Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
The Slimmening #6
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.
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:
For "pure removal" of old code, this may happen in a "2 version" window instead (ex. the old
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.
C) Who would retain ownership (and "responsibility to maintain") the separated component?
For "extractions", the new repositories will live under the
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.
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.
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?
I think components like
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.
@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.
Remove all components that we think can be deprecated. This is the rows in yellow.
Remove maintained components out of the repo.
Some of the other reasons I think we should do this
@eliperkins - Thanks for taking a look at the idea.
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.
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.
Also be making core components like
If you think these explanations don't make sense, please let me know - I can try to elaborate !!
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.
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
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
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.
referenced this issue
Sep 6, 2018
added a commit
Sep 7, 2018
Thank you for updating the original issue @kelset with some recent changes we have discussed together.
Generally speaking, I really like the direction we are moving towards. I have one comment on the roadmap for deprecating and eventually, removing modules from the core.
As a part of the first step (listed below):
I would also think about removing the module that is the subject of a particular extraction and requiring it from the new module right away. That way, we would automatically opt-in everyone for the latest version of a particular module and make it easy to verify that the newly created API and established release process works without issues.
I would imagine we could print a deprecation message along the following lines:
added a commit
Sep 14, 2018
There's two problems:
Does moving away from the current monorepo solve these problems?
Anecdotally, I've seen separation into many repositories come with problems: it's significantly difficult to perform integration tests, and a non-trivial amount of time is spent assuring versions of packages align -- even with decent tooling. Versioning then becomes a developer concern (although, I guess this is normal in JS projects). Then there's the problem of discoverability: where do folks find the de facto WebView? Can developers easily find the right component?
Just some initial thoughts. Glad to hear this stuff’s being carefully considered.