Create Adapter for React Native & React 16

[mcdankyl]

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

1. Find an alternative to rendering with ReactDOM
2. Decide best way to use the solution for (1) with existing adapters
3. Decide whether we would like to do all necessary react native stubbing in the adapter a-la react-native-mock-render, do a RYO implementation, or not take a firm stance to the native mocking
4. Add unit tests to verify functionality
5. Update Necessary Docs

Related Issues

#1390
#831

[ljharb]

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?

[ljharb]

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.

[mcdankyl]

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.

[ljharb]

I'm really not sure, unfortunately. I would assume/hope that the react-native team would provide something for this use case.

[mcdankyl]

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:

1. Nest directories in enzyme-test-suite/test so that we have enzyme-test-suite/test/react and enzyme-test-suite/test/react-native. Change npm test:only to something like npm test:only:react and react native variant.
2. Try to refactor the existing suite to also work with React Native.

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.

[ljharb]

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)

[mcdankyl]

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?

[ljharb]

I would hope it could be done first :-) and yes, that’s indeed the issue for it.

[lededje]

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?

[ljharb]

I’d start there, yes. Not sure if there’s any existing work.

[lededje]

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 itIf with a condition provided. If you want to test a react native adapter none of the tests cases in this file will apply to you so you will need to set up an independent test set.

When you switch between each version of react using npm run react:x where x is a version number it removes and installs dependencies as described in this env.js file. When I created another adapter and removed react-dom as a peer dependency all the over version's tests broke.

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.

[lededje]

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.