React-native: ☂️ Lean Core

Created on 6 Feb 2019  ·  196Comments  ·  Source: facebook/react-native

For the past several months we have been discussing and making progress on a project called “Lean Core”. Please read our motivation for this project. Over the years React Native has accumulated a lot of parts that are now outdated, unused or otherwise legacy. It's time to clean everything up and put the repository into a much more manageable state going forward.

This is an umbrella task intended to track all the work necessary to reach the goal of a leaner core, including work around repository reorganization. This issue is being kept up to date so new items will be added and completed ones will be (re)moved. Some of the items will spawn separate issues to track work. If you don't see a name assigned to any of the below items and you would like to help out, please volunteer in the comments and reach out to me to get started!

Components & Runtime

React Native currently comes with a large number of components, many of which are deprecated or outdated but they still part of the repository and increase the size of applications. For items in this section we are either looking to completely remove things if they are unused, or we'd like to move them either to community managed repositories or otherwise to facebookarchive. The list here is partially based on an awesome investigation by @axe-fb. The migration can be done roughly by following @matt-oakes's guide from further below: https://github.com/facebook/react-native/issues/23313#issuecomment-461462981

  • [ ] Remove ImageStore (@cpojer)
  • [ ] Remove PushNotificationIOS (@cpojer)
  • [ ] Remove AsyncStorage (@cpojer)
  • [ ] Remove Slider (@cpojer)
  • [ ] Remove ProgressBarAndroid (@cpojer)
  • [ ] Remove ProgressViewIOS (@cpojer)
  • [ ] Remove MaskedViewIOS (@cpojer)
  • [ ] Remove ActionSheetIOS (@cpojer)
  • [ ] Remove ImagePickerIOS (@cpojer)
  • [ ] Remove Picker and PickerIOS (@cpojer)
  • [ ] Remove DatePickerAndroid, DatePickerIOS (@cpojer)
  • [ ] Remove ReactART (@cpojer)

Third-Party Dependencies

Over the years we have amassed a large amount of dependencies, especially JavaScript. We have also moved things out of React Native, like Metro and the react-native-cli. This means we left a large amount of tooling dependencies in our package.json, many of which will are unused by RN itself and won't be updated to the latest versions, causing the full install of React Native to be bloated. It would also be great to do an audit of all the dependencies that are used and identify which ones could be removed.

  • JavaScript Dependencies

    • [ ] Check which dependencies are large and whether they can be made smaller

    • [ ] Figure out which dependencies can be upgraded to their latest versions for security fixes

    • [ ] Figure out which dependencies can be deduplicated (= reduce version mismatches) for smaller install size

  • Move React Native code to external dependencies

    • [ ] Identify which JavaScript code could be better served by a third-party package instead of maintaining a copy or our own implementation

Repository Structure

Right now the React Native repository is a large repository with little organization that promotes separation of concerns. It is our goal as part of this effort to also move things into a more manageable structure. As part of this, we'd like to follow a monorepo model that consists of multiple smaller packages. This will be a gradual migration and we will only be tracking the initial work to get this off the ground.

  • [ ] Provide an initial setup that works with the existing repository, with multiple packages and also plays nicely with Facebook's internal setup (@cpojer)
  • [ ] TODO: Identify more work necessary in this area

Completed work


Click to see prior work before this issue was created

Good first issue Help Wanted Ran Commands Discussion

Most helpful comment

I wanted to give a quick update on the progress everyone has been making on the Lean Core effort. I just wanna say how blown away I am by all your contributions in just over a week. Thank you so so so much!

