Deep dive into React Native’s New Architecture

Current React Native Architecture

The native and JavaScript worlds frequently interact with one another when we look at the react native architecture in the current situation. As we are all aware, React Native aids in developing cross-platform applications by enabling the creation of native parts that are simple for natives to comprehend. Therefore, we cannot execute any type of manipulation using React because we lack direct access to the node of that constructed element. In what ways do the two worlds communicate? The React Native bridge is how this two-way communication takes place. Through that bridge, React Native converts the collection of commands coming from the React world into a JSON array, serializes it as a string, and then sends it to the native world.

React Native handles the actual layout by translating React-based display styles (for example, flex) to the relative position values where each element is to be structured before passing it over the UI layer of the native world to ensure uniformity across all platforms. The current React Native design is primarily built on three main threads:

• Native code is run in the central/Native/UI thread, which renders all UI elements.
• The layout thread, often known as the shadow thread, is the one that calculates the actual layout. It uses the Yoga layout engine from Facebook to recast the flexbox layout, as was already mentioned.
• Executing and compiling all JavaScript-related code is the responsibility of the JavaScript thread.

Emerging of JSI

Due to their necessity for excellent performance, JavaScript runtimes like JSC, Hermes, and V8 are written in C and C++. C++ APIs that can communicate with the native side has been developed by developers that want to take advantage of this circumstance. It was given the name JSI. To a JavaScript Runtime, JSI offers an abstraction layer. This layer can be compared to the interface notion used in object-oriented languages. These languages allow you to design functions that the interface’s classes must override. A number value can also be sent directly from the C++ side to the JavaScript side without type conversion by carrying out this action on the JSI side.

Differences between the bridge and JSI

In conclusion, we may state that Bridge will be replaced by JSI technology. While both JSI and Bridge will be used in projects for the foreseeable future, Bridge will soon be replaced, and all native modules will use JSI. Since JSI offers quicker and more direct access to the JS runtime, it produces a more efficient structure than Bridge.

Contrarily, with Bridge, communication between the JS and Native sides occurs asynchronously, messages are processed in batches, and the await keyword is necessary for a straightforward operation like adding two numbers.

They can also be utilized in top-level scope because everything in JSI operates synchronously by default. Of course, asynchronous methods can be developed for lengthy activities, and promises are simple to use. Because JSI accesses the JS runtime, remote debuggers like Chrome cannot be used. Instead, we may debug our applications using the Flipper Desktop software.

We don’t need to use the JSI directly or be familiar with C++ internals because the JSI evolved into an abstraction layer for native implementation. As before, we merely call native functions from the JS side. The Native Modules API and the Turbo Modules API are very similar. As a result, every existing Native Module in the RN ecosystem may be quickly converted to Turbo Modules without starting from scratch.

Standpoint on React Native

React Native, a cross-platform technology used to develop the Wix Mobile Application, enables programmers to create mobile apps using JavaScript declaratively. We must fully comprehend React Native’s fundamental architecture to scale a production-grade application using such a new technology without sacrificing performance and development speed.

New Architechture: React Native

The new architecture replaces the React Native bridge with a new layer called JavaScript Interface (JSI). Thanks to this layer, the synchronization of the Javascript thread and native modules is now achievable, which will let the native and Javascript worlds directly communicate.

JSI-based architecture benefits include:

Turbo Modules:

The first benefit of this layer is that JS can keep track of the references to host objects and call their methods as needed. Therefore, even before the app is opened, we do not need to pre-load the native modules that JavsScript uses. Additionally, the additional serialization burden currently exists in Bridge-based architecture is eliminated.

Fabric

The rendering system that will take the place of the current UI Manager is called Fabric.

Let’s first take a look at the benefits of Fabric by examining how UI is now produced in React Native:

React runs your code and generates a ReactElementTree in JavaScript when your app is launched. The Renderer builds a ReactShadowTree in C++ based on this tree.

The Layout Engine uses this shadow Tree to determine where UI items should be placed on the host screen.

The shadow tree is converted into a hostviewtree, made up of Native Elements, once the results of the layout calculation are known. (For instance, ViewGroup on Android & UIView in iOS will be translated from the ReactNative View/> element, respectively.)

Fabric is React Native’s new delivering framework is a calculated expansion of the old render framework.

The JavaScript Interface will straightforwardly open local strategies to JavaScript, including UI techniques, as found in the JSI part of this article. The JS and UI strings can then be in a state of harmony subsequently. Execution for records, route, signal dealing with, and so on will increment.

What benefits does Fabric offer?

The Shadow Tree method, which enables renderers to display only the portions of our program that have changed, will be moved to the native realm by Fabric utilizing C++. Fabric will profit from React’s concurrent rendering approach to be able to do that.

• The renderer can focus on unambiguous client associations to guarantee they are dealt with expeditiously because of the accessibility of multi-need and simultaneous occasions.
• Server-side rendering for React Native is simpler to develop.
• The new render system’s consistency is cross-platform, making it simpler to maintain consistency across many platforms.

CodeGen

Notwithstanding how energizing the present chatter about Turbo Modules and Fabric appears, JavaScript is a progressively composed language, while JSI is created in the statically composed language C++. As a result, it’s essential to guarantee effective communication between the two.

The new architecture will, therefore, also feature a static type checker named CodeGen.

The interface elements utilized by Turbo Modules and Fabric will be defined by CodeGen utilizing typed JavaScript as the source of truth.

Conclusion

JSI will improve the modules’ performance and the programs that use them. We don’t believe that JSI will impact standard React Native app development because it is only modifying infrastructure. However, if you’re a library maintainer, we believe learning C++ and converting a straightforward library to JSI will be helpful.