Planned breakage: React 16.14 compatibility

[gaearon]

We are renaming some internal fields in facebook/react#18377. That commit will likely make it into React 16.14. We don't have a clear timeline on what it'll be out but I would expect within a couple of weeks.

Since the Enzyme 16 adapter depends on this field name, it would either need to be updated or a new adapter for 16.14+ would need to be created.

Please note that in longer term, this isn't really going to be sustainable. We are planning bigger refactors which will change the internal data structure. I wonder if it would be better if Enzyme just shipped with its own copy of React that may lag behind in features. In our experience, Enzyme lagging behind due to its invasive reliance on internals has been the biggest factor in moving away from it.

[ljharb]

Thanks for the heads up, I'll try to get updates in that use the new field names when available. If this gets published in a prerelease sooner than an actual release, I can start running tests against that.

The reason things have been hard to sustain is because React doesn't expose sufficient public APIs to properly test it ("just dump it into the dom and look at that" doesn't qualify); shipping its own copy of React isn't going to fix that, and it would worsen how behind we are, since most of the time everything just works. I look forward to finding a better long term solution than relying on internals (#1648), which will hopefully involve more exposed/supported testing hooks (including for hooks themselves, which I don't think have any).

[gaearon]

Regarding testing Hooks, technically you can always override the Hooks Dispatcher to point to arbitrary implementation. That’s how Hooks work today in different implementations. The Dispatcher exists on a scary hidden property of the React object but that part is actually pretty stable because it exists solely for dependency injection and doesn’t contain any logic.

[gaearon]

Regarding official API. @bvaughn is working on a proposal that adds limited introspection abilities to a special “testing build” of ReactDOM. However they are intentionally much more limited than what Enzyme currently provides. He will share an RFC soon. I imagine it won’t be sufficient for Enzyme. However, there is also an argument that we don’t think exposing other things or relying on them in tests is a necessarily good thing in the first place. Here it might be difficult to find a path forward if we don’t agree on the big picture approach.

[bvaughn]

Regarding testing Hooks, technically you can always override the Hooks Dispatcher to point to arbitrary implementation.

This is a dangerous path though, since it requires some internal knowledge about e.g. composite hooks (for example: facebook/react#18130).

He will share an RFC soon.

I think I'm probably not ready yet to share an RFC. (I think I'm going to want to play around with Jest e2e integration with Scott some first and see how that goes.)

If @ljharb would be interested in hopping on video chat sometime to talk about the new APIs at a high level though, I'd be happy to do that. The currently planned set of APIs is actually pretty powerful I think, although there's some question about how much of that "power" we want to expose to users for direct usage (vs maybe something that e.g. Jest e2e internals use for validation). That's part of what I'd like to work out first before an RFC.

[ljharb]

I'd be more than happy to do that! It's a totally viable option to release a v4 of enzyme with a more limited featureset, if it means that keeping up to date with React changes will be seamless.

[bvaughn]

What's your schedule like Thursday and Friday? Any particular time(s) good for a video chat?

[ljharb]

We had this chat; there's definitely a potential for enzyme to use some of these new APIs, but it unfortunately doesn't solve the majority of what enzyme (and any non-basic testing framework) needs. Hopefully there will be more such APIs in the future and we can close that gap!

[eps1lon]

If this gets published in a prerelease sooner than an actual release, I can start running tests against that.

Seems like react@next uses the new names now. Is there any chance enzyme can publish a version that tracks react@next more closely (maybe an adapter?). Looking at the comments in the PR that renames the fields, this will happen again. Would be great if we have a strategy to mitigate these issues in the future. Currently react@next is untestable for us.

[ljharb]

Thanks, I'll try to get tests running on next this week (TC39 is today through Thursday, so probably after that).