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?

👋 @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).

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.

@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.

@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 !!

@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" ?

@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.

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.

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

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.

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

here’s the commit: facebook/react-native@0df92af

Expect a properly written PR with the proposal for it, this is a "temporary" post for transparency purposes.

@kelset is this still planned?

No, actually 😅

I'm planning on reworking the top post a bit (based on a couple things discussed during RNEU) but haven't had time yet 🙈 Will do it this week

@turnrye - I think we don't need a top level PR. We could have PRs for individual components that we want to remove and move out - like what we did for webview.

I've updated the top post, let me know / let's discuss about how to make the slimmening better.

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):

version N: the proposal gets merged, new repo gets created and changelog communicates it

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:

WebView has been moved away from React Native core to react-native-web-view package. This version of React Native required that package for you behind the scenes. In the next version, you will have to change your imports to access WebView from that package instead.

@kelset ,NavigatorIOS will be removed in rn-0.58,would you put it in facebookarchive/react-native-custom-components

@linjson I suggest you do it yourself if you still need that component. Or maintain your own version of it.

Does anybody have a rough estimate for impact on bundle size & startup time when removing NavigatorIOS + WebView?

@ricardobeat This tweet by @fkgozali suggests that with NavigatorIOS removed, the savings should be 20kb+. I guess @jamonholmgren would have more info on the webview savings once he has extracted it from core and deleted the necessary code.

That said, since those two extractions will happen as separate times (the full extraction of WebView won't happen in 0.58) I don't think it's too relevant to get a combined "benchmark".

I don't currently have an estimate on savings, but that would be interesting to know.

@ericketts - as someone currently experiencing a migraine, albeit for unrelated reasons, i feel your pain.

also as a maintainer of one of the navigation solutions, i see where you're coming from - asyncstorage and maskedviewios are now two more libraries that we'll need users to install, or we need to instead remove the features that they provide and require users to inject their own tools to do their jobs. that said, i can't see how it would be any better if navigation itself was internal to the react-native repository. it used to be, and it just slowed down iteration speed and made other navigators seem like secondary options because they weren't "blessed" by being part of core, regardless of their merit. further, i think we need to accept the reality that facebook has no interest in maintaining a large react-native core that includes code that they don't use in their apps.

i work on expo and we provide a large set of apis out of the box, and we're also including the packages that are being split out of core (a few will go into our next release in a few weeks or so). in my opinion expo can help a lot with approachability of react-native. other tools like ignite provide opinionated boilerplates and are another reasonable alternative. in general there's an opportunity for the community to build end-to-end frameworks around react-native. react-native will end up as the rendering/plugin layer, and the pieces that are built on top of it will be up to individuals and companies in the community.

my only fear is that the instability from core that we have seen since the start will continue, and folks working with react-native will become fatigued with keeping up to breaking changes and regressions. i imagine it'll get worse before it gets better, with turbomodules and fabric coming and representing a significant change to core, but if this helps us get to a point where the core can be relatively stable it'll be worth it.

i think we need to accept the reality that facebook has no interest in maintaining a large react-native core that includes code that they don't use in their apps

yeah this is really the truth, despite sometimes in the past my trying to pretend its not haha. it also scares the hell out of me for the future of RN as a whole if facebook ever decided that native only is their path forward. I hope the community could and would step up, and I guess this will be something of a test of the potential for that (eventuality of that?) (also you guys at expo are doing some great work for lowering barrier to entry on RN, and I thank you for it, despite having decided to go with a more piecemeal solution for various reasons (some of which contain a bit of irony given the position of my previous post, so I'll edit them... for brevity)).

as you @brentvatne say and I agree, there will likely be growing pains here, and I still have concerns about this project (both on the tech and human sides of the undertaking and results thereof); but there's also a lot of growth going on with RN that looks quite promising, still much to be excited about on the horizon.

I just wanted to get my few cents in, I know others had expressed some of my concerns more succinctly, but the conversation still seemed a bit more in the "yea" camp, so I'll throw my cautious "ehhh..?" into the books.

edit: also hoping your head feels better soon mate, those things are the worst.

the lack of an inbuilt navigation solution for react-native is probably the largest blind spot. any app containing functionality beyond the most trivial use cases will require navigation, and while there are 2 major open source options to fill this role, they both come with their own pitfalls and drawbacks that add cognitive overhead and make RN less approachable.

Let's have this discussion somewhere else, this is not part of the Lean Core process. I understand your frustration but @brentvatne made a great reply.

seeing further pieces of RN stripped off in this manner feels like a step backwards to me. I can certainly appreciate the reasoning behind it, and hell I even agree with that reasoning in a lot of ways and on several points, but I fear that the practical effect will be a net negative on the usability and approachability of RN. just keeping react, react-native, and flow-bin versions synced can be a bit of a headache already... now multiply that a few times and you're looking at a 24/7 blinding migraine.

I agree it may sound counterintuitive but if you look at webview, they (cc @Titozzz) actually managed to merge more than 100 PRs since it's extraction: https://github.com/react-native-community/react-native-webview

Other components like react-native-cli and react-native-netinfo are also success stories: useful modules will find awesome dedicated maintainers who can spend more time on solving a well-scoped problem than we could by mixing everything together. For some of these modules, this is the first time they are receiving real attention. Similarly, this effort also allows us to do a much better job at managing the React Native repo itself. As you can see, the number of open issues and pull requests is as low as it was when React Native was initially open sourced!

I realize though as you point out that there my be a small period of pain until we get everything into order. The new autolinking of native dependencies that will likely be part of 0.60 will help ease the pain though. We won't remove any actual components until then (except WebView).

All that being said: if something is extremely important to people and the separation is causing pain to the community we will consider bringing the module back into core. That reversal would also be a much simpler process :)

(this is slightly off topic so skip it if you're trying to follow the thread)

@ericketts

(also you guys at expo are doing some great work for lowering barrier to entry on RN, and I thank you for it, despite having decided to go with a more piecemeal solution for various reasons (some of which contain a bit of irony given the position of my previous post, so I'll edit them... for brevity)).

we're working towards making expo both a cohesive end-to-end tool while also letting folks who don't want that opt-in in a piecemeal style - more on that in https://blog.expo.io/you-can-now-use-expo-apis-in-any-react-native-app-7c3a93041331.

@michaelknoch what did you guys end up doing re: NavigatorIOS? We have a legacy app that stopped compiling, so we updated react-native only to find NavigatorIOS "deprecated" and "removed". At this point I just want to get the app working again so I can make minor changes.

How is the removal of Webview going to affect those who use RN with Expo.
From what i have seen the alternative of using react-native-webview requires linking which isn't possible with Expo? Is there a timeframe on when Webview is being dropped from RN?

@Shpadoinkle Presumably Expo will include the webview plugin by default like it includes various other native plugins.

indeed expo/expo#3748

support this explain, but i'm very confuse about remove, for example:

CameraRoll has been removed from React Native

and it's really removed from js code, but still remain in native code camera, that's means i can use NativeModules.CameraRollManager get native API， so can i use this? Will the native code be removed in the future？

I expect the native code to be removed for anything where the JS code was removed. If it hasn’t been already then I expect it to in the future.

@TheSavior is correct. We are gradually removing things and you may see some leftovers in some releases. I highly recommend against accessing them as they'll go away soon.

@cpojer
Some APIs have been removed for a long time， such as ART，but native code still remain，if install from community again，there will be double native code，will make the installation package larger， and easy to trigger Android 65535 problem，i think if a componet or api is to be removed，it's better to remove all , include native code