Lean Core

[kelset]

Intro

With this issue I'd like to try and create a "one stop" for all the information available around the discussion that has been going on for a long time within the Core team about this project - and explain the label.

The Gist of it

React Native is currently a huge repo. Would it make sense to move UI components (ScrollView, Switches, WebView) and Native Modules like PushNotifications, etc into a separate repos?

The basic answer is yes, and in the past few months this has started becoming a reality via a few proposals and some commits from the FB team.

You can check the full list of native components that are being considered for extraction/deprecation here, but proposals can also be about JS-only components.

Advantages

• Chance to deprecate older modules
• Make the codebase more approachable
• Reduce the Bundle size for projects that don't use the "extractable" components, which would lead to faster startup times for the apps
• Help the community move fast and enable pull requests to be reviewed and merged quicker
  Reduce the app size effect of adding React Native to an app
• Reduce the size of dev dependencies (this has been criticized in the past)
• Increase community contributions by reducing the size and complexity of the RN repo

Doubts (with "answers" to discuss about)

A) Should we define a roadmap that each "separation" will have to follow?

The rough rule, for now, is to follow this set of steps:

• version N: the proposal gets merged, new repo gets created and changelog communicates it
• version N+1: the component, if used by the main repo, triggers a Warning about deprecation
• version N+2: the code is fully removed and developers will need to rely on the new repo for it.

For "pure removal" of old code, this may happen in a "2 version" window instead (ex. the old NavigatorIOS, removal announced in 57 and will happen in 58).

This is still a WIP so feedback on how to make it better is appreciated. Ideally we'd have a dedicated document with the details on how the flow of an extraction works, so that everyone on the community can understand all the steps involved and can take ownership of a proposal for an extraction.

B) How would this affect platforms like React-native-windows?

Owners of those out-of-tree platforms should be involved in the conversations to ensure a smooth transition.

B1) What's the best way to ensure that Expo is not left behind when the components are moved outside?

C) Who would retain ownership (and "responsibility to maintain") the separated component?

For "extractions", the new repositories will live under the react-native-community umbrella. Details around npm deployment are still being discussed, expect a dedicated issue about that.

For "deprecations/removals" they will be probably be just removed from the main repo, and eventually "ported" to this repository for deprecated-modules by FB by developers that still need it.

---

EDIT: this has been massively edited to provide more informations about the slimmening and reflect the ongoing discussion. And since things are still moving, please keep an eye on this post because it will evolve more.

[eliperkins]

Make the codebase more approachable

I don't know that this will necessarily be the case. If code ends up being spread throughout many modules and repos, it's going to be hard to find exactly the code we're looking for. Having the React Native renderer in the React repo is already an example of this. It's trivial to search the repo now for the specific component you're looking for and find all the code related to it.

Reduce the Bundle size for projects that don't use the "extractable" components, which would lead to faster startup times for the apps

I believe we can accomplish this in ways that don't include separating code in the repo.

Have we explored using Lerna or Yarn workspaces to help alleviate some of this?

[kelset]

👋 @eliperkins I see you points, just want to underline how this is a temp post while the proposal is being written up :)

You should discuss those points there once it's up (which should be soon, @axe-fb is writing it AFAIK).

[satya164]

I think components like ScrollView which are absolutely necessary when building any app should remain in the core. Separating components such as WebView, ViewPager, DrawerLayoutAndroid etc. make sense.

Reduce the Bundle size for projects that don't use the "extractable" components, which would lead to faster startup times for the apps

Metro should support tree-shaking. Then RN can use ES exports which will reduce the bundle size for JavaScript code that's not used.

For native code, on iOS, devs have to include the modules they are going to use, not sure why this isn't the case on Android. But it would help to reduce the native code size.

[axe-fb]

@kelset - I started working on a proposal, but I think that each Native Module and View Manager may be slightly different. Instead of writing one blanket proposal for all components, I think it will be more actionable to write up proposal for sets of components.

I am thinking that the work itself could be done in two phases. Here is a set of Native Modules that I have looked at.

Phase 1

Remove all components that we think can be deprecated. This is the rows in yellow.

Phase 2

Remove maintained components out of the repo.

Some of the other reasons I think we should do this

1. Make upgrading easier - today, a breaking change in ONE component prevents teams from upgrading entire React Native. With massive changes like Fabric, we need the ability to be able to continue upgrading React-Native core, and allowing gradual upgrades of things like native modules.

2. Faster PRs and responding to issues. Though we tag issues and PRs, at this point it seems a lot. Also, moving components outside will also enable other contributors merge in PRs faster. Given the surface of React Native, we do need more help, and need to add to core contributors.

[axe-fb]

@eliperkins - Thanks for taking a look at the idea.
I did look into Lerna workspaces. While it is potentially useful for typical cases of testing, I am not sure how it would really benefit during development. As I understand, most people typically work on a single component at a time, and having the ability to have a simple RN app with just that component may make it more manageable, and will also be easier to get started with.

It's trivial to search the repo now for the specific component you're looking for and find all the code related to it.

I would like to believe that in most cases, the code of a component or native module should live at one single place. Today, JS and Native code is separated, which makes it harder. But putting them all in one repo, it would be much easier to develop/debug.

Having the React Native renderer in the React repo is already an example of this.

I think you are right. We would like to eventually like to move to a world where React is the top level repo, and REact-dom is a renderer, just like React-native, or React-VR. I think that by separating core from components and native modules would help with that.

Bundle Size

Also be making core components like ScrollView or Flatlist at the same level as other components, we can ensure that people who don't use core components remove them like regular components.

If you think these explanations don't make sense, please let me know - I can try to elaborate !!

[axe-fb]

@satya164
Could you please explain "tree-shaking" ?
Could you also please explain the point about "For native code, on iOS, devs have to include the modules they are going to use, not sure why this isn't the case on Android. But it would help to reduce the native code size" ?

[satya164]

@axe-fb

Tree-shaking is when the bundler marks unused imports as dead code which is then removed by the uglifier. Since ES imports are statically analyzable, it's easy to detect which modules are unused and mark them as dead code. All the major bundlers on the web support it, such as Webpack, Rollup, and Parcel. Rollup and Parcel also support tree-shaking on CommonJS modules. Metro doesn't support this feature.

So when you start a React Native iOS project, not all of the native modules and components are linked by default. If you want to use a native module that's not linked by default, you need to link it manually (for example the blob module on iOS is not linked by default). Whereas on Android all of the available native modules and components are already linked by default.

[jamonholmgren]

We used Lerna on a project (https://github.com/infinitered/gluegun) and, while it's a very cool system, I found it wasn't really worth the extra confusion it generated among new contributors.

[gwmccull]

I remember a year ago or so, someone came up with a list of the components that every renderer needed to support if they were going to be able to able to render an app. It was things like View and Text. As I recall, there were around 7 components and a handful of APIs plus the bridge. I think the list may have been put together by the person who built react-native-xp but my google-fu is weak today so I can't find it

All of that to say, it seems like the React Native repo should have the minimal list of components/APIs/code required for every app and then everything else should be in a separate repo

[elicwhite]

At React Native EU today there was a conversation with some of the core contributors around why we haven't removed NavigatorIOS yet. The answer was that it is part of the slimmening effort but just nobody had done it yet.

@fkgozali just put up an internal commit removing it from React Native. That will be landing shortly.