Giters

facebook / react-native

A framework for building native applications using React

Home Page:https://reactnative.dev

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

☂️ Lean Core

cpojer opened this issue · comments

commented

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: #23313 (comment)

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
commented

@cpojer I'd like to remove SnapshotViewIOS 🔪

commented

Hey @cpojer, thanks for putting it all together!

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

commented

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?

commented

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

commented

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?

commented

@cpojer I could help with moving slider 🙂

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

commented

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

commented

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

commented

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

commented

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

commented

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.

commented

Can help with StatusBarIOS and PushNotificationIOS

commented

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

commented

Can I help with

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

I'll take the checkbox, please.

commented

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.

commented

@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.
  • 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 :)

commented
  • 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.

commented

Hey @cpojer! I would help with

  • Remove MaskedViewIOS and possibly move to community repo
commented

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

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

Hey @cpojer! Could I help with

  • Move ActionSheetIOS native code to expo.
commented

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

commented

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

commented

Could I help with this task? @cpojer

  • Move Picker to a community repo.

@jainkuniya Maybe we can work together?

commented

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

commented

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

commented

@cpojer I can help with

  • Move "Share" to community repo
commented

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.

commented

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

commented

@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: react-native-netinfo/react-native-netinfo#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.

commented

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

commented

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

commented

Hey @cpojer I would love to work on this one

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

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

commented

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

commented

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

commented

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?

commented

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

commented

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

commented

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

commented

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

commented

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

commented

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

commented

hi, @cpojer I would love to work on

  • Move ProgressViewIOS to a community repo

Thank you

commented

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.

commented

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

commented

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?

commented

@cpojer I would like to work on PushNotificationIOS.

commented

@cpojer i could help with

  • Move ImageEditor to a community repo

Thanks!

commented

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

commented

@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

commented

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?

commented

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

commented

I would like to take Picker!!!

commented

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

commented

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

commented

This issue should be pinned 📌

commented

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

commented

@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 (react-native-community/discussions-and-proposals#56, react-native-community/discussions-and-proposals#55, react-native-community/discussions-and-proposals#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.

commented

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

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

commented
  • Move Picker to a community repo.

@cpojer could I start this issue?

commented

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?

commented

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.

commented

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

commented

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

commented

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

commented

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:

I also want to highlight how extracting these modules can lead to better maintenance of those modules, ie @matt-oakes added tests for NetInfo (react-native-netinfo/react-native-netinfo#4) and @ifsnow added Flow types to AsyncStorage (react-native-async-storage/async-storage#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!

commented

@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

commented

@cpojer

  • Remove SwipeableList

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

commented

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

commented

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

commented

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"

commented

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

commented

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

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

commented

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

commented

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

commented

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 ?

commented

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

commented

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

react-native-netinfo/react-native-netinfo#17

commented

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

commented

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

commented

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

commented

Remove WebView from RN repo

I’m happy to take this

commented

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

commented

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

commented

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)

commented

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

commented

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

commented

@cpojer Hi just created a PR for ProgressViewIOS : ) react-native-progress-view/progress-view#1

commented

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

commented

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

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

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

  • Move native "TestModule" into RNTester

if it's not already resolved!

commented

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

commented

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