Recommend using interop layer first when adding new arch support to libraries #166
Conversation
brentvatne
requested review from
Kudo,
cortinico,
cipolleschi,
gabrieldonadel and
alanjhughes
docs/enable-libraries.md
Outdated
| ### Common issues (JavaScript) | ||
|
|
||
| (list them here, along with solutions and links to pull requests) | ||
|
|
||
| ### Common issues (iOS) | ||
|
|
||
| (list them here, along with solutions and links to pull requests) | ||
|
|
||
| ### Common issues (Android) | ||
|
|
||
| (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.
| > [!IMPORTANT] | ||
| > Before proceeding to convert your library to natively use TurboModules/Fabric, you should [ensure that it is compatible with the interop layer](enable-libraries.md). This is the quickest way to make your library compatible today. | ||
|
|
||
| This guide explains how to convert your library to use the TurboModules API and Fabric Component API natively, without the interop layer. The following steps are prerequisites to ensure your modules and components are ready for the New Architecture. |
There was a problem hiding this comment.
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.
docs/enable-libraries.md
Outdated
|
|
||
| (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 getShadowNodeClass, createShadowNodeInstance etc.
Fabric won't call those methods and the widget will most likely be rendered wrongly (i.e. wrong size, 0 height so unclickable, etc.)
docs/enable-libraries.md
Outdated
|
|
||
| ### 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.
New Arch Bridge mode is sort of an "intermediate" state that we have now as we're enabling Bridgeless mode by default. In the future New Architecture === Bridgeless mode.
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
Co-authored-by: Gabriel Donadel Dall'Agnol <donadeldev@gmail.com>
Currently the only guidance we provide in this repo is how to convert your module to use TM/Fabric APIs. The quickest approach to get your library compatible today is to leverage the interop layers that React Native provides by default as of 0.74. We want to recommend that library authors first begin by ensuring/fixing compatibility via interop layers, before proceeding to either rewrite with TM/Fabric APIs, Expo Module API, or something else. It is much easier to use interop layers and guiding folks to use this right now could significantly assist in the rollout of the New Architecture, lest the community be overwhelmed by potentially large refactors.