An Overview of the Current React Native Architecture

In this State of React Native 2018 blog post, a future plan for introducing a new architecture to the React Native ecosystem was announced. The upgrade is expected to address the limitations of the current architecture and provide new capabilities to projects using React Native. As of 2022, the new architecture is closer to achieving maturity, while more and more elements of the new ecosystem have become generally available (such as the Hermes engine).  

But before the new architecture arrives, read on to learn more about the current solution and get an analysis of its structure to understand shortcomings that the new solution will address.

Threads and the rendering process 

First, take a look at a basic fragment of code written in React Native:

const HelloWorldComponent = () => {
return <View style={{ flex: 1,
justifyContent: 'center’,
alignItems: ‘center’,
borderWidth: 5,
borderColor: 'red',
backgroundColor: 'yellow' }} >
<Text>Hello, World</Text>
</View>
);
}

You might wonder how this JavaScript (JS) code can produce an application that runs on mobile devices. As it turns out, this code needs to be processed by application trees: 

• First, a React Element Tree is created by React. This tree contains React Elements – pure JavaScript objects that define how the application or a particular view should look like. This is where properties (props), styling and elements hierarchy are defined. 
• Next, a React Shadow Tree is computed. This is the stage where the layout of elements is determined. A React Shadow Tree includes React Shadow Nodes that contain properties from original JavaScript elements, along with layout data. Layout calculation is provided by the Yoga layout engine. 

• Finally, a Host View Tree is constructed. This tree is composed of display elements specific to a particular native platform (Android, iOS) that corresponds with React Native JS elements. 

As a result, three separate structures used in the process of rendering React Native application are created. Each structure exists in a separate thread whose functions are roughly divided in the following way: 

• JavaScript thread – responsible for handling incoming events and rendering the view elements in response to said events 
• Background (Shadow) thread – where the process of calculating layout elements takes place 
• UI (Main) thread – where the application itself is run. It is the only thread that can access user interface (UI) and manipulate it 

The three separate threads exist within their own realms. But how can they communicate with each other? To put it simply – by using the Bridge. 

React Native Bridge

The React Native Bridge serves as an intermediary between threads. It is mostly written using C/C++ and uses a JavaScript engine (JSCore, V8 in debugging) to facilitate communication between JavaScript and Native (machine) code.

The Bridge can be conceptually seen as something similar to a Message Broker, as is works in an asynchronous way and requires serializing data (in the JSON format) between threads. Incoming messages are queued by the Bridge and processed in a first-in, first-out (FIFO) manner.  

Communication between threads is bidirectional. The JavaScript thread handles events coming from the other two threads, while the process of displaying and updating the application view requires data to be sent through the render pipeline. 

Advantages and drawbacks of the React Native architecture

By using the Bridge, React Native can leverage certain advantages. The obvious one is the cross-platform capability that enables you to reuse the same source code to deploy your application on different platforms (mainly Android and iOS). It also makes the development process easier. The architecture lets you hot reload your application during the development process so that you don’t have to recompile the source code every time changes are made, which saves a lot of time.  

However, as the saying goes, there’s no rose without a thorn. The implementation of the Bridge comes with some drawbacks, most importantly: 

• all of the communication between threads is asynchronous, which complicates the usage of native application programming interface (API) components, which expect synchronous processing (Android’s RecyclerView is one example of a tool that faces certain limitations in its usage); 

• the transfer of large amounts of data (such as images and data in the base64 format) can be very slow; 
• data has to be copied between threads instead of being accessed by all threads where it is stored. 

For relatively simple applications, written mostly in JavaScript, these drawbacks are usually not a huge problem, but for more complex projects, closely integrated with native platform APIs, these limitations might pose a serious issue.  

These drawbacks are the reason behind the introduction of a new architecture for React Native – but that’s a story for another time.

React Native architecture – more to come!

This article is meant to provide a general overview of the current React Native architecture and its inner workings and limitations. Having insights into its current state gives you a better understanding of why the new architecture and its components (Fabric, TurboModules and others) are such a big change.  

Since the new architecture is getting closer to becoming a stable solution, we’ll explore it further in future articles to see what is looming on the horizon. 

If you’re looking to develop a React Native application, a team of experienced and engaged engineers can accelerate your software delivery and help you build an outstanding product. At Software Mind, we engineer cutting-edge solutions for companies from a wide range of industries who value high quality and reliable software partnerships. Reach out to us via the form below and find out how our top React Native development talent can boost your company’s growth