Turbo Modules

Remember the native modules from the last post? Text, Image, View. So their new name is Turbo Modules. They have the same purpose but implemented and acting differently. First, they are lazy-loaded (only when the app needs them) comparing to loading all of them on the launch time. In addition, they are also exposed using the JSI so JS holds a ref to use them on the React Native JS lib side. Result => better performance especially on launch time.

1 STASHED

1 LIKE

React Native — A Bridge To Project Fabric 

medium.com

MORE IDEAS FROM THE ARTICLE

The new flow

We now go over the flow from the previous post and will show the differences. There isn’t a bridge anymore

  1. User clicks on the app icon
  2. Fabric loads the native side (no native modules)
  3. It tells the JS thread that it is ready and now the JS side loads all the main.bundle.js which contains all js and react logic + components
  4. JS called through the ref native function (the one that was exposed as an object using the JSI API) to Fabric and the shadow node creates the tree as before
  5. Yoga does the layout calculation converting from flexbox-based style to host layout
  6. Fabric does its thing and shows the UI

1 STASHED

2 LIKES

The current Arhitecture

Don’t get them wrong, Facebook is using React Native by themselves for the Marketplace app, Ads app and more which servers millions of daily users. In addition, some well-known companies like Wix, Bloomberg, Tesla, Zynga and much more using RN in production with the current architecture.

But all of the above companies and especially Facebook got to a point where they understood that if they want to make a better native experience and better developer experience they have to do a huge move and change and this is exactly what they are in a process of doing (part of it is already completed)

1 STASHED

1 LIKE

Some of the main disadvantages of the current structure
  • There are two realms: JS and Native which are not really aware of each other and do not share the same memory
  • The communication is async through the bridge between the two realms
  • It is slow to transfer large chunks of data. Since the memory is not shared, all the data passed between js and native is a new copy
  • No way to update the UI in a sync way.
  • The library repo is HUGE. It makes the library heavier and also making it slower to contribute code from outside or release new fixes

1 STASHED

4 LIKES

The New Arhitecture

Now, let’s explain about all the new words you see here: JSI, Fabric, Turbo Modules

JSI is gonna replace the Bridge

JSI (Will replace the Bridge) — Its purpose is to make the JS and Native are aware of each other. There won’t be any need to serialize JSON through the bridge and even more than that — there won’t be a bridge! It will allow to expose native object as js objects and vice-versa. It will also expose an API for synchronous calling on this object on both sides. Actually, all the rest of the architecture will be built on top of that (Fabric, Turbo Modules which will be explained next).

1 STASHED

2 LIKES

Fabric — the new name for the UIManager which will be responsible for the native side. The biggest difference now that instead of communicating the JS side by the bridge, it will expose its native function using the JSI so the JS side and vice-versa can communication directly those ref functions. Better and efficient performance and passing data between sides.

1 STASHED

1 LIKE

CodeGen — Suppose to make the JS side a Single Source Of Truth. Can let you create static types of the js so the native side (Fabric and Turbo Modules) will be aware to them and avoid validating the data each time => better performance and less place for mistakes when passing data.

Lean Core — A change in React native repository structure. The purpose is to make the lib lighter and help the community resolve more pull requests faster than before. Facebook splits some of its parts to an external repo. It is already a process in progress that you can follow in their Github here.

1 STASHED

1 LIKE

Deepstash helps you become inspired, wiser and productive, through bite-sized ideas from the best articles, books and videos out there.

GET THE APP:

RELATED IDEAS

Testing in React Native

As your codebase expands, small errors and edge cases you don’t expect can cascade into larger failures. Bugs lead to bad user experience and ultimately, business losses. One way to prevent fragile programming is to test your code before releasing it into the wild.

There is more value in testing than you might realize. One of the best ways to fix a bug in your code is to write a failing test that exposes it. Then when you fix the bug and re-run the test, if it passes it means the bug is fixed, never reintroduced into the code base.

7 STASHED

4 LIKES

Testing · React Native

reactnative.dev

They started with iOS and when Android release was ready, took them only 2 days to build.

However, they immediately stopped after identifying various issues such as poor performance of touch events and lack of 64-bit support .

Though they thought React Native was ideally for iOS.

5 STASHED

2 LIKES

Why Discord is Sticking with React Native

blog.discord.com

  1. The user should be notice if the app si offline and be informed in a screen if that feature is not available
  2. The offline features should be synced with the server once back online

3 STASHED

Handling Offline Mode in React Native

around25.com