» » React Native 0.68 and "new architecture"

React Native 0.68 and "new architecture"

On March 30, 2022, the Meta engineering team announced a new version of React Native 0.68. In addition to various minor improvements and fixes, this version contains a historical change for the platform, for the first time we can try the so-called new architecture in our applications. Let's figure out together what kind of new architecture is and why it took almost 4 years to get to it.

How React Native Works

React Native is a set of tools, libraries and components that allow a developer to create applications with a native interface and logic running on a JS engine.

The following modules are responsible for building the application:

  • BUCK - multi-platform build system

  • Metro bundler - JS bundler written specifically for React Native

  • React Native CLI - a set of utilities for building an application for a specific platform

At runtime, the following are required:

  • JS Core or Hermes - engines that run JS code

  • Yoga layout - cross platform layout manager with syntax close to css flex box

  • ReactJS and React Native - the core of the application, responsible for rendering on the JS side and interacting with the native layer

And so we put together the RN application. What happens under the hood?

 

  1. User clicks on the application icon

  2. Native Thread load all native dependencies and modules

  3. Native Thread starts JS Thread which loads the built js bundle

  4. The JS Thread sends a serialized message through Bridge about how to render the UI on the native side.

  5. Shadow Thread receives these messages and forms the UI Tree

  6. Based on the UI Tree, the Yoga layout manager generates native components with dimensions for a specific platform and device and passes them to the Native Thread for rendering

  7. Native Thread draws components on the screen. Below is an example of mapping RN components to platform-specific components.

 

User interaction occurs in the same way, the Native Thread is responsible for processing gestures and sends information about the event through the Bridge to the JS Thread where the new UI state is calculated and steps 4-7 are repeated.

Problems of the old architecture

In 2018, the RN team announced the start of a major work on the creation of a new architecture. The main problem seemed to be asynchronous Bridge

  • a large number of events passing through the Bridge and requiring serialization / deserialization can serve as a bottleneck and cause slowness in the UI

  • the asynchronous nature of Bridge prevents it from being used effectively with synchronous native components

  • since communication between Native and JS happens via message, JS can't efficiently manage Shadow Thread directly since Shadow Thread doesn't know anything about JS side data structures

New architecture

Schematically, the new architecture looks like thisYou've probably noticed a lot of new names, let's take a look at each of them.

 

You've probably noticed a lot of new names, let's take a look at each of them.

JSI - jаvascript Interface replacement for Bridge. With JSI, you can directly interact with native modules, avoiding the overhead of message forwarding. Through JSI, native methods will be available to jаvascript through C++ host objects. These host objects can contain both independent functionality in C ++ and act as intermediaries for interacting with a native platform, for example, in Objective-c or Java via JNI. It is important that JSI methods can be both synchronous and asynchronous.

Fabric is a new rendering system that replaces UIManager. Thanks to JSI, now you do not need to keep a copy of the component tree on JS and Shadow thread and synchronize it through Bridge, but you can manipulate this tree directly. Fabric makes UI work synchronous and also prioritizes UI tasks over asynchronous calls such as HTTP requests or IO operations.

Turbo Modules - in the current architecture, all modules for working with native functionality (Bluetooth, Geo, Camera, etc.) must be loaded at application startup time. In practice, this significantly slows down the application start time. Turbo Modules eliminate this problem and allow you to load native modules when you need them in your application. Another advantage is the use of JSI for communication between the module and JS.

CodeGen - makes it easy to create native interfaces to work with Turbo Modules and Fabric. Using Flow or TypeScript, the module developer describes its interface, and the C++ code will be generated automatically.

Now, in the new scheme, the JS Thread is much more directly integrated into different processes directly, you can communicate with several modules in parallel without waiting for a response in the form of a message through the Bridge as it was before.

You can read more about how the new rendering works on the React Native website in a special section .

How to use in practice?

In practice, to support the new architecture, we must ensure that all native modules work.

Inside React Native, all components already support the new architecture, and if you are going to create a new application or just want to experiment with a new architecture, then this instruction will be useful .

If you are a developer of RN libraries or you have your own native modules, then following this instruction you will be able to adapt your library. The following libraries can serve as a good example of the implementation of the new architecture:

What about existing applications? My feeling is that it will take another 6 to 12 months for the library developers to adapt them to the new architecture. One thing can be said unequivocally - this new architecture is the reality in which we are already. Do not ignore it, help the community, experiment and it will positively affect both your project and your experience with React Native.

Useful materials

 

 

Related Articles

Add Your Comment

reload, if the code cannot be seen

All comments will be moderated before being published.