[Shallow Renderer] Plan forward

[gaearon]

Let's discuss what to do with the shallow renderer here. As I mentioned in #16168 (comment), we aren't using it much and don't consider it a best practice. So we aren't going to be very good stewards of its API going forward.

My proposal was for Enzyme or folks interested in it to copy the code into another repo, and continue maintaining it there under a difference package name. It would make sense to Enzyme to start depending on that fork. We would then deprecate react-test-renderer/shallow in favor of the community-maintained fork.

If you'd like to volunteer to set up a repo, please let us know in this issue!

cc @davidmarkclements regarding the proposed react-shallow-renderer package name.

[ljharb]

The main concern I have isn’t maintenance of the code - it’s how it might break with new react releases.

Given that most of what the dev tools does seems to overlap with what enzyme needs, i wonder if a better path might not be in sharing those components between enzyme and the dev tools?

[gaearon]

At least for shallow renderer, I wouldn't expect breakage with new React releases because the code itself is standalone. It can lag behind in features but it doesn't actually depend on React internals the way the more invasive introspection does. This is because it's completely implemented from scratch and doesn't use the real codepaths.

[gaearon]

I'm not sure I see how DevTools would be helpful given that DevTools introspect a real tree — but shallow renderer is a 100% custom implementation that doesn't use any of the real reconciliation mechanisms.

[kumar303]

This comment about shallow renderer's dependencies implies that forking it into a standalone module would require copying/pasting a lot of core code.

[gaearon]

This is not a lot of code. Each of these is a tiny utility and they probably don't add up to more than ~200 lines.

[gaearon]

Also you can replace invariant with throw Error, warning with console.error, and objectIs with Object.is.

[ljharb]

That's a fair point; it would still be preferable to avoid it lagging behind in new features if possible.

[tomstuart]

For clarification: what is the main reason that the regular test renderer can’t support a shallow mode where composite child components are left inline instead of recursively rendered into host components? Is it for reasons of API backward compatibility, a fundamental limitation of the test renderer, a design principle, or something else?

[robertknight]

If it wasn't for the need to support the very large number of tests that I presume already exist, I think I would advocate for Enzyme to deprecate (and maybe even eventually drop) its shallow rendering mode entirely and instead document methods for users to mock at the import level as Dan described here. Anecdotally I observed that the differences in normal vs shallow rendering in Enzyme were the source of quite a lot of confusion for other devs on my team and that led us to replace it with normal rendering + import-level mocking instead.

If Enzyme were to do that, perhaps the shallow renderer could be "frozen" so that it is kept working, but no new features are added to it as a matter of policy.

[ljharb]

@robertknight That presumes that it's actually a better pattern to do explicit import mocking of each sub-component (it also presumes that a pattern that forces jest is a reasonable thing to recommend). This isn't the place for a longer writeup of why shallow rendering is critical, a good pattern, and required for robust testing, however.

[robertknight]

That presumes that it's actually a better pattern to do explicit import mocking of each sub-component (it also presumes that a pattern that forces jest is a reasonable thing to recommend).

I agree that both of those things would be undesirable. We automatically mock imported components using some simple heuristics rather than requiring developers to remember to configure each one. We also use a Babel plugin, which is not tied to any particular test runner, rather than Jest, to do this.

This isn't the place for a longer writeup of why shallow rendering is critical, a good pattern, and required for robust testing, however.

That's fair enough. Perhaps I can continue the discussion in an issue on the Enzyme repo?

[Sonic12040]

Would you be willing to speak more about the automatic mocking? I'd love to learn about the flow that you've found successful and the use-cases.

Edit: Realize I didn't tag @robertknight