Here is all the work that is already completed:

  • NetInfo (https://github.com/react-native-community/react-native-netinfo) was successfully split out and released on npm via @react-native-community/netinfo by @matt-oakes, who even added new tests and new features to the module!
  • ViewPagerIOS (https://github.com/react-native-community/react-native-viewpager/pull/1) was successfully split out by @ferrannp.
  • AsyncStorage (https://github.com/react-native-community/react-native-async-storage) was pulled out by @Krizzu.
  • StatusBar (https://github.com/react-native-community/react-native-statusbar/pull/1) was moved into a separate repo by @dmtrKovalenko.
  • Slider (https://github.com/react-native-community/react-native-slider/pull/1) was split out by @michalchudziak.
  • MaskedViewIOS (https://github.com/react-native-community/react-native-masked-view/pull/1) was turned into a community repo by @FonDorn.
  • PushNotificationIOS (https://github.com/react-native-community/react-native-push-notification-ios/pull/1) was extracted by @rafaellincoln.
  • ImageEditor (https://github.com/react-native-community/react-native-image-editor/pull/1) was extracted by @Trancever.
  • @EvanBacon added a deprecation message for ImageStore in #23330.
  • @wellmonge merged AlertIOS and Alert in #23318.
  • Callstack engineers released the first version of the new React Native CLI: https://blog.callstack.io/the-react-native-cli-has-a-new-home-79b63838f0e6

I also want to highlight how extracting these modules can lead to better maintenance of those modules, ie @matt-oakes added tests for NetInfo (https://github.com/react-native-community/react-native-netinfo/pull/4) and @ifsnow added Flow types to AsyncStorage (https://github.com/react-native-community/react-native-async-storage/pull/4). By decoupling these components from React Native (and Facebook), they can move much faster individually without being blocked by a Facebook employee. Further, because we can migrate existing issues and Pull Requests from the React Native repository, it will also make it easier to maintain React Native itself and we'll be able to respond to pull requests faster!

This is what we are working on or working on next:

  • Remove VibrationIOS
  • Remove unused third-party dependencies
  • Start migrating Facebook internal code to use the new react-native-community packages

Again, to everyone who has been helping so far, thank you!

All 196 comments

@cpojer I'd like to remove SnapshotViewIOS 🔪

Hey @cpojer, thanks for putting it all together!

I'm willing to tackle few issues, starting from moving AsyncStorage.

I would be happy to help with moving NetInfo to a community repo.

Would it be best to create a personal Github repo first and then potentially migrate that to the react-native-community org once it's ready, or should we start right away with a repo in that org?

@cpojer, I'd like to help at some of this issues, could I start with "Merge AlertIOS with Alert"?

That's awesome! I put your names down next to the items above.

@jdmunro can you send a PR and assign me to it? Then I can take it over and remove FB specific stuff before landing.
@Krizzu and @matt-oakes I created https://github.com/react-native-community/react-native-async-storage and https://github.com/react-native-community/react-native-netinfo for you to send PRs against with all the code necessary to make them third-party modules. Ideally in the first step, you'll just take the code from the RN repo and put them in separate repos. In order to ensure it works, we could then link them back into RN as a dependency and remove the original implementation. Further down the line we can actually move it to an optional package.
@wellmonge Sounds great! I'm not sure entirely what the work will entail but maybe you can just check out the two modules and see if you can unify them?

@cpojer I could help with moving slider 🙂

After that I can pick up something else if you’ll still need some help

@michalchudziak Awesome! I created https://github.com/react-native-community/react-native-slider, please see my comment above on what to do next.

As a name for the project in package.json, please use @react-native-community/<project name>, ie. @react-native-community/slider.

@cpojer I can take ViewPagerAndroid. I think better moving it to a community repo (if you can create the repo for me, thx 😄) than just removing it because other packages around have implemented this behaviour on JS for iOS and they relay on the native one for Android.

Hey @cpojer I would like to help by merging and moving Picker and PickerIos. :)

@ferrannp created https://github.com/react-native-community/react-native-viewpager for you! See the messages above.
@jainkuniya thanks! Not exactly sure what that will look like but maybe you can see how to unify them and start sending small PRs to react native.

That's awesome! I put your names down next to the items above.

@jdmunro can you send a PR and assign me to it? Then I can take it over and remove FB specific stuff before landing.
@Krizzu and @matt-oakes I created https://github.com/react-native-community/react-native-async-storage and https://github.com/react-native-community/react-native-netinfo for you to send PRs against with all the code necessary to make them third-party modules. Ideally in the first step, you'll just take the code from the RN repo and put them in separate repos. In order to ensure it works, we could then link them back into RN as a dependency and remove the original implementation. Further down the line we can actually move it to an optional package.
@wellmonge Sounds great! I'm not sure entirely what the work will entail but maybe you can just check out the two modules and see if you can unify them?

Sure! I'll do that and report to you.

Can help with StatusBarIOS and PushNotificationIOS

@cpojer Do you have a preference for the Android package name?

Using NetInfo as an example it is currently com.facebook.react.modules.netinfo. Should we make it standard across all extracted modules with something like com.reactnativecommunity.modules.netinfo?

Can I help with

  • Move SegmentedControlIOS to a community repo
  • Move ProgressViewIOS to a community repo

I'll take the checkbox, please.


Thanks for submitting your issue. Can you take another look at your description and make sure the issue template has been filled in its entirety?

👉 Click here if you want to take another look at the Bug Report issue template.

@dmtrKovalenko put you down for StatusBarIOS, created https://github.com/react-native-community/react-native-statusbar
@matt-oakes community in the package name sounds good but if we keep the existing one I'm fine with that too.
@kdenz Created https://github.com/react-native-community/react-native-segmented-control for the SegmentedControlIOS
@vonovak Created https://github.com/react-native-community/react-native-checkbox for the checkbox repo

Just to summarize the rough steps that we should take for the extractions:

  1. Extract the current version of the module you are working on and all of it's dependencies into a separate git repository, and send a PR to the one that was created for your in RN community. See react-native-webview for an example of how it should work if it contains native code.
  2. Add a deprecation warning to React Native using the warnOnce module that already exists, see react-native-implementation.js for an example.
  3. We'll then close all issues/PRs and direct people to use the newly created projects and repositories instead.
  4. After a release or two we will entirely remove the code from React Native, at which point only the external module will work.
  5. Alternatively, we can try an approach where we will remove the code from the RN repository immediately, but add the new community repository as a dependency to React Native and keep the existing APIs working the way they are. I'm unsure whether that will work for modules with native dependencies, though.

Please let me know if you have any questions :)

  • Move ImageStore to a community repo

I think we should deprecate this in favor of any existing FileSystem solution. The core use-case is getting Base64 from an image. It also has no android support.

Hey @cpojer! I would help with

  • Remove MaskedViewIOS and possibly move to community repo

I'd like to help out!
Could I work on

  • Remove ProgressBarAndroid from the repository, possibly move to community repo
    ?

Hey @cpojer! Could I help with

  • Move ActionSheetIOS native code to expo.

@cpojer I'd love to help, sign me up for Libraries/CameraRoll (ImagePickerIOS and CameraRoll components)

The RNTester app doesn't have its own package.json so any components that we remove would have to either be removed from the RNTester app or needs to remain in the core as a dependency. What is the approach for RNTester with regards to this slimmening?

@cpojer I can help with moving Clipboard to a community repo :)

Could I help with this task? @cpojer

  • Move Picker to a community repo.

@jainkuniya Maybe we can work together?

@zhaozhiming ya sure, what I was planning is to first merge it in RN repo itself and then move to community repo.

Interesting. What will happen to the RNTester? I hope we can keep it with all the components.

@cpojer I can help with

  • Move "Share" to community repo

Also, it would be very helpful to have some kind of coordinated template, so there is the native code as a lib, an easy way to develop it and contribute.

@pvinis Maybe take a look at this commit from the NetInfo repo I'm working on:

https://github.com/matt-oakes/react-native-netinfo/tree/83e96b30fda1c18f62d27ec0db61db7f56eddc1f

There's no NetInfo code there yet, but it has the Android and iOS parts of the library and an example project which links through without needing a nested package.json.

I'm now planning to move the NetInfo code in and then move the RNTester examples into the example project.

@EvanBacon sounds good. Do you wanna sign up to add a warning to RN to deprecate ImageStore and recommend a third-party solution?

@matt-oakes has been done a great job with NetInfo already, that's a model to mirror for all the extractions: https://github.com/react-native-community/react-native-netinfo/pull/1

@pvinis as @matt-oakes says every project should have its own examples and testing code. I think once we are all done we can consider creating a single RNTester example that pulls in all the most commonly used extracted modules and brings them together into a single app.

VirtualizedList is staying, right? I saw it before in the list but I see it's not anymore.

Hey @cpojer I can take care of moving ImageEditor to separate repo.

Hey @cpojer I would love to work on this one

  • Identify all dependencies in package.json that aren't directly used in React Native

@matt-oakes how are you planning to test or help with developing this lib? we need a project that incorporates the lib, that can be easily updated/disposed-and-recreated or something.

It would be easy this way for others to contribute. It could be an "example" app, but to my mind an "example" app is for showing how to use a lib, where a "dev" app would be where the lib can be developed, tested etc.

Any ideas for that?

@brunolemos yes it is, sorry my mistake for putting it in there at first.

@Trancever I created https://github.com/react-native-community/react-native-image-editor for you to send a PR against!
@nimish-gupta that's awesome! Can you do the analysis and create a separate issue that discusses the unused dependencies; or otherwise send a pull request with clear explanations on why they can be removed (ie. they cannot be found etc.)
@pvinis we are currently discussing whether it makes sense to create a scaffold. Until we have that, basing your work off of the structure in https://github.com/react-native-community/react-native-webview or https://github.com/react-native-community/react-native-netinfo makes the most sense to me.

hi @cpojer for the PickerIOS and Picker project, I am planning to go with following steps:

  • Add a warning in the PickerIOS, that it is deprecated and will be removed in further release.
  • After the release remove PickerIOS from RN.

In the mean time we can move Picker to community repo.

Suggestions?

@jainkuniya I think the idea is good but keep in mind that Picker uses PickerIOS under the hood. I think it would be best if we could get rid of PickerAndroid and PickerIOS and instead only expose Picker, what do you think? A lot of other components already work this way.

To give people an idea of the process I went through to move the NetInfo code:

1) Used create-react-native-library to generate the scaffolding: npx react-native-create-library --platforms ios,android --package-identifier com.reactnativecommunity.netinfo --prefix RNC --license MIT netinfo
2) Created an example project by running react-native init NetInfoExample in the root of the new library project. I then renamed the created folder to just example.
3) Removed the example/package.json and moved the dependencies and scripts into the root package.json. I also moved some of the other generated files like babel.config.js into the root of the project.
4) Updated the references to React Native libraries in the examples Android gradle files and the Xcode project. Doing a find and replace for ../node_modules/react-native and replacing it with ../../node_modules/react-native was enough.
5) Updated the path to the main module name in MainApplication.java and AppDelegate.m from index to example/index.
6) Added the babel-plugin-module-resolver modules and configured it like this in babel.config.js. This allows you to import the library code in the same way as a user would.
7) Manually linked the library project with the example one. This is very similar to how you would usually do it, but the path on Android in settings.gradle will just be ../../android (like this).
8) I then moved the native code files, renaming them with an RNC (React Native Community) prefix instead of the old RCT. I placed the Javascript code in js and changed the index path in package.json.
9) I then moved the examples from RNTester into the example project and tidied up the code a bit. Feel free to grab the example/index.js file as a way to contain the examples you copy over from RNTester. It's just a lightweight wrapper like there was in RNTester originally.
10) I did tidy up the project a little bit to make it match how react-native-webview is set up. The main changes were around the Android gradle files.

