This year, the React Native team has focused on a large scale re-architecture of React Native. As Sophie mentioned in her State of React Native post, we’ve sketched out a plan to better support the thriving population of React Native users and collaborators outside of Facebook. It’s now time to share more details about what we’ve been working on. Before I do so, I’d like to lay out our long-term vision for React Native in open source.
Our vision for React Native is…
We have identified the following focus areas to help us achieve this vision.
Table of Contents
✂️ Lean Core
Our goal is to reduce the surface area of React Native by removing non-core and unused components. We’ll transfer non-core components to the community to allow it to move faster. The reduced surface area will make it easier to manage contributions to React Native.
is an example of a component that we transferred to the community. We are working on a workflow that will allow internal teams to continue using these components after we remove them from the repository. We have identified dozens more components that we’ll give ownership of to the community.
Open Sourcing Internals and Updated Tooling
The React Native development experience for product teams at Facebook can be quite different from open source. Tools that may be popular in the open source community are not used at Facebook. There may be an internal tool that achieves the same purpose. In some cases, Facebook teams have become used to tools that do not exist outside of Facebook. These disparities can pose challenges when we open source our upcoming architecture work.
We’ll work on releasing some of these internal tools. We’ll also improve support for tools popular with the open source community. Here’s a non-exhaustive list of projects we’ll tackle:
✅ Testing Infrastructure
When Facebook engineers publish code, it’s considered safe to land if it passes all tests. These tests identify whether a change might break one of our own React Native surfaces. Yet, there are differences in how Facebook uses React Native. This has allowed us to unknowingly break React Native in open source.
We’ll shore up our internal tests to ensure they run in an environment that is as close as possible to open source. This will help prevent code that breaks these tests from making it to open source. We will also work on infrastructure to enable better testing of the core repo on GitHub, enabling future pull requests to easily include tests.
Combined with the reduced surface area, this will allow contributors to merge pull requests quicker, with confidence.
Public API
Facebook will consume React Native via the public API, the same way open source does, to reduce unintentional breaking changes. We have started converting internal call sites to address this. Our goal is to converge on a stable, public API, leading to the adoption of semantic versioning in version 1.0.
Communication
React Native is one of the top open source projects on GitHub by contributor count. That makes us really happy, and we’d like to keep it going. We’ll continue working on initiatives that lead to involved contributors, such as increased transparency and open discussion. The documentation is one of the first things someone new to React Native will encounter, yet it has not been a priority. We’d like to fix that, starting with bringing back auto-generated API reference docs, creating additional content focused on creating quality user experiences, and improving our release notes.
We’re planning to land these projects throughout the next year or so. Some of these efforts are already ongoing, such as JSI which has already landed in open source. Others will take a bit longer to complete, such as reducing the surface area. We’ll do our best to keep the community up to date with our progress. Please join us in the Discussions and Proposals repository, a initiative from the React Native community that has led to the creation of several of the initiatives discussed in this roadmap.
This content was originally published here.