React Native for React Developers [Part 1: React Native and the new Architecture]

#reactnative #react #newarchitecture #sharingiscaring #KinCarta #WorkingBetter #ForEveryone

Introduction

This Guide is written to help ReactJS developers easily adopt React Native.

Make sure that you fully understand the purpose of this guide, as a guide, meaning that it does not cover all the topics from start to finish, instead there will be some useful links included, and you need to research further more on your own.

Mobile apps vs Web

There are many advantages to creating a mobile app instead of a Website for a mobile device. First of all, with html you can not replicate the same experience of some mobile native elements, like the mobile OS does. For example custom made DatePicker made with HTML will never look and work the same as the one the mobile OS provides. Next, the interaction on the mobile devices differs from the interaction on the web, which assumes that you have a mouse, but on the mobile devices we have the ability to use finger gestures that opens a lot of new possibilities.

What is React Native?

*Explain what is React Native, and the difference between React Native CLI and Expo, and what are some alternatives (Flutter, Xamarin, Kotlin Multiplatform)

React Native is a cross-platform mobile SDK, developed by Meta (former Facebook), and released as an open source project for everyone in 2015.

Since its release, React Native became the most popular framework for building mobile apps, mostly because of the ease of use of the JavaScript programming language, and the single code base for building the app for multiple platforms with a single code.

Learn More…

How does React Native work?

As we have mentioned previously, React Native is a Framework for building cross-platform mobile apps. Unlike some older frameworks like Ionic, which is basically and empty mobile app, with builtin web browser and is running our web app as a standalone mobile app, React Native generates a real Native app, which is using the same components provided by the mobile OS (iOS and Android), not replicating them to look the same, like Flutter does for example, which is rendering every component “pixel by pixel”, and works like a game engine, meaning that in its core it has a replicas of all the System components, iOS and Android provides, which means, when the OS receives an Update, and some of the components are changed, Flutter needs to make that change internally, and then you need to update your Flutter version, make some changes in the code if needed, than push a new update to your app, and when the user updates the app, he will see the new Button, unlike React Native, that uses System provided components, which means when new OS changes some component, the Button for Example, with the update of the OS on your device your app will automatically render the new button.

React Native architecture

With the latest RN version 0.70, React Native has brought the promised new architecture to life (although you were able to try it since 0.68 by changing some flag in the code). In the picture bellow, you can see the differences between the old and the architecture, the old being on the left side, and the new on the right side, and the most important thing to notice is the absence of the famous “bridge” from the new architecture, and some new things like JSI, CodeGen, Fabric and Turbo Modules, and in the following text I will try to explain the problem with the bridge, and all those new things:

• Bridge: the bridge that existed with the old architecture was one of the biggest reasons why meta decided to re-architect the entire React Native core. The bridge was literally a bridge over which the Javascript was communicating with the native code, and all that worked with JSON serialization, so with every interaction in the App, the javascript will send a JSON with some data of the interaction of the user over the bridge, and when it gets on the native side of the “River”, that JSON will than get deserialized, and there was a big issue when you have a lot of interactions from the user, for example when you were scrolling through some big list of items fast, and a lot of the time you will won't see any data in the list just empty white rows for a split of a second, and then they will appear, and this is happening because there were a lot of serializations-deserializations of JSON happening.

• JSI (JavaScript Interface): JSI is basically the replacement for the old bridge, and instead of Serializing-Deserializing of JSONs, with JSI we have a capability to access the native code via C++, so we can directly invoke some native code from JavaScript (for example working with Bluetooth or Camera). Read more here and here.

• Fabric: The Fabric is the replacement for the UI Manager in the old architecture. With the old approach, when we run our application, React will ReactElementTree in Javascript, and based on that ReactShadow tree in C++ will be created on the Native side, and based on this Shadow tree the Layout Engine will calculate the positions of all UI elements and will create HostViewTree which consists of the actual Native Elements (View becomes ViewGoup for android and UIView for iOS etc.). The communication between this different threads (JS and Native) happens over the bridge, which we already know was an issue, because of Serialization-Deserialization of JSONS which is performance expensive operation, but also means that we are keeping two copies of the same date on both sides of the bridge. Also because the crossing of the bridge is slow when there is a lot of traffic, because as we said we had two copies of the same date, until our JSON crosses the bridge our data will be out of sync, and as we mentioned previously because of this problem, sometimes when we scroll large lists, the scrolling will be laggy and we won't see the date for part of a second. Well Fabric solves this issue with the help of JSI, so Fabric will allow JS and UI threads to be in sync, which means that the user interactions will be prioritized and will be executed synchronously in the main or the native thread, while other tasks like API request will be executed asynchronously. Also now the Shadow Three will be immutable and shared between JS and the UI threads. Read more here and here.
• Turbo Modules: In the current architecture, all the Native Modules used by JavaScript (e.g. Bluetooth, Geo Location, File Storage etc) have to be initialized before the app is opened. This means, even if the user doesn’t require a particular module, it still has to be initialized at startup.

Turbo Modules are basically an enhancement over these old Native modules. As we have seen in the previous part of this article, now JavaScript will be able to hold references to these modules, which will allow JS Code to load each module only when it is required. This will significantly improve startup time for React Native apps

• CodeGen: All this talk of Turbo Modules and Fabric sounds promising, but JavaScript is a Dynamically typed language, and JSI is written in C++, which is a Statically Typed Language. Consequently, there is a need to ensure smooth communication between the two.

That’s why the new architecture will also include a static type checker called CodeGen.

By using the typed JavaScript as the source of truth CodeGen will define interface elements used by Turbo Modules and Fabric. It will also generate more native code at build time, instead of run time.

React Native for React Developers [Part 1: React Native and the new Architecture]

React Native for React Developers [Part 2: React Native CLI vs Expo]

React Native for React Developers [Part 3: Setting up Dev Environment]

React Native for React Developers [Part 4: xCode and Android Studio]

React Native for React Developers [Part 5: Core Components, Styling, Platform Specific Code, Permissions and Custom Fonts]

React Native for React Developers [Part 6: Navigation: Stack Navigation]

React Native for React Developers [Part 7: Navigation: Bottom Tab Navigation]

React Native for React Developers [Part 8: Navigation: Deep Links]

React Native for React Developers [Part 9: Push Notifications: iOS]

React Native for React Developers [Part 10: Push Notifications: Android]