Rewrite

[RealOrangeOne]

trafficstars

• [x] Remove old code
• [x] Build Haste Map
• [x] Add mocks for native modules
• [x] Add component mocks
• [x] Add extra require definitions
• [x] Add unit tests for mocking
• [x] Increase coverage
• [x] Basic tests for react-native core components
• [ ] Basic tests for react-native core APIs

Lasted Checked Version: 0.42

[JPeer264]

@RealOrangeOne based on your list above, are just the tests missing? So basically your rewrite is almost ready right?

[RealOrangeOne]

@JPeer264 i believe so, however it hasn't been tested in a few months, and there have been many versions of react-native in that time. Please feel free to try out this rewrite and let me know how it goes!

[JPeer264]

Hm, I tried earlier to set up the tests, but all failed. So I am quite confused - also they failed here on this Travis.

[RealOrangeOne]

@JPeer264 Looks like an issue related to both dependencies, and react-native changing their api (somehow?). Which is strange, seeing as everything worked fine the last time I tested it

[JPeer264]

I guess I got the mistake. Here it seems, that it does install [email protected] which requires [email protected]. But the given react version is [email protected] which does not satisfy the peer dependencies. It might be better to remove the react export and just install react-native. But to ensure that the right peer dependency is installed (luckily react-native got react as peer), you can use install-peerdeps, which automatically installs the right react version.

[RealOrangeOne]

That sounds like quite an issue, and likely one end users will have too. Potentially experimenting with moving all react-* dependencies to peer might solve the issue? As people will need them installed to use the library anyway

[JPeer264]

Unluckily I saw that you need more than just react. So installing just the peers won't install e.g. react-dom. So I guess having it the way you got it now is fine. But still it would be better to add the react-natives patch version to ensure that npm will install the right version. I made a new list and came up with some mistakes in the travis env list (first and third seems to differ):

react native version	react version	link to package.json
0.38.1	15.4.0-rc.4	link
0.39.2	15.4.0-rc.4	link
0.40.0	15.4.0-rc.4	link
0.41.104	15.4.0	link
0.42.3	15.4.1	link
0.43.5	16.0.0-alpha.6	link
0.44.3	16.0.0-alpha.6	link
0.45.1	16.0.0-alpha.6	link
0.46.4	16.0.0-alpha.12	link
0.47.1	16.0.0-alpha.12	link

Furthermore, react-addons-test-utils is deprecated since [email protected] to react-dom/test-utils. So I think there must be a detection in ./build/react-native.js wether the react version is higher or lower than 15.5.0 or 16.

[jasonfma]

Would be reasonable to support up to RN 42 (before the fiber stuff)? Seems super valuable to get this in and then maybe tackle the fiber changes separately?

Also happy to try to help with this too.

[jasonfma]

@RealOrangeOne I've pulled the rewrite branch and I was trying to get it running for the latest RN (0.49) and react 16. I think I got it working but there is a test failure around the Android back button. I was able to update all packages except for sinon because of a nise error when running the tests.

When I went to test my changes against RN 0.38, I ran into some issues trying to write a bunch of defensive code for stuff that's not in 0.38 but is required for RN 0.49, and for enzyme adapters with the other react version.

I think it'll be a lot easier to get this rewrite done to focus on the latest RN and react 16 as a major breaking change. If we really need older version support we can look to add that in progressively.

Thoughts?

[RealOrangeOne]

@jasonfma that sounds like a great idea. I've been out of the react-native (and mobile) scene for a while. Pivoted my work rather heavily. Yes I completely agree breaking backwards support is probably ok, as react-native has undergone a lot of changes since I wrote this PR.

I think targetting >=0.49 is probably ok. Once support for that is working, support for older versions might be possible, and the version mask can be widened slightly. I think it's perfectly fine to drop support for <0.3* easily, even early <0.4*.

I very much look forward to what you come up with!

[jasonfma]

@RealOrangeOne opened a PR into your rewrite branch #151

[nick-rex]

Hi there, what is required to get this over the line? Happy to help if it is of any use

[jasonfma]

I think the core APIs that need to be tested are as follows:

• [ ] AccessibilityInfo
• [ ] ActionSheetIOS
• [ ] Animated
• [ ] LayoutAnimation
• [ ] ListViewDataSource
• [ ] NetInfo
• [ ] PanResponder
• [ ] PermissionsAndroid
• [ ] PixelRatio
• [ ] PushNotificationIOS
• [ ] Settings
• [ ] Share
• [ ] StatusBarIOS
• [ ] Systrace
• [ ] TimePickerAndroid
• [ ] ToastAndroid
• [ ] Transforms
• [ ] Vibration
• [ ] VibrationIOS

[jasonfma]

I believe the way that RN is doing it with jest is a good guideline of how to get these APIs working. https://github.com/facebook/react-native/blob/master/jest/setup.js

[RealOrangeOne]

Theoretically, it should be a simple case of stubbing out the native modules related to those APIs, and possibly make them return sane values if required. I'm hoping none of them require a full stub

[ckurban]

Whats the ETA for this?