• Author: Mehul Mohan
  • How React Native Constructs App layouts (and How Fabric is about to change it)
  • React Native – First Steps
  • Twitter: Mehul Mohan
  • The Future of React Native RN Fabric (Is Pretty Awesome!)

The React Native team has been working on ways to fundamentally change the way React Native works with the operating system. Let’s call this Project “Project Fabric” until it’s officially released. Let’s talk about what it is and how it will change for developers.

How does React Native currently work

React Native currently uses three threads:

  1. UI thread – This is the main application thread that runs Android/iOS applications. It has access to the UI, which can only be changed by this thread.

  2. Shadow thread – This thread is the background thread used by React Native to calculate the layout created by React.

  3. JavaScript Thread – This thread is the execution environment for JavaScript code (actually your React code).

Internal communication

Let’s analyze its construction process from the beginning. Suppose you want to draw a red box in the center of the screen. Then, your JS thread will contain the code to create the layout. Here’s a typical React Native (RN) layout:

    <View style={{ flex: 1, justifyContent: "center", alignItems: "center" }}>
        <View style={{width: 100, height: 100, backgroundColor: "red"}}></View>
    </View>
Copy the code

The system has its own layout implementation, and it doesn’t understand the Flexbox code you just wrote. Therefore, RN must first convert your Flexbox encoded layout into a layout system that the system can understand.

Moving on, we need to transfer this layout calculation portion to another thread before the transformation so that we can keep the JavaScript thread executing. RN therefore uses shadow threads, which are essentially building a layout tree encoded in the JS thread. In this thread, RN uses a layout engine called Yoga, which translates the layout based on Flexbox into a layout that the system can understand.

React Native uses the React Native Bridge to pass this information from the JS thread to the Shadow thread. In a nutshell, this is just serializing the data in JSON format and transferring it as a string to the React Native Bridge.

At this point, we are in the Shadow thread. The JS thread is executing and there is nothing on the screen. Once we get the render tag from the Yoga, this information will be transmitted to the UI thread again via the React Native Bridge. Again, this will do some serialization on the Shadow thread and deserialization on the main thread. And then the main thread will render the UI.

Existing problems

As you can see, all communication between threads takes place on the Bridge, but there are many limitations. Include:

  • Transferring large data (such as converting an image to base64 string information) is slow, and if you can accomplish the same task by simply pointing to data in memory, these are unnecessary copies of data

Also, all communication is asynchronous, which is fine in most cases. However, there is currently no way to synchronize updates from the JS thread to the UI thread. This can be problematic when you use flatLists with a lot of data. (You can think of FlatList as a poor implementation of RecyclerView.) Finally, due to the asynchronous manner in which communication between THE JS thread and the UI thread is conducted, the native modules that strictly require synchronous data access are not fully available. For example, RecyclerView on Android requires that the adapter synchronously access the data it presents in order to have no flicker on the screen. This is not possible due to React Native’s multithreaded architecture.

Introduce the Fabric

Let’s go back to the layout of the browser. If you think about it, the way the browser renders input fields, buttons, etc., is actually operating system dependent. So, when rendering, your browser will ask your operating system (Windows, Mac, Linux, or whatever), for example, where on the web page should I draw the input box? Let’s take a look at the thread mapping between the browser and React Native.

  • UI thread → UI thread

  • React Native Rendering Engine (Yoga/Shadow Thread)

  • JavaScript thread → JavaScript thread

We know that modern browsers are sophisticated enough to handle all of these tasks efficiently. So why can’t React Native do that? What prevents it from working like a browser?

Expose Native apis directly to JavaScript

Have you ever written commands like document.getelementById and code like setTimeout and setInterval in the console and seen the results printed out? Their implementation results in [native code]. What does that mean? You can see that when you execute these methods, they don’t call any JavaScript code. Instead, these methods call directly into the native C ++ code. So browsers don’t allow JS to use Bridges to communicate with the host operating system. Instead, they use native code to expose the JS interface directly to the system! In a nutshell, that’s what React Native Fabric will do: eliminate bridge communication and use Native code to control the UI directly through the JS thread.

other

  • RN Fabric allows the UI thread (where the UI is drawn) to synchronize with the JS thread (where the UI is programmed)
  • Fabric is still in development, and the React Native team really hasn’t mentioned a public release date as of now. But I’m pretty sure we’re going to see something great this year.
  • Application development frameworks like THIS (RN, NativeScript, Flutter) will get better and better!

Image source: HTTPS://www.slideshare.net/axemclion/react-native-fabric-review20180725