[Reply] 2022: How can we improve React Native? #546
Replies: 14 comments 29 replies
-
Upgrade story is not compelling (~193 votes)
We recognise the difficulty in pushing for New Architecture adoption and we hope to clarify the goals of the New Architecture. The New Architecture is about new capabilitiesIn 2018, when the New Architecture project started, we took a look at the limitations of our bridge structure due to its asynchronous nature of message passing. One of the hero cases for re-writing our architecture was to support synchronous renders — specifically to synchronously calculate height of dynamic views so there would be no layout jumps. As well, React was releasing support for concurrent rendering — all of which motivated us to rewrite our architecture to handle these new use cases. To clarify, the goal of the rewrite was to unlock new capabilities within React Native and not to change the baseline performance. Moving forward we should better demonstrate new capabilities of the New Architecture. For example, here is a commit where we New Architecture performance should be neutral and how we measured this at MetaAs mentioned, the goal of the New Architecture was not to improve performance but, with Meta using React Native in over 71 apps, we had to ensure the New Architecture would not regress performance. The same holds true for any app using React Native in open source. Today, we have rolled out the New Architecture to over 1100 screens on Android and iOS; all React Native surfaces within the Facebook mobile app are using it. To rollout, we had ensure we didn’t regress key performance metrics that the Facebook app uses, most notably time to render recent content and memory usage. Even though the cornerstone of the new architecture was not performance, it is under active development at Meta. We will continue making incremental improvements over time. How migration has been challenging for our community and how we hope to helpThe migration path is not what we would like it to be. We are still evaluating what we can do better there and how to minimise the cost of migration. For example one of the ideas that we have is to expand interop layer to be more feature complete and document it. This would allow the New Architecture to work with legacy native components. On JavaScript side, we’re looking for ways to support deprecated APIs like findNodeHandle and measure. You would only need to move off legacy native components and deprecated APIs once you start using the new capabilities. This way, migration effort would be minimal and it would allow the ecosystem to move towards the new architecture gradually. |
Beta Was this translation helpful? Give feedback.
-
LogBox issues and hard to debug errors (~161 votes)
In 2019 we introduced LogBox as a replacement for YellowBox as a better way to surface errors and warnings to users. At the time, we didn’t even log errors or warnings to the console, and the error experience was just the native Redbox. LogBox fixed this by showing console errors, in addition to console warnings, in the app; parsing stack frames to find the relevant application causing the error; showing a code frame for the error location; and showing the user component stack traces. Over time, some of these features regressed so for 0.71 we’ve made some improvements including:
Some future improvements we could make are:
Finally, for console errors triggering LogBox: even though we do show console errors and warnings in the Metro console and other places now, those logs can still be cryptic, unsymbolicated, and hard to understand. Until those logs are as easy to understand as they are in LogBox, I think it makes sense to continue showing them in the app. But if you want to disable logs in LogBox you can call LogBox.ignoreAllLogs() and LogBox will only pop up for thrown exceptions. Please continue flagging issues with the error experience and how we can improve it. If you have and more ideas, feel free to ping me directly! |
Beta Was this translation helpful? Give feedback.
-
Consistency of APIs across platforms (~150 votes)
We appreciate the feedback asking for improvements to cross-platform React development, and have been investing in this at Meta for many of the same reasons highlighted here. The overall direction of this work is to reduce the fragmentation between React Native and React DOM, and unify common features around W3C open standards. The "Reduce API fragmentation" RFC (#496) will continue to be updated and will incorporate ongoing community feedback. In addition the the related work on Yoga that will be mentioned, these are some of the other projects we're currently working on:
The community's support and involvement in expanding cross-platforms support to Web has been instrumental in allowing us to pursue this work at Meta. (Special thanks to @gabrieldonadel, @dakshbhardwaj, @dhruvtailor7, @ankit-tailor, and @madhav23bansal.) And we will need your continued help and adoption in 2023! |
Beta Was this translation helpful? Give feedback.
-
|
Just want to mention big progress in shared UI between platforms made in tamagui by @natew. It's currently most advanced and feature reach RN+web UI lib. |
Beta Was this translation helpful? Give feedback.
-
|
RFC: Reduce API fragmentation has been updated with a more complete proposal for unifying with React DOM. |
Beta Was this translation helpful? Give feedback.
-
More engagement on PRs (~58 votes)We appreciate and recognize the time it takes for contributors to make pull requests for our codebase in efforts of making React Native better for all. In regards to response time, in mid-2021 our team introduced a process to address new pull requests as they come in. It is now a responsibility of our on-call rotation to acknowlede PRs and pull in relevant owners. Since this change, the delta between number of open and closed PRs per week has stayed closer to 0. While not a perfect metric for staleness, it is re-assuring that we’re sustainably tackling new PRs. However even with this process there are still PRs that will be lengthy to merge. This is dependent on the complexity of the change and also the direction. As React Native apps within Meta work off of the main branch, our team is responsible for ensuring we don’t regress these apps, and further, the community who will receive these changes in new releases. Due to this, sometimes there is also internal work we have to do which also adds to delay. Ideas we have on improving this:
|
Beta Was this translation helpful? Give feedback.
-
Lacking documentation, guidance for workflows (~326 votes)
We hear the complaints of how documentation needs work for React Native. Just as React docs have been going through a re-write to focus on understanding concepts, we acknowledge the React Native docs need similar investment. We hope to address this by ensuring current projects incorporate documentation into planning. For example, our work on adding symlinks to Metro should also include updating documentation and providing guides. Similarly, New Architecture rollout considers documentation a core part of its success. However that doesn’t address the missing documentation of APIs and behavior today. We hope that we can prioritize a re-write of the documentation soon but in the meantime we will happily prioritize and review PRs from the community to fix any documentation. In addition, we are leveraging website survey feedback and analytics from the website to prioritize the most impactful areas. In terms of best practices and use-cases, I think the community is often the best equipped to share their knowledge. That being said, if there are ways the team can help folks write and share best practices, please let us know! Especially as the New Architecture becomes the standard, our documentation should build expertise in the community to best teach others. |
Beta Was this translation helpful? Give feedback.
-
Poor experience with UI capabilities offered by React Native (~600 votes)
Thanks everyone for raising these issues around UI capabilities in React Native — there is definitely room for improvement. In the past, our approach has been to rely on the community to fix these experiences — either by building their own libraries or contributing back to core. However we know that hasn’t been working. The community hasn’t been set up for success due to the lack of direction and education from us. All of this is to say, I think these issues can be helped by the team:
Regarding 1, there is still active discussion and question on what level of ownership React Native product should take. Some ideas include shaping React Native to be more like a browser — providing the essential APIs such that UI engineers can build small abstractions that build on one another. Our 2018 lean core effort was a first step in evaluating where our ownership boundary should lie. I think this model will continue to evolve from the feedback of our use-cases of React Native internally and discussion. Regarding 2, this is something React Native can do better in both triaging issues, prioritizing and informing core contributors to get involved to help solve. Some potential action items our team is looking into:
|
Beta Was this translation helpful? Give feedback.
-
|
What about numColumns support for SectionList ? |
Beta Was this translation helpful? Give feedback.
-
CSS features and support for Yoga (~328 votes)The need for more modern CSS features is something we agree with. React Native 0.71 takes a step towards this, adding support for Some important styling properties like We’re betting on Yoga as the vehicle to drive innovation to layout in RN. Supporting OSS is a key objective in the overall project. We’ve started off by building a backlog of existing PRs and issues, but have a lot to do to foster contribution. Yoga unit tests are not runnable in OSS. Its JS bindings (still widely used by the community) haven’t been installable as a standalone since Node 10. There is not an automated system to release new packages for Cocoapods. This is not to mention issues against YogaKit, the Yoga playground, the yogalayout ViewGroup, or a C# implementation that has been out of commission for years. All that is to say there is no shortage of work. Core Yoga is probably our highest priority, as it impacts everyone (and is the layer Fabric uses across platforms), but some of issues impacting standalone Yoga (e.g. the degraded JS bindings) feel like we should find a way to tackle for the ecosystem, either as direct implementation, or enabling the community to implement. |
Beta Was this translation helpful? Give feedback.
-
|
Adding web styles like |
Beta Was this translation helpful? Give feedback.
-
Make Metro Better (~142 votes)
In 2022 we grew the team maintaining Metro at Meta and focused on improving Metro’s correctness, reliability, compatibility and performance. We also resumed regular open source releases of Metro, improved Metro’s documentation for contributors, and collaborated closely with Expo on Metro for web and Expo Router. We’re actively working on symlink support (including first-class support for pnpm and other package managers that rely on symlinks) and on We strongly believe in Metro’s core architecture and the developer experience it enables for React Native. We’re excited to see newer bundlers such as Turbopack and Parcel adopting an incremental compilation architecture that is fundamentally similar to Metro’s, which enables consistently fast builds at scale. The innovation in this space has also created new opportunities to improve Metro’s performance even further; one of those is replacing Metro’s Babel dependency with a higher-throughput JavaScript compiler (SWC or similar) for faster initial builds, which we’re hoping to explore in 2023. |
Beta Was this translation helpful? Give feedback.
-
|
Great work! Can't wait until tree shaking is prioritised though 😢 ! |
Beta Was this translation helpful? Give feedback.
-
Upgrades are painful (~234 votes)
Upgrading is an important part of the React Native developer experience and we plan to continue investing in making upgrading a smoother and more reliable process. Over the years React Native has made improvements to the upgrading experience like Autolinking, the Upgrade Helper, and Microsoft’s align-deps for finding compatible versions of 3rd party modules. There is still much more that we need to do here to make this as seamless and integrated as it should be. It’s also important to recognize that the upgrade experience consists of many stages and conditions including but not limited to:
We want to acknowledge that this is a longstanding issue and we have not made as much progress on this as we would like. We are very motivated to address this as its a critical step for the New Architecture rollout and sustainable growth of the ecosystem, and will continue doing research on current gaps and the most impactful areas to focus on in the upgrade experience. If you have ideas or suggestions for how to improve upgrades, please reach out! |
Beta Was this translation helpful? Give feedback.
-
|
@cipolleschi Makes sense to be careful adding new tools. Do you have any thoughts on the process I listed? |
Beta Was this translation helpful? Give feedback.
-
|
We already do the same thing with the upgrade helper. The tool does exactly that: it creates a new app and run a diff command on the files, outputting the differences between the two, so that they can be applied. :D |
Beta Was this translation helpful? Give feedback.
-
|
The helper is pretty great, but that's comparing two example apps and not an existing app to a skeleton version created with the exact React Native version you're upgrading to. Just being able to generate a more similar skeleton app to diff against using some clever introspection would go a long way. Is the upgrade helper using AST diffing? |
Beta Was this translation helpful? Give feedback.
-
|
@rolfb I'm not sure I'm following, but if the suggestion is to compare any app X to the sample app created by Yes, it would be probably possible to try and consider only the files in that the template knows to show the differences, but still, for some highly customized app, this won't work. Imagine that you have a complex AppDelegate (for iOS) or a complex Activity or you have renamed those files... The tool won't be able to catch those changes. The number of edge cases to handle would make the pretty hard to create properly.
No, not as far as I know. It does something more advanced than just |
Beta Was this translation helpful? Give feedback.
-
|
@cipolleschi Apologies for the late reply. The amount of output in a diff can be mitigated by ignoring some folders when upgrading with one such folder being A complex AppDelegate or renamed native files can be handled by AST-based diffing which will make necessary changes more clear by where code moved. Mileage may vary a lot here, but probably better than current? The process could be something like:
Unsure if I am communicating this well, but just sorting the keys in |
Beta Was this translation helpful? Give feedback.
-
Hard to migrate to New Architecture (~111 votes)Our team is committed to making the New Architecture rollout as smooth and gradual as possible for application users. While the New Architecture is in this experimental phase, we’re working closely with library maintainers and early adopters in our New Architecture Working Group to collect feedback on the pain points and ways we can improve the New Architecture easier to adopt. In August, we asked the Working Group for the Major Pain Points to Migrate to the New Architecture to gauge our progress and check in on how the community was feeling regarding the migration. Based on that discussion, we already pushed some improvements:
We’re commited to getting this right so that users have a seamless migration experience. Our hope is that users will need to only need to make a few changes when the New Architecture will be stable and the default, similar in effort to any other major release. In response to some specific issues mentioned:
If you have any feedback or have any difficulties with the experimental version of the New Architecture, please continue to post in the New Architecture Working Group! |
Beta Was this translation helpful? Give feedback.
-
|
@mikehardy thanks for the clarification, I wrote that comment in the context of the OP about it being hard to migrate to the new architecture. Sorry if I was unclear there, I know that RNFirebase works fine without the new architecture and I know you put in ton of awesome hard work to make it as great as it is! All that hard work is very appreciated, IMO RNFirebase is one of the highest quality libraries available in the react-native ecosystem. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for the clarification and for highlighting the problem. It is a very dear problem to me and I hope we would be able to have it solved soon. Also, consider that the New Architecture is still in an experimental phase. We have a list of things we need to work on and solve before we can mark it as stable and solving the |
Beta Was this translation helpful? Give feedback.
-
|
Swift support for new architecture should be must. |
Beta Was this translation helpful? Give feedback.
-
|
Please, swift support. |
Beta Was this translation helpful? Give feedback.
-
Is there an issue or thread somewhere we can follow to get notified of possible ETA or changes here released? Thanks :) Edit: |
Beta Was this translation helpful? Give feedback.
-
Poor Debugging ExperienceWe are aligned with the OSS community that the debugging experience with React Native is not up to the standard we like. In 2019, we added default Flipper support with React Native v0.62.0 as a single unified tool to debug React Native apps to improve the debugging experience. Unfortunately, the debugging experience with Flipper has regressed. Currently, the Flipper team has been focused on native developer experience, so we are going back to the drawing board. We have created a new pillar within our team focused on Developer Experience. We are currently investigating improved Chrome Debugger protocol support from the Hermes team as well as migrating the debugging experience from Flipper to Chrome DevTools so we can deliver a debugging experience that meets our standard. Plans are evolving as we go into planning and we hope to keep the community updated once they are finalized. If you are interested in helping with this effort or providing feedback, feel free to comment below and we'll reach out or join us on the React Native discord -- you can get access through this form. Thank you so much for your patience while we work on this! |
Beta Was this translation helpful? Give feedback.
-
|
I'd love to help with that. |
Beta Was this translation helpful? Give feedback.
-
|
We at Infinite Red know that a lot of React Native developers rely on Reactotron for debugging support, as well. Reactotron's developer experience has also regressed over the past several years. However, we have plans to address that in the new year, so look for improvements to come along at some point. The more high-quality tools we have for debugging RN apps, the better. |
Beta Was this translation helpful? Give feedback.
-
|
Where can we be updated about your work? I had no choice to use Hermes by now and I am stuck with the poor Flipper debugging experience |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment has been hidden.
This comment was marked as off-topic.
This comment was marked as off-topic.
-
|
Hi @mfbx9da4, this is the response thread to the survey. Please only leave reply comments to the top-level posts. If you have feedback to leave, I've unlocked #528. Please leave this feedback there, thank you! |
Beta Was this translation helpful? Give feedback.
This comment was marked as off-topic.
This comment was marked as off-topic.
and others
-
Last month we asked “How can we improve React Native?”, and we received over 2000 votes across 80 comments with suggestions in topics ranging from debugging tools, to new UI capabilities. We appreciate all of the time folks took to provide feedback, and in this post we’re responding to the top voted issues.
We've grouped a lot of the feedback into general themes and will post a comment for each.
Please only leave replies to these comments -- thanks!
Beta Was this translation helpful? Give feedback.
All reactions