search

RealOrangeOne / react-native-mock

A fully mocked and test-friendly version of react native (maintainers wanted)
MIT License
570 stars 153 forks source link

Rewrite #120

Open RealOrangeOne opened 7 years ago

RealOrangeOne commented 7 years ago

Lasted Checked Version: 0.42

JPeer264 commented 7 years ago

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

RealOrangeOne commented 7 years ago

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

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 commented 7 years ago

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

I guess I got the mistake. Here it seems, that it does install react-native@0.38.1 which requires react@15.4.0-rc4. But the given react version is react@15.4.0 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 commented 7 years ago

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 commented 7 years ago

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 react-dom@15.5.0 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 commented 7 years ago

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 commented 6 years ago

@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 commented 6 years ago

@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 commented 6 years ago

@RealOrangeOne opened a PR into your rewrite branch #151

nick-rex commented 6 years ago

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

jasonfma commented 6 years ago

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

jasonfma commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Whats the ETA for this?