RN Web support

[mdjastrzebski]

RN vs RN Web comparison

RN Web renders HTML elements like <div> instead of typical RN host views like <View />, <Text />.

// Testing code
const renderer = TestRenderer.create(
  <View>
    <Text>Test</Text>
  </View>
);
expect(renderer.toJSON()).toMatchSnapshot();

// RN Output
<View>
  <Text>
    Test
  </Text>
</View>

// RN Web Output
<div
  className="css-view-175oi2r"
  dir={null}
>
  <div
    className="css-text-146c3p1"
    dir="auto"
  >
    Test
  </div>
</div>

This can be replicated by installing jest-expo package and applying Jest "preset": "jest-expo/universal". Using is the Jest Expo package is the only known popular way to render in RN Web mode I am aware of.

The comparison above has been achieved using React Test Renderer, since RNTL's detectHostComponentNames() function throws error when running under web preset.

Potential solution

React.js (web) has a mature testing solution in form of RTL, on which RNLT is modelled. However, as noted in our docs, RTL has much better testing environment due to usage of Jest DOM package, which is a reliable browser DOM simulation. In contrast, RNTL contains code simulating only the key aspects of RN env, sometimes in a very crude way.

Therefore, our recommendation so far, has been to test RN Web rendering using a proper RTL setup. This has two major downsides:

1. It's a more complex setup for the user
2. It requires user to write and maintain two sets of tests: one for RN using RNTL, and another for RN Web using RTL.

In order to ease life of RN Web users, we could potentially include proper RN Web setup inside RNTL. The env setup could be modelled on Jest Expo package (or simply re-use it). That would solve pain no. 1.

In order to solve pain no. 2, we would have to be able to execute given test suit in both RN+RNTL and RN Web+RTL+Jest DOM setup. The easiest, but not easy, way to achieve it would be create a adapter/facade layer, that would expose the familiar RNTL API to the user, but would internally translate it to RTL calls. This should be possible as, RNTL API is largely coherent with RTL API. There are some semantic differences between the queries which would need to be bridged by such RNTL adapter. E.g., RNTL exposes includeHiddenElements option which is an alias to hidden option in RTL, but RNTL exposes it on all queries, while on RTL it's only available on *ByRole queries.

Alternative approaches

1. Recommend users to test the core RN (not yet translated to Web) using current RNTL. This is what we support now. It does provide a unified testing ground for RN apps, by mixing together various iOS and Android observed runtime behaviours, but does not allow for testing of RN Web-specific aspects.

2. Provide example setup for devs wanting to test RN Web using RTL+Jest DOM, but without ability to share testing code. Users would have to duplicate their tests manually. RTL testing code would be largely copy-paste from RNTL with minor tweaks, but that the burden of maintaining RNTL/RTL differences would be on the users.

3. Create and maintain an external RNTL Web package, that would do support the API adaptation described above, in a similar way that RN Web exposes RN APIs. This could be maintained either by RNTL team or by some 3rd party with serious interest in RN Web support.

Considerations

The decision whether to pursue this effort inside RNTL should be based on the following factors:

1. Demand from the users to test RN Web apps using more realistic Jest DOM setup
2. Cost of creating and maintaining such adapter code in relation to RN & RN Web evolution.

CC: @thymikee, @AugustinLF, @pierrezimmermannbam, @MattAgn

[pierrezimmermannbam]

I agree very much with the first downside you identified but I'm not sure I understand your solution. What would it mean to include RNWeb support into RNTL exactly? I don't think there really is a way around having a test setup for RN and another for RNWeb because you don't want to use the same preset and also not the same environment (node vs jsdom). Maybe there would be solutions to make that setup easier though, that's definitely worth exploring.

You could however run the same test files using two different environments if RNTL supported a web setup, probably by mapping to RTL's APIs like you suggested. That being said I have some concerns about this approach:

• The most important one is I'm not really convinced that the second downside really is a downside. The way I think apps that use RNWeb should be tested is testing fully shared components using RNTL and only test code that's platform specific with both test setups. In those cases (which are usually not that frequent) it's also likely that the functional behavior is different so having two tests anyway would make sense. If you wanted all your tests to be for both platforms then it would indeed be very hard to maintain but I don't think it would be very beneficial. Also If you want to write tests for the web, they would be better written with RTL which has web semantics (for instance userEvent is pretty different).And if we added a an additional layer of abstraction it could make debugging web tests very hard
• I fear that maintaining this adapter could be very hard and it would introduce a coupling between RNTL and RTL's versions (and also testing library user event). It would probably need to be a separate package then but it would have 3 peer dependencies and pretty strict requirements for versions probably

[mdjastrzebski]

In case of switching envs under a single preset, Jest Expo package with it's universal preset does it automatically. It has for environments: iOS, Android, Web and Node (not sure what exactly is it but could be React Server Components). Each test is run against each of these four enviroments, with iOS and Android rendering to Views and Web and Node rendering to divs

[mdjastrzebski]

It seems what we share the same concers about the "cost" of maintaining the solution in the long run and additional complexity it would add. @pierrezimmermannbam thanks for your feedback on this. 🙌

[pierrezimmermannbam]

Oh ok sorry I didn't know jest-expo provided a preset with multiple envs. That's interesting but I wonder how this could be used today since a single test cannot be written to work with all of those environments

[mdjastrzebski]

• iOS/Android under Jest Expo is essentially the same as RNTL runtime env, with returning ios or android in Platform.OS, Platform.select and picking .ios.ts/.android.ts files when available. So here the single test approach is working.

• Web/Node affects the above as well, but also swaps react-native for react-native-web which results in rendering divs instead of Views. Here the tests are failing due to detectHostComponentNames() failing.