The New React Native Architecture Explained: Part Two
First announced in 2018, the React Native re-architecture is a massive effort Facebook undertook to address some long-standing issues of this cross-platform mobile solution.
In this series we will give an overview of the main elements that comprise React Native’s new structure. We will avoid showing code, to keep this explanation as accessible as possible, and will share our excitement regarding this new implementation.
In this second post we will dive into how React Native consumes the code you write, and how the re-architecture changes it.
The first one is fairly intuitive—potentially, the JSC could now be swapped out more easily for other engines (or newer versions of the JSC, as recently happened in RN 0.59). Other options you may know are ChakraCore by Microsoft and V8 by Google.
So this re-architecture step of React Native both enables massive changes to the current structure and opens the door to write more C++ for your apps, also enabling easier brownfield approaches.
If we were to replace the second block of the architecture with its new counterpart (you can find the full graph in the first article), the change would look like this:
This concludes the second part of our exploration of the re-architecture. Over the next few weeks we’ll release more posts diving into the other blocks. In the meantime, remember to share this article with your fellow developers or reach out for follow-up questions over on Twitter (DMs are open).
As you can imagine, these changes open the door to many more improvements in the next block, and we hope they spark excitement regarding how they will impact your codebases, without requiring any rewrites.
All aboard the hype train!