React Native — A Bridge To Project Fabric — Part 3

Finally, we got to the last post explaining about the future that’s coming for RN architecture.

We discussed the current structure until now and it is time to talk about the stuff that was not the perfect choice, looking backward as React team leader on Facebook at this time mentioned in her blog post

Some of the main disadvantages of the structure of the current architecture are =>

• 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 but it also means no guarantee the data will get to the other side in 100% or in the time we want
• 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. Let's say I have a FlatList with a huge amount of data the is loaded when I scroll, the screen might flicker in some edge cases when there was a UI interaction but the data hasn’t got back yet to be shown
• The library repo is HUGE. It makes the library heavier and also making it slower to contribute code from outside or release new fixes

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)

They decided to solve all those issues mentioned as disadvantages above.

So if that was the previous architecture structure =>

The General Structure of the main pieces in the current architecture (for explaining the terms)

This will be the new one =>

The General Structure of the main pieces in the new architecture (for explaining the terms)

Now, let me explain about all the new words you see here: JSI, Fabric, Turbo Modules, and CodeGen.

I will do it in the same way I did in my last post. First -> Fundamental terms and Second -> App launch flow with the new structure and terms.

1. 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).
2. 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.
3. 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.
4. 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.
5. 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. This is how they show it =>

BTW — here is an example of something you can try on your chrome browser which is the inspiration for how the JSI works and exposes objects =>

Inspect a page in chrome and write console.log and press Enter. You will see a native code. The console.log and other functions are actually objects exposing a ref to native code (C++ in this case)..crazy ah?

As promised, I will now go over the flow from the previous post and will show the differences. The biggest difference is that there is no 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 =>

To wrap up the flow, we do almost the same but without the bridge and now we can have better performance, we can do stuff in a sync way and even prioritize the sync actions on UI. The launch time will also be better and the app size will be smaller.

So..when can I use all this awesome stuff???

You can follow all the updates in threads that Facebook created in their Github here:

1. JSI
2. Fabric
3. Turbo Modules
4. Lean Core
5. CodeGen

Generally, most of the changes will be done gradually and will hopefully be released in Q4 2019 or Q1 2020.

Finally, we got to the end of the posts about Project Fabric. It took me some effort to collect all those pieces of information to get a better understanding of this new structure.

I will be happy to get some Claps and if you also want to follow me on twitter to see the slides and lectures I started giving about it you are welcome to follow here

Feedbacks are also welcome! Thanks for reading (:

My Twitter: chenosfeldman

My LinkedIn: Chen Feldman

P.S — here is some little part of links I read and watched as part of the process and recommend you to try to sharpen your understanding. (I give credits to all of them for giving me great material to read and watch)=>

• Latest RN news from Core Team- https://facebook.github.io/react-native/blog/
• Parashuram post about the new architecture http://blog.nparashuram.com/2019/01/react-natives-new-architecture-glossary.html
• Pharam new 2019 lecture React Amsterdam — https://www.youtube.com/watch?v=NCLkLCvpwm4
• https://levelup.gitconnected.com/wait-what-happens-when-my-react-native-application-starts-an-in-depth-look-inside-react-native-5f306ef3250f
• Layout engine explnation — https://www.freecodecamp.org/news/how-react-native-constructs-app-layouts-and-how-fabric-is-about-to-change-it-dd4cb510d055/
• Four parts article about the new architecture by Lorenzo from Formidable (part 1 here links to the others)— https://formidable.com/blog/2019/react-codegen-part-1/
• FB State of React Q4 2018 by Sophie Alpert from FB team at this time — http://facebook.github.io/react-native/blog/2018/06/14/state-of-react-native-2018

Credits to : Ronen Mars, Nick Ribal or frenkel and Irad for helping to finalize the post’s content

My lectures about this subject — upload here soon

• React Next 2019 (English) — https://youtu.be/_IiDHmAPH28
• Reversim 2019 (Hebrew) — https://youtu.be/2eZ4G-loZkY
• Podcast episode (Hebrew) — https://www.ranlevi.com/2019/07/23/osim_software_react_native_bridge/