Open manuelmorales opened 8 years ago
I'd vote for allowing children, but then we'll have to mock all this native-connecting Apis. At some point you have to make the cut
The idea of this library is to use the 'Shallow' render feature of enzyme
. In an ideal world, everything would render accurate children, and we wouldnt have any issue like this. This kind of a change would be rather monumental, and complicated to implement, but i'm open to the change!
Any help with this would be greatly appreciated
Understood guys. Thanks for the clarification. I don't feel capacitated to take over this myself as I'm quite new to react and react native yet. You can close this issue if you like.
Thank you!
@manuelmorales any workaround for this, or any tips on getting things to work?
We made a fork at https://github.com/Root-App/react-native-mock-render that will allow fully rendering native components with enzyme's mount()
. We wrote about it at https://blog.joinroot.com/mounting-react-native-components-with-enzyme-and-jsdom/
We'd be happy to contribute a PR back into react-native-mock
, but it'd be a breaking API change.
@dan-manges that looks like great work. Looking through your code i'm not seeing any massively breaking changes, but I may be wrong.
I'm currently in the process of doing a major rewrite that'll fix this issue once and for all in a much more reliable way. Whilst it's not finished yet, i'd love some feedback on it! There's an open PR to track this #120
@RealOrangeOne could you explain your approach to supporting mount in this PR? Is it similar to what's been done in react-native-mock-render?
@talarari no, #120 is a complete rewrite. Rather than using complete mocks as the current version of react-native-mock
and react-native-mock-renderer
do. #120 uses the direct react-native
code when rendering, in mostly the same way jest
does.
As you can read here https://github.com/airbnb/enzyme/issues/470, it won't work. And by the looks of https://github.com/lelandrichardson/react-native-mock/blob/master/src/components/View.js#L284 it is expected.
My question is: Is it part of your ideal for this library to keep extending it so that eventually, things like these work? Or would that be totally off scope for this library?