What is a Bridge in React Native?

A React Native is generally composed of two fields or two parts:

1. The first part is the code of JavaScript.
2. The second one is native code.

The ability to build a bridge between JavaScript code and Native language is a major factor in React Native's success. React Native was created in a way that allows for the creation of a link between JavaScript code and the native language. JavaScript and Native code may communicate with each other thanks to React Native's Bridge. There is simply no way for the native code to communicate any information to the JavaScript code, and likewise, without the React Native Bridge.

Reasons behind using Bridges

The reason we use bridges in React Native is that we want to reutilize the existing libraries of JavaScript.

If we want to reutilize, we can either implement from scratch, but that will be too expensive in production-level code. So, we use React Native Bridges.

Working of the React Native Bridge

When we click on our app icon to launch it, the operating system creates the main thread (also known as a UI thread) and assigns it to our app. The JavaScript thread and the shadow thread are created by this main thread (also known as the shadow tree). Calculating layouts described on the JavaScript side and sending that information to the Native side is the responsibility of the shadow thread. JavaScript is used to lay out views, and the Shadow tree is used to compute them before routing them to the UI thread.

To disable a button, we can configure a JavaScript feature that will direct traffic above the bridge in the form of a serialized JSON object. At the end of each iteration of the event loop, improvements on native views are gathered together and redirected over to the native side.

Data Dispatching

In addition to supplying properties, we can also pass a function that will execute JavaScript code in response to a number of native events (for example pressing the button). This callback in JavaScript is noteworthy since it is serialized and forwarded to the native side. When we click the button, the callback is executed, and the native event is forwarded to the JavaScript domain. Now, without using a callback, we can also directly redirect events from the native side to the JavaScript side.

The problem is that if we start this interaction on the native side, we won't know who is looking at the JavaScript side, which could trigger unwanted actions and make debugging our code challenging. Additionally, unless there is a compelling reason not to, using callbacks on the JS side makes logical.

Execution

The majority of the time, everything moves along smoothly, but occasionally, like an old bridge, there are traffic bottlenecks. Scrolling through an extensive catalog of things, we could notice a blank screen before the remaining items were displayed. This occurs as a result of the onScroll native event being routed to the JavaScript thread, which then sends the updated layout information to the shadow tree for computation before redirecting to the native side.

We quickly skim through the events that result in the traffic bottleneck over the bridge. Pre-calculating layouts can help us get away from this and cross the bridge more than once. We may see similar execution issues while running sophisticated animations. The notion that UI is a function of data is one of the React concepts that underpin React Native, as we have already explored. React notifies you that the condition has to be modified when you transform it.

Let's assume that details flow similarly to the typical React app now. We start with a React section and move on to three sections with more information.

• These section hierarchies are created anonymously by the generation of a Virtual DOM tree.
• React detects that the children's next steps are detailed when the parent section's condition is modified.
• Children are basically a UI representation, so React understands how to group and implement browser DOM modifications.

Let's now separate the Browser DOM and assume React Native does the same in response to calls to Native modules rather than grouping Browser DOM updates.

Consequently, there are two ways to proceed with details for Native modules:

1. Shared mutable data.
2. Native and JavaScript modules exchange serializable messages.