Hopefully, that helps people :)

@pvinis I think there is a lot of crossover between showing people how to use the library and helping with development, especially when the surface area is small like with NetInfo. The example in the project pretty much fulfils both purposes at the same time.

For automated testing, I've not looked into it fully yet, however, I have previously used Jet (based on top of Detox and used by react-native-firebase) to do end-to-end testing with react-native-location.

Awesome. I did the same process a few days ago when trying to extract some app functionality to a lib. I didn't do the package.json deletion and a couple of other small steps. I will try and check everything you did and I did, and see if there are still unclear things.

Thanks for the details. :)

@cpojer SnapshotViewIOS seems also to be used internally for some iOS integration tests. It's only available if you link against the RCTTest native module. Usage is here: https://github.com/facebook/react-native/blob/master/RNTester/js/RNTesterApp.ios.js#L180

Are we just removing SnapshotViewIOS from the public RN export, i.e. it should still be available privately for the test usage?

There was some discussion about how to keep the history of the files which are being imported. I found this guide which was really useful and allowed me to do it for the NetInfo module:

https://stosb.com/blog/retaining-history-when-moving-files-across-repositories-in-git/

As a summary, you first need to find out which files you need to copy over. You then create a script like this:

#!/bin/bash

mkdir -p combined/

# Pipe output to silence "file not found" warnings.
mv ReactAndroid/src/main/java/com/facebook/react/modules/netinfo/NetInfoModule.java combined/ 2>/dev/null
mv Libraries/Network/RCTNetInfo.h combined/ 2>/dev/null
mv Libraries/Network/RCTNetInfo.m combined/ 2>/dev/null
mv Libraries/Network/NetInfo.js combined/ 2>/dev/null

true

You should put this file somewhere outside the repository.

You then need to run these commands:

git fetch origin --unshallow
git checkout -b history
git filter-branch -f --prune-empty --tree-filter ~/treefilter.sh @
git filter-branch --prune-empty -f --subdirectory-filter combined

The first filter-branch command will take a while and will use the script to move all of the files you're interested in into a single folder. The second command should be fairly quick and will move the files from the new folder to the root and then keep only the commits that alter any of the files you want to keep.

You can then end up with a history like this: https://github.com/react-native-community/react-native-netinfo/commits/master

hi, @cpojer I would love to work on

  • Move ProgressViewIOS to a community repo

Thank you

Note on the fetch polyfill:

Remove the fetch polyfill from the repo and re-use whatwg-fetch directly if possible

We had to fork it because our Blob module is not standard and doesn't automatically release its resources. It should be easier to implement automatic resource cleanup with the new native modules system but until then we should keep the forked polyfill.

