Recommend using interop layer first when adding new arch support to libraries #166
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,40 @@ | ||
| [../README.md#Guides](../README.md#guides) | ||
|
|
||
| # Enable the New Architecture for Libraries | ||
|
|
||
| **The first step for supporting the New Architecture in your library is to ensure that it is compatible with the [interop layer](https://github.com/reactwg/react-native-new-architecture/discussions/135)**. The interop layer makes it possible to use existing native modules written for the legacy architecture with the New Architecture. **You should do this before proceeding to convert your library to natively use TurboModules/Fabric.** Starting with React Native 0.74, the interop layer is enabled by default and, if your library is compatible, then no changes will be needed on the user's side in order to use your library. | ||
|
|
||
| ## Using the interop layer | ||
|
|
||
| The interop layer will generally work out of the box with simple libraries, but the more complex your library is, the more likely it is that you will need to make some changes. The following sections will guide you through the process of verifying that your library works with the interop layer and fixing common issues that you encounter. | ||
|
|
||
| > [!IMPORTANT] | ||
| > If you have already added a Codegen spec to your library, but the library is not fully converted to TurboModules/Fabric, we recommend that you delete it before proceeding. You can add this back when you are ready to convert your library to natively use TurboModules/Fabric without the interop layer. | ||
|
|
||
| ### Test your library | ||
|
|
||
| Follow [the guide for testing your library against the latest version of React Native](https://gist.github.com/cipolleschi/82b7a9561b8861330efabbd3eb08c6f5). Be sure to test all of the functionality of your library to ensure that it works as expected. | ||
|
|
||
| ### Common issues (JavaScript) | ||
|
|
||
| (list them here, along with solutions and links to pull requests) | ||
brentvatne marked this conversation as resolved.
Show resolved
Hide resolved
|
||
|
|
||
| ### Common issues (iOS) | ||
|
|
||
| (list them here, along with solutions and links to pull requests) | ||
|
|
||
| ### Common issues (Android) | ||
|
There was a problem hiding this comment. We know that the Interop Layer doesn't work on either Android or iOS if a legacy view is specifying a custom ShadowNode, i.e. in Android by overriding the method |
||
|
|
||
| (list them here, along with solutions and links to pull requests) | ||
|
|
||
|
There was a problem hiding this comment. @Kudo @alanjhughes @gabrieldonadel - can you add some suggestions here for common issues to seed this with some initial useful tips? we can expand on it later. could base it off of the prs you've had to open recently / the "common problems" tab on spreadsheet. |
||
| ### Get help | ||
|
|
||
| Search the ["Libraries" discussion category](https://github.com/reactwg/react-native-new-architecture/discussions/categories/libraries) for similar issues, and if you can't find a solution, post a discussion with details about the issue you are facing. | ||
|
|
||
| ### Update library status | ||
|
|
||
| (post to the discussion? add some metadata to the pkg.json?) | ||
|
There was a problem hiding this comment. Question: Wouldn't this require even more work from OSS library maintainers? As of now, they support Old Arch/New Arch/Bridgeless and I guess most of them are not testing interop layer. Specifying explicit support would require them also to test the changes for interop layer before releases There was a problem hiding this comment. There is no need to test the interop layer if you already support NewArchitecture. Also libs should be focused on testing only Old Arch and Bridgeless. What @brentvatne mentioned here was more: if you're looking into supporting the New Architecture, the first thing to do is just try a NewArch app with your library. It might just work out of the box and there is nothing extra to do 👍 There was a problem hiding this comment. Makes sense, thanks for clarifying |
||
|
|
||
| ## Next steps | ||
|
|
||
| Once your library is compatible with the interop layer, release a new version for your users. You can proceed to [converting your library to natively use TurboModules/Fabric](enable-libraries-turbomodules.md) when convenient for you. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably the only nit here is:
Folks will ask themselves what are the pros/cons of using the Interop Layer no? Currently we're not aware of any performance cost imposed by the Interop Layer, but we know we intend to remove them at some point in the future. This is needed for example to remove Old Arch code which will reduce app size.
So we should probably clarify that today, it's safe to use the Interop Layer as a first solution without performance implications, and then consider migrating to the native APIs in the near future.