Move iOS and Android Specific Code to Their Own Packages

[empyrical]

This is a proposal for a new structure the React Native project could take. I consider it to be part of the spirit of the slimmening, and could also lead to more components and apis being able to be moved out of core.

To clarify: this is not a proposal to move IOS and Android to their own repos. They would be in a monorepo, like React and ReactDOM are

https://github.com/facebook/react/tree/master/packages

I have tried to describe as much as I could, but if there is anything else that should be described in this I would be happy to add to it!

I am happy to champion this effort and this would probably be the biggest open source contribution I've done yet, so it will be quite the learning experience.

[empyrical]

I think that the first thing that should be done is land an initial set up of a Yarn workspace. It would both reveal possible places internally where things might break, and would also make it so RNTester could sit in the workspace without being dependant on the progress/acceptance of this proposal. I will look into doing a PR of this.

[empyrical]

Do you mean, like, moving all platform-specific components into userland instead of splitting them out into platform modules?

[kevinvangelder]

Not sure if this should be part of this proposal or not, but other people are discussing it, so I'll throw in my two cents. I think we should avoid ever naming modules with the iOS or Android suffix. Even if the other platform doesn't have the necessary APIs available to complete the module's objective it might in the future, causing a rename when it's implemented, or there may be less-common platforms, such as Windows, that do have the necessary APIs that have to implement the awkward module naming for purposes of supporting cross-platform use of the module. I gather the original purpose of doing this was to make it clear that the module only supported particular platforms even for people too lazy to read the docs, but I don't think the possibility of third-party platforms was considered at the time.

[empyrical]

I highly agree that the platform suffix should be dropped from the names! 👍

However in some cases a platform will need a completely different implementation of a component/API and can't be generic. In cases like that it could just go in the platform module, rather than in the main module. DatePicker... is a good example of this. It's a component on IOS, but an API that summons a dialog on Android.

[kevinvangelder]

Right, but hiding implementation details is exactly what React Native is good at, so as long as the behavior isn't wildly unexpected.

[empyrical]

If there are no objections, I will be revising the proposal to drop the platform suffix from the moved APIs

[grabbou]

Update: We have split CLI into multiple packages (android, ios and core) and it's been the best decision in a while.

I was wondering if there's any outcomes from this PR, such as we're unlikely to implement this architecture or eventually, that's the direction we're going?

[TheSavior]

I think the people on our team at FB want these pieces separated as well. However, this is major refactoring work that can only be accomplished internally, so it’s probably a ways out. Probably at least a year until anything could actually happen here unfortunately. We have lots of other projects we have to focus on first. :-)

[kevinvangelder]

Even if it can't happen for a while, it would be good to solidify the plan.

[larakitb]

I think the people on our team at FB want these pieces separated as well. However, this is major refactoring work that can only be accomplished internally, so it’s probably a ways out. Probably at least a year until anything could actually happen here unfortunately. We have lots of other projects we have to focus on first. :-)

Is there any updates from Meta team around this ? Thanks!

[cortinico]

Is there any updates from Meta team around this ? Thanks!

What @TheSavior mentioned above still stands:

I think the people on our team at FB want these pieces separated as well. However, this is major refactoring work that can only be accomplished internally, so it’s probably a ways out. Probably at least a year until anything could actually happen here unfortunately. We have lots of other projects we have to focus on first. :-)

I don't think we have major updates to share on this side. I believe @rickhanlonii had some opinion on this project and maybe has more to share.

Sharing my personal point of view here: I think that reviving this proposal and trying to land it in some form would be highly beneficial. I feel that the current setup of the repo is slowing us down (i.e. it's complicated to export code to separate packages) + it's hard to understand for newcomers (i.e. why iOS code is inside React and Android code inside ReactAndroid?).

As this RFC looks like a big refactoring, I share all the concerns that were already presented: it should probably be done internally, or at least will require some guidance and coordination from Meta.

To make it a bit more actionable, I believe we could split the whole RFC in three big milestones:

1. Re-organize the project into a proper Yarn workspace - Essentially, having react-native as a top level package and having repo-config/package.json as our workspace is really suboptimal. It introduces a lot of complexity and makes it hard to extract anything inside the package/ folder we currently have.

2. Align versioning of react-native and the other packages we currently have, and let the CI publish them - Currently the versions of react-native we have on main is updated from 1000.0.0 to the needed one whenever we publish a nightly/release/release-candidate. That's not true for the other NPM packages inside packages/ folder. Those packages are following arbitrary version schemas and are published on a "per-need" basis. This means that our nightly versions of RN are not actually using all the code we have on main. Only the react-native package is doing so, other dependencies (i.e. react-native-codegen) are not updated and we might have code on main for them, which is not actually published. I think that we should align the versioning of all the packages to the RN one. Moreover, we should potentially move to having the CI publish all the packages, not only react-native.

3. Modularize react-native. I.e. Split the Android/iOS code into separate packages (react-native-ios, react-native-android and more).

Point 3. seems to introduce a lot of complexity due to implications on how we treat APIs that are platform specific, etc. However, I think that 1. and 2. are potentially doable and would be a first step towards unblocking a proper modularization.

Curious to hear other's opinion here 👍