- The current native modules (aka bridge modules) architecture has some flaws:
- There is no way to defer its initalization to the future since the native modules registry needs to compute methods of all native modules at runtime.
- Inbuilt (inside react native core) or custom (written by user) native modules cannot be stripped from final build if unused
- Currently, synchronously calling native module methods is possible but is not really recommended because Chrome Debugger does not support it
- Turbo modules (react-native-community/discussions-and-proposals#11) solves most of these problems:
- There is an idea in the proposal to generate Obj C/Java classes using native module shape defined with flow types (or potentially any type system, like typescript) at build time. This removes the initialization step completely since the native code already knows the shape of the native module.
- As such, native modules that are not used in user land code will automatically be stripped from the final build since their Obj C/Java counterparts are not generated. I’m unsure yet about the specifics of how this will happen and whether this just strips out userland native modules or inbuilt react-native native modules as well
- In this proposal, the Javascript counterpart of a native module holds a direct reference/pointer to its native implementation using a Javascript Interface (aka JSI). I imagine it to be a literal memory pointer to the class for the generated native module which can be used to invoke methods on the native side directly. So native module method invocations don't need to batched anymore, as they are today. They can be executed synchronously without congesting the message queue of the “bridge”. However the debugging story for it is still an open question and is tracked in this issue by @nparashuram: react-native-community/discussions-and-proposals#11 (reference)
- improve app startup where the startup/landing screen is react native
- improve loading time when deeplinking to a screen that is react native
- slim down RN size (both native/javascript) in final app if its unused in userland
- Currently, when you load a react native screen, you have to create a root view with the name of the screen you want to load. This is ideally done like this:
- When you do this, react native just returns an empty view synchronously which you then attach to a view controller to draw it on screen. The actual contents of this react native view are populated in the future. While this is performant in some sense, it is not how things would happen if you build native UI’s.
- Fabric solves this by actually rendering react native views more idiomatically i.e. synchronously.
- Embedding react native views inside native views would be more native-like. There won’t be a flash of empty content in place of RN view