@cpojer Move "Share" to community repo is currently points another repository which has a rich feature set than the share inside the react-native. So I would like to have a new repository named like react-native-simple-share or something like that.

Please have a look at this branch (I will delete this repo once we get a new community repo)

Note on the fetch polyfill:

Remove the fetch polyfill from the repo and re-use whatwg-fetch directly if possible

We had to fork it because our Blob module is not standard and doesn't automatically release its resources. It should be easier to implement automatic resource cleanup with the new native modules system but until then we should keep the forked polyfill.

Since I need AbortController.Signal support I was looking into doing an update to the forked polyfill. Would that fit with the future of the fetch polyfill inside core?

@cpojer I would like to work on PushNotificationIOS.

@cpojer i could help with

  • Move ImageEditor to a community repo

Thanks!

@nicholaslee119 Created https://github.com/react-native-community/react-native-progress-view for you. Check the comments above on how to make progress.
@Ansalibrahim Good point. Created https://github.com/react-native-community/react-native-simple-share for you. Please send a PR there!
@rafaellincoln Created https://github.com/react-native-community/react-native-push-notification-ios for you to work on.
@dratwas @Trancever is already on it, please work with him on the repo that was created for it.
@Jyrno42 Could we upgrade to a third-party polyfill that supports all the stuff we need?

@cpojer Sorry i didn't see that @Trancever is on it.
I could take Move ImageStore to a community repo if it is not already taken or Move ImagePickerIOS to a community repo

Could somebody tell me why AsycnStorage and PushNotificationIOS will be removed? I think those are both used by a lot of apps, so maybe we could move them to the community instead of just removing?

Especially PushNoticationIos is used by a lot of people. I'm using https://github.com/zo0r/react-native-push-notification which is using PushNotificationIos. Is there a better alternative which I don't know?

@vdlindenmark AsyncStorage is not being removed, but moved to Community

I would like to take Picker!!!

If Move ImagePickerIOS to a community repo is not already taken, I would gladly help out 😄

Hey @cpojer I have submitted #23359 for merging PickerIOS and Picker. Please review :).

This issue should be pinned 📌

@dratwas I'm sorry, I got confused there. We are actually deprecating ImageStore entirely because there are third-party options already available as pointed out by @EvanBacon. Do you want to volunteer for another module?
@vdlindenmark as @Krizzu is pointing out, both of these modules are going to stick around in community modules.
@Keraito I created https://github.com/react-native-community/react-native-image-picker-ios for you to send a PR to.
@andersonaddo done! Thanks for the suggestion.

@cpojer I wonder if you guys have also evaluated the possibility of moving AccessibilityInfo to community repo.

I don't know if it could live apart from the core, but I see the benefit of increasing the accessibility support on React-Native.

There're already some proposals to increase accessibility support into the view layer and make it more cross-platform (https://github.com/react-native-community/discussions-and-proposals/pull/56, https://github.com/react-native-community/discussions-and-proposals/pull/55, https://github.com/react-native-community/discussions-and-proposals/pull/54), but something that RN doesn't provide right now, and there's no issue or proposal about it, is the access for some user's a11y preferences on the operational system level. For instance: there's no way to get "reduce motion" option, which is needed to adapt the app by reducing/turning off animations.

