-
-
Notifications
You must be signed in to change notification settings - Fork 2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create Adapter for React Native & React 16 #1436
Comments
We have one for React 16; but we definitely do need one for react-native. Implementing it here in this repo would be great; anyone interested in opening a PR? |
Since we’d want a different adapter as needed for different React-native versions, we might also want a utils package. We’d also want to add a new binary to the adapter helper for react-native. |
Yup I'm already aware of the regular react 16 adapter. I was more saying one that works with react native apps built with react 16 as the react dependency. I've been ripping apart and experimenting with the 16 adapter as a way to boost familiarity with the adapter system. I'm planning to start working on implementation after holiday travels. Do you have some ideas as to what the adapter would use instead of ReactDOM? I saw that react test utils also has a render method in addition to a shallow render method. I was thinking of investigating that first. |
I'm really not sure, unfortunately. I would assume/hope that the react-native team would provide something for this use case. |
Looking to start investigating implementation. I started setting up my development environment and was reading through the existing test suite. I noticed that quite a bit of the tests seem to be heavily geared towards React and not React Native. This isn't really a surprise, but leads me ask how we would prefer to setup the suite for React Native. A couple quick options I was able to come up with:
Of these (2) sounds to be more maintainable with less duplication. I'm unsure if there are any pitfalls which would block it from being possible due to lack of familiarity with the test suite. Is one of these decisions largely preferable over the other? I'd also be interested to know if there are any other better options. |
I’d prefer we move to a place where tests that are specific to each adapter (like anything React-specific) moves to that individual adapter, and the tests in enzyme-test-suite become adapter-agnostic (and thus, react and react-native agnostic) |
That makes the most sense. Would you say that the test suite refactor should be a hard precondition before starting the implementation of the wrapper? Or would it make more sense to just implement the adapter with the right testing setup, allowing the other adapters to be refactored as time permits? I'm leaning toward the refactor needing done first so that we have thorough code coverage on the native adapter from day one. Edit: Also, would that fall under #1132 or should I create another issue? |
I would hope it could be done first :-) and yes, that’s indeed the issue for it. |
Is there a work around for this, or can someone point me in the right direction to look into this issue? Is the adapter for React Web the best place to start? |
I’d start there, yes. Not sure if there’s any existing work. |
I've spent a few hours looking over the adapter react 16 uses and have come to the conclusion it's unlikely something that can be done independently. I'll share that which I've learnt below for other adventurers. The following appears to be the case at time of posting. There is a single set of tests for all adapters found there. This file runs once for each of the adapter versions in this setup file. Excluding specific version of react from running a set of tests are done in this file with an When you switch between each version of react using There is no documentation on how an adapter is meant to work. Overall it feels that react native was very much left out of the changes made when converting Enzyme to use adapters. I'm not judging; it's Airbnb's library and they can do what they want with it, but it's a shame because you can't adequately test a react native application without Enzyme imo. I have a workaround solution I'm using that I'll post in the next few minutes. |
This is the work around I'm using for the time being. It's a jest mock set that knocks out the apis that react-native use allowing you to use the standard react 16 adapter. My implementation is similar to react native's implementation This is meant as a functioning stop gap until a proper adapter has been built. |
All the scripts can and should be modified as needed. Fwiw tho, this wasn’t a result of any migration - enzyme has never explicitly tested itself on react native nor was it originally built to handle it. Adding more explicit react-native support is going to be an effort that necessitates changing things as needed. In particular, the organization of the tests is such that (as you discovered) it’s not useful as a generic adapter test suite. The same is true if a preact or inferno adapter tried to use them. This is something we’ll need long term regardless. |
That's really interesting, after looking deeper I think I've found the duct tape module that allowed react native work. Would you be interested in doing progressive changes rather than a big bang? First split out the tests to allow generic adapter tests, then sort out the environment switching mechanisms that require react-dom to be installed etc? |
That sounds like a great approach. The purpose of the "react" scripts is to make sure that for each version of react, the appropriate additional packages (like react-dom) are installed. If we need a "react-native" script, great, if we come up with a better solution, great :-) |
Someone working on it? |
@thefelpes No one is working on it from my end. We ended up using React Test Renderer and Shallow render directly. |
Hi @mcdankyl, what do you mean by "use shallow render directly"? |
At least for the react 16 adapter, shallow rendering relies on ShallowTestRenderer. We are directly using ShallowTestRenderer for shallow rendering and using TestRenderer for full renders. |
It'd still be great to create a RN adapter; using those tools directly takes a lot of work to migrate across major react versions. |
@shawnaxsom Hey man, I appreciate it so much! I'm going to try this out today and see what it can do! 👍🏼 You're awesome! |
I was having trouble with this set up that you can find on https://airbnb.io/enzyme/docs/guides/react-native.html |
The following function
induces the Error in Node 8
@shawnaxsom Any idea of how to fix this ? |
Same here - I am encountering the same issue mentioned by @yuanfux When I tried to run the setup file, the test failed with the following message:
FYI, the versions of dependencies used (I am using
|
@yuanfux - here is our complete
|
doesnt work for me. The same error. But thanks |
Not working for me. Current behaviorYour environment
API
Version
Adapter
|
Nothing is going to work properly until a full react native enzyme adapter is created; using jsdom is a workaround. |
Problem Statement
Currently we have no support for using a react native adapter with Enzyme. This is because the current adapters are built for react native web.
Attempting to use mount with the current adapter will cause various issues from polluting the user's console with a ton of logs to inability to import necessary libraries.
While this is the case you can get some testing done by filtering the logs and using jsdom.
Most of the console error issues seem to be coming from the ReactDOM call for the React 16 adapter here
Purpose
The purpose of this ticket is to track work related to implementation and decisions regarding implementation of a react native enzyme adapter.
TODO
Related Issues
#1390
#831
The text was updated successfully, but these errors were encountered: