[Reply] 2022: How can we improve React Native?

[lunaleaps]

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!

[sammy-SC]

Upgrade story is not compelling (~193 votes)

• Developers have a hard time convincing their leadership to invest in migrating to the New Architecture.
• Lack of performance benchmarks to check on what benefits we are getting.

---

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 capabilities

In 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
explored synchronous rendering. This API is not ready for production use but it demonstrates how the new architecture can fix async nature of React Native.

New Architecture performance should be neutral and how we measured this at Meta

As 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.
We measured these metrics in production on millions of devices of varying device classes over several months to ensure neutral performance across the board. We spoke in more detail on the challenges of rolling out New Architecture to the FB app in our React Native EU 2021 talk.

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 help

The 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.

[rickhanlonii]

LogBox issues and hard to debug errors (~161 votes)

• LogBox has issues symbolicating errors and incurs cost in transpilation
• Improve Promise.reject errors
• Better error debugging

---

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:

• Better stack frame collapsing. We found that the list of internal stack frames had not been updated in awhile, causing LogBox to blame internal React Native code instead of product code that the user could act on. We’ve updated this list (Add more internal callsites for better stack frames cli#1699) so we’re reporting the correct frame more often.
• Less white screens due to errors: We found the error handling was being initialized too late in the startup sequence, which would cause early errors to cause a blank screen instead of showing a LogBox with the error. We fixed this ([devx] Fix error reporting for module errors facebook/react-native#34650) so that more errors are shown to the user instead of blank screens.
• Not filtering logs from the console. This (facebook/react-native@fa2842d) was a change championed by Expo ([LogBox] Add LogBox.isIgnoredLog() for expo remote logging integration facebook/react-native#34476), which reverts the behavior of LogBox.ignoreLogs() so that it does not hide errors and warnings from the console. This ensures that important deprecation warnings and critical issues are not hidden from the user globally.

Some future improvements we could make are:

• Delete the native redbox experience: Most of the errors that are not caught by LogBox today are due to environment issues such as the bundle not being available, a syntax error in the bundle, are an error in a native function. In all of these cases, the current Redbox is hard to understand. We have some designs (Redesign Native RedBox  facebook/react-native#29158) for how to handle these cases better, and would love some help from the community to implement them.
• Ahead-of-time bundle LogBox: LogBox code is never changed by app developers. To prevent the overhead of bundling LogBox modules, we could ahead-of-time bundle them and include it as an asset. No timeline on this, but if anyone in the community is interested in pairing on this, I’m happy to help out!
• Symbolicate Component Stacks: I’ve actually built a prototype for this, but we were blocked on getting full file names from React. Now that React has changed the way we gather component stacks by using stack frames, I believe we can implement this. The blocker is switching React Native over to use the new component stack frames format.

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!

[necolas]

Consistency of APIs across platforms (~150 votes)

• Cost/benefit of what should and shouldn’t be platform-specific styling
• Reduce API fragmentation
• Should React Native own React Native Web?

---

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:

• Adding the W3C EventTarget and PointerEvent APIs to React Native. We want to unify the interface for working with pointer lifecycles and different pointer types across platforms.
• Adding W3C element props and styles to React Native. We want to reduce the differences between React Native and React DOM when it comes to configuring and styling elements. The React Native community has already been a big help in making progress on this front.
• Unifying styling APIs between React Native, React Native for Web, and stylex. We're working towards expanding the CSS feature set of React Native StyleSheet, and we're working on compatibility between stylex and React Native for Web. Our goal is to eventually deliver an API and a CSS subset that developers can rely on across platforms.
• Moving react-native-web under Meta ownership. We're serious about supporting the web as a target, and improving the results developers can expect.

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!

[pronevich]

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.

[necolas]

RFC: Reduce API fragmentation has been updated with a more complete proposal for unifying with React DOM.

[lunaleaps]

More engagement on PRs (~58 votes)

• PRs open for over 9 months
• Lack of team engagement on PRs

---

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:

• Guidance on making PRs small and well-tested.
• Guidance on how to add changes to React Native in a way that allows us to leverage internal experimentation frameworks. This de-risks changes for us.
• Building a culture of proposals/discussion that involves team buy-in before before making a PR. We already have a discussion and proposals group but we could lean into this more strongly to ensure no one gets burned by submitting a PR that has little chance of being merged.

[lunaleaps]

Lacking documentation, guidance for workflows (~326 votes)

• Documentation is missing some APIs and some examples are too simple
• Lacking documentation for best practices
• No documentation for different platforms

---

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.

[lunaleaps]

Poor experience with UI capabilities offered by React Native (~600 votes)

• Keyboard handling is a bad experience
• FlatList capabilities and performance
• Image, Image Caching Support
• RTL support needs improvement
• Better support for different platform layouts
• Layout Animations on Android is still experimental
• Lack of control over shadows on Android

---

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:

1. Getting a clearer idea of what should belong in React Native
2. Figuring out how we support the community in providing direction, education

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:

• Aligning our internal support model with OSS support. This would incentivize more eyes on issues that affect both internal and OSS users.
• Better signals to our community on what issues would be impactful to work on and collaborating to get fixes in. Similar to our response on community engagement, this might involve figuring out a working model via discussions and proposals and making changes in a way they can be experimented on.

[blazk0]

What about numColumns support for SectionList ?

[NickGerleman]

CSS features and support for Yoga (~328 votes)

• CSS Features
• Improve Styles in React Native

---

The need for more modern CSS features is something we agree with. React Native 0.71 takes a step towards this, adding support for gap, rowGap, and columnGap. This was enabled by a long-standing Yoga contribution by @jacobp100 and React Native bindings for Android, iOS, and Fabric by @intergalacticspacehighway.

Some important styling properties like boxShadow and filter would be implemented by the platform’s native view system, but there is a specific callout on Yoga, which enables layout properties (sizing, positioning, etc). We are planning to add new layout capabilities and make the existing ones act more like the web. The key challenge here is moving our ecosystem, reliant on incorrect behavior. The linked RFC provides many more details on our long-term vision, and feedback is encouraged.

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.

[nandorojo]

Adding web styles like boxShadow & filter, in addition to modern styles like clip-path, would make designing in React Native so much better. gap is already a huge step. I'm excited that this is potentially on the roadmap.

[motiz88]

Make Metro Better (~142 votes)

• Missing features in Metro: symlinks, custom source maps, exports, better performance
• Better documentation for Metro
• Support for more package managers

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 exports; these are vital features for compatibility with the broader JavaScript ecosystem, and we recognise they’ve been a long time coming. We’re planning to ship them in early 2023. There’s also more work to be done on documentation, stabilising experimental features, and encouraging open source contributions to Metro.

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.

[mfbx9da4]

Great work! Can't wait until tree shaking is prioritised though 😢 !

[elicwhite]

Upgrades are painful (~234 votes)

• Current tooling for upgrades is not reliable
• Want better tools for release upgrades
• A lot of instability between releases

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:

• Environment setup
• Upgrading 3rd party modules
• Upgrading Xcode projects
• Modifying app code
• Native API stability
• Education on new features
• Security maintenance

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!

[rolfb]

@cipolleschi Makes sense to be careful adding new tools. Do you have any thoughts on the process I listed?

[cipolleschi]

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

[rolfb]

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?

[cipolleschi]

@rolfb I'm not sure I'm following, but if the suggestion is to compare any app X to the sample app created by npx react-native init with the version you like, I don't think it will be helpful at all. The diffing will output so many differences (due to the app X being a real app and it will have much more code) that will make the tool nearly unusable.

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.

Is the upgrade helper using AST diffing?

No, not as far as I know. It does something more advanced than just diff but not something that advanced.

[rolfb]

@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 src/ and further by ignoring unrelated folders and files. Exceptions to this can be called out explicitly during the process?

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:

1. Prepare destination (ex. sort keys in package.json alphabetically or another consistent ruleset if alphabetical isn't ideal)
2. Collect information (app name, bundle identifiers)
3. Generate skeleton with --skip-install and as much detail from previous step as possible (no more RnDiffApp or com.rndiffapp)
4. Prepare skeleton using same rulesets as step 1 if not done upstream
5. Diff and patch, using AST interactively where applicable

Unsure if I am communicating this well, but just sorting the keys in package.json on both sides in preparation reduces the diff between 0.70.6 and 0.71.0-rc.2 by 6 lines, or 15%, in a quick test. Would be one less line if the correct package name was set during init. On the other hand it could be very important for people to have keys like name and version at the very top of the file, but as long as the process is consistent in preparing one or both sides before diffing it would reduce the output.

[cipolleschi]

Hard to migrate to New Architecture (~111 votes)

• use_frameworks is not supported
• Better documentation needed for migration

---

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:

• Reduce boilerplate C++ code users need to write: In Android, we encapsulated a lot of code into the Defaults classes (C++ and Java/Kt). Before this change, there was a lot of boilerplate C++ to developers to manage. Now they’re removed from app space so users don’t need to write them by default, and we’re added options to configure more custom setups.
• Reduce boilerplate iOS code users need to write: Similarly for iOS, a lot of this logic was moved into a RCTAppDelegate class, and we are providing a single function for libraries to easily configure themselves for the New Architecture.
• Reduce the number of unsupported JS APIs: From community feedback on the difficulty of migrating off certain JS APIs, we are exploring ways to allow for backwards compatible usage of JS APIs such as findNodeHandle and measure*. These APIs will still be deprecated because they can cause bugs or are not performant, but our goal is that users will not need to migrate off of them before enabling the New Architecture.

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:

• use_frameworks!: we are actively tracking the issue, and hope to prioritize the work as soon as we can.
• Documentation: this will continue to be an investment and we have several open PRs with doc updates for the New Architecture. In addition, we are maintaining the RNNewArchitectureApp and RNNewArchitectureLibraries repositories to demonstrate New Architecture migration step-by-step.

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!

[evelant]

@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.

[cipolleschi]

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 use_framework! problem is part of that list. :D

[BraveEvidence]

Swift support for new architecture should be must.

[migueldaipre]

Please, swift support.

[uloco]

use_frameworks!: we are actively tracking the issue, and hope to prioritize the work as soon as we can.

Is there an issue or thread somewhere we can follow to get notified of possible ETA or changes here released? Thanks :)

Edit:
NVM, found it here reactwg/react-native-new-architecture#115

[lunaruan]

Poor Debugging Experience

• Debugging with Flipper
• Improve the stability of React Native debugger

---

We 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!

[manakuro]

I'd love to help with that.

[jamonholmgren]

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.

[JohnBerd]

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

[lunaleaps]

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!