I think those options provided by UIAccessibility on iOS (I don't know the equivalent on Android) could be available from AccessibilityInfo.

And having a community repo could attract more contributions for that particular problem.

Thank you.

@cpojer I can't see any unassigned module, so I will speak with @Trancever if I could help with:

  • Move ImageEditor to a community repo

@elucaswork Accessibility is incredibly important and I believe it must be part of React Native itself. We should do everything we can to improve accessibility support in React Native out of the box.
@dratwas sounds good!

  • Move Picker to a community repo.

@cpojer could I start this issue?

something that RN doesn't provide right now, and there's no issue or proposal about it, is the access for some user's a11y preferences on the operational system level. For instance: there's no way to get "reduce motion" option, which is needed to adapt the app by reducing/turning off animations.

I think those options provided by UIAccessibility on iOS (I don't know the equivalent on Android) could be available from AccessibilityInfo.

I was just today wondering about how to read the "reduce motion" option in React Native, but it seems that it has not been implemented.

What would be the best way to do a feature request and get some visibility for it? Is https://react-native.canny.io/feature-requests still the preferred forum for feature requests?

What should we do with VibrationIOS? It has been marked as deprecated in favor of Vibration since March 2016. Seems like an easy candidate for removal.

@hramos great suggestion! I'm gonna take care of removing that one.

@cpojer I noticed that the Picker/PickerIOS was not assigned to anyone. I would like to work on it too, if at all possible.

Hi @rafaellincoln, for picker stuff, I guess we are planning to combine it first in RN repo itself and then move it to community repo. For merging I have submitted PR #23359

I wanted to give a quick update on the progress everyone has been making on the Lean Core effort. I just wanna say how blown away I am by all your contributions in just over a week. Thank you so so so much!

Here is all the work that is already completed:

  • NetInfo (https://github.com/react-native-community/react-native-netinfo) was successfully split out and released on npm via @react-native-community/netinfo by @matt-oakes, who even added new tests and new features to the module!
  • ViewPagerIOS (https://github.com/react-native-community/react-native-viewpager/pull/1) was successfully split out by @ferrannp.
  • AsyncStorage (https://github.com/react-native-community/react-native-async-storage) was pulled out by @Krizzu.
  • StatusBar (https://github.com/react-native-community/react-native-statusbar/pull/1) was moved into a separate repo by @dmtrKovalenko.
  • Slider (https://github.com/react-native-community/react-native-slider/pull/1) was split out by @michalchudziak.
  • MaskedViewIOS (https://github.com/react-native-community/react-native-masked-view/pull/1) was turned into a community repo by @FonDorn.
  • PushNotificationIOS (https://github.com/react-native-community/react-native-push-notification-ios/pull/1) was extracted by @rafaellincoln.
  • ImageEditor (https://github.com/react-native-community/react-native-image-editor/pull/1) was extracted by @Trancever.
  • @EvanBacon added a deprecation message for ImageStore in #23330.
  • @wellmonge merged AlertIOS and Alert in #23318.
  • Callstack engineers released the first version of the new React Native CLI: https://blog.callstack.io/the-react-native-cli-has-a-new-home-79b63838f0e6

I also want to highlight how extracting these modules can lead to better maintenance of those modules, ie @matt-oakes added tests for NetInfo (https://github.com/react-native-community/react-native-netinfo/pull/4) and @ifsnow added Flow types to AsyncStorage (https://github.com/react-native-community/react-native-async-storage/pull/4). By decoupling these components from React Native (and Facebook), they can move much faster individually without being blocked by a Facebook employee. Further, because we can migrate existing issues and Pull Requests from the React Native repository, it will also make it easier to maintain React Native itself and we'll be able to respond to pull requests faster!

This is what we are working on or working on next:

  • Remove VibrationIOS
  • Remove unused third-party dependencies
  • Start migrating Facebook internal code to use the new react-native-community packages

Again, to everyone who has been helping so far, thank you!

@cpojer

  • Remove unused dependencies
  • Identify all dependencies in package.json that aren't directly used in React Native

Above tasks are completed using PRs #23428 and #23467

@cpojer

  • Remove SwipeableList

addressed in #23484, can take on removing ListView too if you like.

FWIW, CameraRoll has a dependency on ListView. Maybe moving it out first would be useful in removing ListView.

FWIW, CameraRoll has a dependency on ListView. Maybe moving it out first would be useful in removing ListView.

The CameraRollView file in RNTester appears to be the only thing using ListView in ReactNative. Perhaps a PR to swap that to FlatList would be a good thing to do to break that dependency. I'd happily accept that if it happens before CameraRoll is pulled out entirely

When compared to other versions Size is increased which is a key point , So is there any way to reduce size in react native 0.58.4 , Just for one page it took 18MB
The following are my dependencies
"react": "16.6.3", "react-native": "0.58.4", "react-native-elements": "^1.0.0", "react-native-gesture-handler": "^1.0.15", "react-native-vector-icons": "^6.3.0", "react-navigation": "^3.2.3"

i saw that navigatorIos was removed from rn 0.59. i wondered if there is already a community package for it? @cpojer

@cpojer I can work on this one, if anyone has not started working on this

  • Remove the fetch polyfill from the repo and re-use whatwg-fetch directly if possible

@nimish-gupta give it a try! There may be some gotchas, but we can discuss that on the PR and see how it goes. It may not be feasible to do this, but let's try and see how far we can get.

@cpojer I wonder if KeyboardAvoidingView is useful enough to keep in the core.
Have you guys thought about removing it as well to give space for more robust solutions such as https://github.com/APSL/react-native-keyboard-aware-scroll-view, or is it very useful to keep in the core?

@elucaswork we actually use that one surprisingly a lot at FB, so I expect we'll keep maintaining it for a while. Maybe we can discuss moving it to a separate repo after we are done with the work currently scoped out under this project.

Great work here. However, I was trying to use NetInfo and AsyncStorage and it seems that they are missing podspec files. @cpojer I think a lot of us use Pods, shouldn't we make it a sort of standard with react-native packages that have native ios codes ?

Great work here. However, I was trying to use NetInfo and AsyncStorage and it seems that they are missing podspec files. @cpojer I think a lot of us use Pods, shouldn't we make it a sort of standard with react-native packages that have native ios codes ?

It looks like these have subspecs in the React Native podfile that probably need to get added to the new repos: https://github.com/facebook/react-native/blob/master/React.podspec#L301-L304

@syaau @TheSavior Good spot. I have opened a PR to add a Podspec to the new NetInfo repo:

https://github.com/react-native-community/react-native-netinfo/pull/17

@cpojer in my experience KeyboardAvoidingView is really flaky, maybe this is a good oportunity to improve it if its gonna stay on the core??

I would like to propose that we deprecate ART in favor of react-native-svg.

@justDanielMata yeah, I definitely think it should be improved if it stays in core, but that should be handled in a different discussion.
@EvanBacon I'll discuss this with the team and get back to you.

Remove WebView from RN repo

I’m happy to take this

@ericlewis unfortunately that one can only be done from FB's side because we still depend on it internally.

NavigatorIos has been removed from react-native, @cpojer can you please create a repo for it under react-native-community? I want to revert it back, if that's ok

i have a working version here
https://github.com/michaelknoch/react-native-navigator-ios

@sijad (fyi: i haven’t fixed any broken flow type imports)

@sijad We'd like to only put components into react-native-community that we still recommend using. The components we are moving out of React Native as part of Lean Core above are all fine components to use in your apps. NavigatorIOS is not something we want people to continue using as we recommend other navigation solutions. However, it seems that @michaelknoch took it upon him to maintain it, so I recommend using that version until you can move to something else.

but why do you advise against using navigatorios? Do you think the performance of JS based navigation (f.e react-navigation) is fast enough that native navigation is not mandatory anymore?
@cpojer

@cpojer Hi just created a PR for ProgressViewIOS : ) https://github.com/react-native-community/react-native-progress-view/pull/1

@michaelknoch on the contrary, we definitely recommend you to use a native navigation solution. It just happens that NavigatorIOS was a legacy navigation system that we don't use at Facebook any longer. Right now, we use our own custom native navigation system at Facebook that is unfortunately not open source. We recommend people to use https://github.com/wix/react-native-navigation.
@kdenz awesome, I'll check it out!

@cpojer Just completed migrating and summing up SegmentedControlIos and added an example app.

  • Tested the Component and everything is working well in a new RN project.
  • Released to npm.

@cpojer completed shifting Clipboard-Api from RN core to community version and added an example app to test everything out.

  • Tested the Component and everything is working well in a new RN project.
  • Released to npm.

@cpojer i've recently started with react native, but i could try

  • Move native "TestModule" into RNTester

if it's not already resolved!

@cpojer what about Toast component? I think it should be deprecated now and removed later.
Reasons:

  1. Toast is just another type/style of notification, there are many types of notifications components
  2. Exists only Android implementation
  3. There are ton of "toast like" components maintained by community https://github.com/search?q=react+native+toast which are multiplatform

What do you think about it?

I'm interested in keeping TabBarIOS around and maintained / future proof. I feel it is quite valuable, together with NavigatorIOS, as a lightweight solution with first class accessibility.

If it is the general opinion that it should not be under react-native-community, since like NavigatorIOS it's already deprecated, I would do so under my own account but I would prefer it under the umbrella of -community.

Was there a reason for the deprecation other than its not used inside Facebook and it's iOS only (which is a decent reason)?

I have a working version here: https://github.com/michaelknoch/react-native-tabbar-ios

@karlsander

Hi, I move ActionSheetIOS native code to expo. Please check 🙇
https://github.com/expo/react-native-action-sheet/pull/105

I was trying to find where is react-clone-referenced-element used, but with no luck. Am I missing something? I'm new to contributing and to react-native code-base, so sorry if it's stupid question.

@Rendfold you are not missing something, I was wondering the exact same thing.

Here is the relevant commit in which it was added: https://github.com/facebook/react-native/commit/665954efcc4460839d00a572be84cf204a42c0d5

Looks like it is to satisfy dependency now that ListView has been removed. I believe this is only used inside Facebook too.

@ericlewis it was updated there, but not added so I went further. Had to go to 2016 commits to find where it was eaba2abc0b76f9a26703c87eecf4a8bb52f9ed3e
But yes, you were right, it is for ListView.

@cpojer I was poking in DrawerLayout / DrawerLayoutAndroid for #23730 and it seems pretty isolated.

Would it be a good candidate to extract as well? I'm happy to take that on.

I noticed that of the modules mentioned here, only react-native-async-storage and react-native-netinfo have passing e2e tests for both platforms, react-native-cameraroll also has them but the tests are failing on android.

I've recently looked into e2e testing of react-native-svg using Detox, and set it up on travis and bitrise:
https://travis-ci.org/msand/react-native-svg-e2e/builds
https://app.bitrise.io/app/1a150b039e9b8fbd#/builds

I have it taking screenshots on both ios and android, and testing new project setup in plain react-native for both, and additionally with cocoapods for ios.

I don't have access to setup bitrise for the react-native-svg repo, @cpojer would it be possible to get the rights for that? Or should I migrate the e2e tests to circleci instead? It seems the android emulator has access to kvm / acceleration there anyways.

Getting it to work without kvm on travis and bitrise required the latest emulator canary and lots of attempts to find a working configuration, as they don't support acceleration. Anyway, in case some other module is interested in setting up e2e somewhere else than circleci, then this repo might be of use: https://github.com/msand/react-native-svg-e2e

Off topic: If someone is interested in helping out with testing react-native-svg, then it would be great to get a script/app to run the tests from here: https://github.com/web-platform-tests/wpt/tree/master/svg
Can probably use https://github.com/kristerkari/react-native-svg-transformer to load the svg files as is, and then a comparison step to screenshots would be really helpful.

With regards to deprecating/splitting out ART, I'm in support of separating it out from the react-native repo, and letting it live on as is and getting bug-fixes/performance improvements. At least if you only have e.g. simple path data you want to render, and don't need any other parts of the svg spec, then it is likely that ART will be more performant when used in react-native at least. As it doesn't have to support as many features as something aiming for full svg spec conformance.

If you render to canvas using ART in the web it might be faster than svg as well, depending on the use case; profile to find your actual hotspots/bottlenecks before putting effort in this kind of optimization, and make proper A/B measurements with statistics over enough data if you do. And, if you have existing code using ART, it is probably alright to keep around as is. But, for new code I would probably recommend using spec conformant svg and write it in a (react-native-)web compatible way (unless it needs canvas/webgl level performance). A compatibility index.web.js implementation will be included in the upcoming react-native-svg release for this purpose as well.

I was just today wondering about how to read the "reduce motion" option in React Native, but it seems that it has not been implemented.
What would be the best way to do a feature request and get some visibility for it? Is https://react-native.canny.io/feature-requests still the preferred forum for feature requests?

@kristerkari I've submitted a PR adding support for "reduce motion" into AccessibilityInfo
https://github.com/facebook/react-native/pull/23839

@cpojer Hi, I am sorry I was out for a while. I have successfully moved react-native-status-bar. But did not deprecate it in core. Should I do it now?
And also I am planning to create additional release for react-native-status-bar package.

@dmtrKovalenko yes, please do!

Made a PR for deprecation status-bar -> #23898

I don't have access to setup bitrise for the react-native-svg repo, @cpojer would it be possible to get the rights for that? Or should I migrate the e2e tests to circleci instead? It seems the android emulator has access to kvm / acceleration there anyways.

@msand I think everyone has settled on CircleCI, because it runs faster as benchmarked by @gengjiawen , but I'm not sure if that is 'official'.

react-native-cameraroll also has them but the tests are failing on android.

I'm having some trouble getting the Android test to pass, the test is really simple (does the app start), so it's something in config. I've copied the config over from netinfo, but it's not working out of the box. @matt-oakes do you see at a glance if there is anything in particular I've missed?

@bartolkaruza This is something I fixed in the NetInfo repository here: https://github.com/react-native-community/react-native-netinfo/pull/25

I'll submit a PR to fix Camera Roll now.

@cpojer any plans to extract tvOS from the core?

I think we should also remove Button.

Remove or extract? I would prefer extract than remove.

A question for react-native libraries that are currently using functionality that is extracted into community modules:

What is the recommended approach of relying on extracted modules? Direct dependencies or peerDependencies?

As an example, reactotron-react-native currently uses AsyncStorage directly. When using react-native-asyncstorage as a direct dependency it could lead to multiple versions being used in the consuming app. Is this being planned for or should it be a peerDependency?

I think it should be a dependency, and AsyncStorage define ReactNative as a peerDependency, this way it could use several versions of AsyncStorage in the same app (except you want to make sure to use the same one, and you put it clear in the library readme), but install process will show a warning if ReactNative dependency can not meet.

Is it this simple? Wouldn't there be potentially multiple versions of the named native module "AsyncStorage"? I think this could lead to issues, or not?

Yes, there would be several versions, but if each one is standalone and don't share data between them, there should no be problems.

Hi @cpojer I'd like to help with some of this issues, could I start with "Move the merged PickerIOS/Picker component to community repo"?

Hey @wagnermaciel , me and @bartolkaruza are working on it. And almost done. @cpojer can you please create a community repo. Actually I guess the plan is to move it out to community and merge both the components.

https://github.com/jainkuniya/react-native-picker

@jainkuniya No worries. @cpojer Are there any issues here that you could assign to me? I'm working with a group of friends and we're all interested in getting involved whatever way we can 👍

@wagnermaciel thanks for joining our effort! I just updated the original post and removed people who weren't responsive on the tasks they signed up for. Any of the ones above without a name next to them can be picked up by you if you like. Which one do you wanna work on?

Hi @cpojer, may I be assigned to Move "ImagePickerIOS to a community repo" - I will be happy to maintain it. Many thanks in advance!

@aerlinn13 I put you down for that one. Just send a PR to the repo and ping me and we'll handle it from there :) Thank you!

@cpojer Thanks for the quick response! Could you assign "Remove ProgressBarAndroid from the repository, possibly move to community repo" to me? I'd love to work on it. Thanks!!!

@wagnermaciel done! Looking forward to your contribution :)

Hi @cpojer, i want to mention ToastAndroid component. Do you have an idea what to do with that?
It looks like ToastAndroid is used in HMRLoadingView and LinkingExample. So it's questionable how to replace notification type for that two components.
Anyway If it is used internally by FB then it is not an issue at current time and ignore my comment :)

My original post:

@cpojer what about Toast component? I think it should be deprecated now and removed later.
Reasons:

  1. Toast is just another type/style of notification, there are many types of notifications components
  2. Exists only Android implementation
  3. There are ton of "toast like" components maintained by community https://github.com/search?q=react+native+toast which are multiplatform

What do you think about it?

@radeno I don't think we are going to remove it right now, but we may chose to do that later.

Sorry @cpojer been really busy last month but I’ll resume work on ProgressViewIOS today

@cpojer I just noticed "Deprecate StatusBarIOS" is checked, but StatusBarIOS.ios and StatusBarIOS.android haven't changed since 2018. Did i overlook something?

If nothing is missing, sorry. Otherwise, let me know, cause I can help with it.

@cpojer Could you provide some clarification on where to find or how to create the files for the ios folder? Thanks in advance!

@cpojer ready to take on moving any component that is yet unassigned, or tackle auditing JS dependencies.

@cpojer I'd like to contribute to react-native as our company is currently using it in production. I found this umbrella issue searching for good first issues, but I was unable to understand what is still up for grabs.

What are the top priorities? Do you need more help with the issues on top (e.g. Move ProgressViewIOS to a community repo) or with the ones that are in future work section? There are some that have no one assigned (such as the one to move ProgressViewIOS) but reading the thread they seem to be already taken.

@RafaelOda top priorities today are helping with issues, triaging and responding to any number of issues in the repo. That said, if you can identify things outside the scope declared here and present them for moving out that would be great.

Do we have the instructions for making a new RNC lib somewhere in a wiki or something? They will be useful to keep and have for others to find, not only for RNC but as kind of a template/guidelines for all libs.

I just found this actually, but it's not done yet. :)

I think next candidates are:

  • KeyboardAvoidingView, SafeAreaView
  • Modal (?).

Would be glad to take SafeAreaView!

Are those migrations from core still up for grabs? If so, what are the up-to-date next candidates? I would like to try to give a hand as well :)

I think @brentvatne @ide @ericvicenti @kmagiera have informed opinions on what could still be moved out and not impact the developer experience when using third-party libraries like react-navigation and reanimated.

One of the things we could use help with is to get rid of using ToolbarAndroid in RNTester on Android. Could somebody work on replacing its usage with something else?

Just finished updating the top level post. ImagePickerIOS is one of the unclaimed components where the component wasn't extracted yet. Is there anybody who'd like to take on the effort and send a PR to the repository created at https://github.com/react-native-community/react-native-image-picker-ios ?

Finally, it seems that the work on bringing DatePickerIOS and DatePickerAndroid never materialized, see https://github.com/react-native-community/discussions-and-proposals/pull/85 – This is a good opportunity! Ideally somebody takes the charge to extract both DatePicker components into this repo: https://github.com/react-native-community/react-native-datepicker

With two high-level exports, DatePickerIOS and DatePickerAndroid.

After the initial version if shipped and the components are deprecated from RN, the community will then be able to merge the two into a single component.

cc @mmcknett and @Swaagie

Added ReactART as another part of RN that we'd like to extract into a separate repo: https://github.com/react-native-community/react-native-art

Help wanted!

can I take DatePickerIOS and DatePickerAndroid?

@sijad have you worked with React Native before and do you have a plan for how to do the extraction?

@cpojer Can I take ReactART starting next Monday? I'm currently evangelising and driving RN adoption at work, and so I had to deal with both ReactART and wrapping native code as reusable RN packages.

@ivanmoskalev sounds great! Let me know when you are getting started and make a PR for the new repo I created :)

@cpojer did you by accident completely overlook the review branch? It had all work minus docs and some detox tests.

edit: cc @sijad for awareness

edit 2: https://github.com/Swaagie/react-native-datetimepicker all work as it existed in the review branch. I have no rights to recreate that repo atm, but would like to finish it off.

Also @sijad, if you would like to contribute in the form of a thorough review and code fixes (if needed) that would be very welcome!

@cpojer @sijad the work definitely materialized as @Swaagie mentioned. I reached out in Discord as well.

No worries about missing the branch – it can be easy to overlook. In retrospect I should have advised Martijn open a PR in Draft-state while he continued to make the smaller PRs for the work we broke out and put into our sprints.

Is there a place where I could help suggest documentation for standard operating procedures for these smaller modules in Lean Core on react-native-community? We've learned a lot iterating on react-native-datetimepicker – would love to share with the broader community to make other modularization easier / faster.

Oh man, I must have and then recreated a repo with a different name -.-

Could you send a PR to the new datepicker one?

Will do! Thanks for the quick turnaround! Also no hard feelings, we're all human and like @crobbins said we should have made the work more visible.

@cpojer could you update the top post and add my github handle to:
Merge DatePickerIOS and DatePickerAndroid, move to community repo
thanks!

@Swaagie Done!

Would be amazing if you adopt https://github.com/yfuks/react-native-action-sheet and merge it with ActionSheetIOS

If you're going to maintain a repo that is created to move APIs out of React Native core, please ensure you are capable of supporting implementations for other platforms, and be sure to look at the equivalent implementations in react-native-web and react-native-windows.

@cpojer are you really doing all of those or can I grab one?
FWIW I've made progress with RCTImagePickerIOS and will submit a PR within the next few days.

@Johan-dutoit yes, unfortunately the removal of modules can only be done by a Facebook employee. Looking forward to your ImagePickerIOS extraction!

@cpojer 🎉PR Submitted and tested 🎉

@cpojer I would like you to react native to those folders that are considered a bit confusing, in a readme.md file that explains what you intend to do in each of the files. This would greatly facilitate those who want to contribute to the project. Like fishhook

For example

image

  • React.js
    The main purpose of this file is...
  • react-native-implementation.js
    The main purpose of this file is...
  • react-native-interface.js
    The main purpose of this file is...

Those three files can be a bit easy to understand, but when we have files like these it can be a bit complicated.
image

Obviously they do not have to be too descriptive, let alone describe what each file does. Only the most relevant or a basic definition of what is intended to be done in a certain folder.

In addition, it would be very helpful to show an outline of how this repository works. I would like to know your opinion. Thanks for everything.

@cpojer Anything left that I can pick up? Would love to pitch in.

As @FLGMwt mentioned in https://github.com/facebook/react-native/issues/23313#issuecomment-469288200, it would be great to move DrawerLayoutAndroid out as well

It would be great to move ToastAndroid and Animated too

@ecreeth, those files are using createReactClass because they rely on mixins that haven't been removed yet. Files using createReactClass are still using propTypes but will be dropped for Flow once they are updated.

@TheSavior Thank you very much for the information!

Would love to contribute, I see "Move Button to a community repo" hasn't been taken. What needs to be done? Would love to help!

Sure. Just check the other ones like https://github.com/react-native-community/react-native-netinfo. You need to have the native code for ios and android, plus any js. Unfortunately, we don't have a specific way to create a new lib.

Hi How to use webview after remove webview in RN

Hi, would love to help! I see that all the "remove" tasks have been assigned to @cpojer, is there any class that I can remove for help? for instance the "ImageStore"

Hey, I can help with moving DatePickerComponents, please let me know how I can be of any help @cpojer , Thanks!

Hello @cpojer, I can help with moving the CheckBox component, it will be grateful if you could guide me along the process. Thank you!

I'm happy to take a stab at moving Button to a new community repo. Would appreciate some guidance on how to proceed, but I will start by having a look at the source and start getting my bearings. @cpojer please advice.

Opened PR to remove Remove DatePickerAndroid, DatePickerIOS, TimePickerAndroid

https://github.com/facebook/react-native/pull/26729

How are we deciding when to add new exports to the core? For example, the useWindowDimensions hook can be built in user-space but it has been added to the core - https://github.com/facebook/react-native/blob/3b3c95b0170e60983eb6e89b910d100d08eee141/Libraries/Utilities/useWindowDimensions.js

I think our thinking with hooks is that modernizing react-native core to provide hooks by default makes sense. It wouldn't feel great to have react native only provide legacy APIs and have the hooks wrapping them in a separate community package.

So I think hooks are a specific question distinct from generally adding new exports to core.

Hey everyone! Currently there is no action that can be taken by members from the community. The currently scheduled removals are on hold for two reasons:

  • We are waiting for a while until we remove components to give the community time to migrate to the extracted versions.
  • The deletions can only be done by somebody from Facebook because we are actually just moving those files to be Facebook internal until we adopt the external modules in the future.

Regarding hooks based APIs, this issue is not the right avenue for that discussion. In general, I believe we should add hook based APIs progressively as we rethink our public API in the future.

Hello everyone, I'm new to contributing to open-source projects and I would like to know if I can still help with this issue.

The currently scheduled removals are on hold for two reasons...

Was it a mistake that ToolbarAndroid was removed (silently) anyway?

@cpojer Can I do 'Move Button to a community repo'?

@Archulan you can send your PR to react-native-button

@Archulan see this comment #23313 (comment)

@Archulan you can send your PR to react-native-button

Okay. Can you please guide me on doing this?

I think it doesn't make sense to move Button out. The component is very small and it's helpful for getting some basic functionality in place without needing to install any libraries.

@brentvatne

I think it doesn't make sense to move Button out.

so weird like react contain <Button/>

after the revolution there should just be

react-native = jsi(fabric & turbomodule) + codegen

other could be driven by community.

for getting some basic functionality in place.

maybe should use monorepo in react-native with react-native-element like react with react-dom

@cpojer Is Vibration (https://reactnative.dev/docs/vibration) also being moved to a community project? If so, and since it seems small enough to start, I could help with that.

@cpojer could I remove ImageStore?

Is possible help with this ? I'm a beginner and I think i can learn a lot with this .
Regards.
Manuel Portero.

If any help is still needed with this I am happy to help 😃

Mee too

I would like to contribute. Is there anything I can do?

Is there anything I can do?

I would like to contribute, is there anything that I can do?

Was this page helpful?
0 / 5 - 0 ratings