The New React Native Architecture Explained
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 first post we discuss the aspect of the re-architecture that will actually affect the code you may write—the new React features and a tool called Codegen.
To help visualise how React Native works, we have prepared this basic graph:
While an intuitive approach to start, and one that has served React Native well for years, the team at Facebook wants to rethink this async message approach to overcome its limitation: to enable this, they are working on a new architecture for React Native. We can describe their strategy as such: to take each of the four core sections of React Native and improve them individually. In this article we’ll explain how the team approached improving the first block, React.
The React Native team largely leverages the work done by their colleagues on the core React library. This means the new React Native will be able to rely on all the new features announced last year at ReactConf 2018 (you can find a comprehensive recap here). In particular, Andrew Clark showcased the concepts of concurrent mode and synchronous event callbacks—available from React 16.6—which, as we’ll see in the third post, enable some important low-level implementation.
The new React feature parity is, for the foreseeable future, the only change of the re-architecture that will affect the code most React Native developers write—by using Suspense to let components “wait” for something before rendering, and Hooks to use state and other React features without writing a class.
In conclusion, if we were to replace this first block of the architecture with its new counterpart, the change would look like this:
This ends the first part of our exploration of the re-architecture. Over the next few weeks we’ll release more posts diving into the other elements. 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 other blocks, and we hope they spark excitement regarding how these powerful changes will impact your codebases, without requiring you to rewrite (basically) anything.
All aboard the hype train!