RetroSearch Browse

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/react-native-community/discussions-and-proposals/issues/6 below:

Lean Core · Issue #6 · react-native-community/discussions-and-proposals · GitHub

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.

xcarpentier, brentvatne, jamonholmgren, mshustov, todorone and 101 moreconnlark, ralph-dev, Monte9, JCMais, RSNara and 17 morekrizzu, tylerthebuildor, grabbou, trietbui85, faizalshap and 23 morenewerton

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4