warn when it looks like you haven't updated react-dom

[threepointone]

sketching a possible "fix" for #14039 for discussion.

• icky error message, I know.
• can't think of a good test for this, open to suggestions. should I mock the dispatcher to trigger this specific error? sounds self serving.
• should probably add a TODO to remove this in v17

[threepointone]

I should add a flag that fires this warning only once.

[gaearon]

How did you test this? It's likely specific message in #14039 is no longer what happens. We need to actually look at what happens when e.g. using [email protected] and [email protected] / [email protected] (it's even possible the messages are different).

It's also worth looking at what happens when you mix [email protected] / [email protected] / [email protected] with [email protected].

Could you write up an analysis of what different combinations fail with today?

[threepointone]

I haven't tested this, setting it up right now. will report back.

[aweary]

This isn't the first issue to arise from mismatched react/react-dom versions, and it probably won't be the last. Could we just add a version to ReactDOM and the other renderers and have the renderer warn when it doesn't match React.version?

We already have checkReact for react-dom to check that React is loaded first, we could add the version check there?

[gaearon]

We kind of wanted react-dom to keep working with react of the same major without breaking. I don't think a strict match is necessarily desired unless you're trying to use new features — in which case you should have at least that version of both.

[aweary]

I don't think a strict match is necessarily desired unless you're trying to use new features

Why not? Using mismatched versions isn't something people do intentionally (afaik) and if a user is already updating one, the burden of updating the other should be low.

[gaearon]

If it works fine, what's the point of being too sensitive about it? In general it doesn't cause issues anymore.

[threepointone]

alright, I've verified, here's how react/react-dom at various versions interact with a simple hook -

[email protected]

• 0.0 - ?? fails before react even starts up,
• 3.0, 4.0, invariant - Hooks can only be called inside the body of a function component.
• 5.0, 6.0 - dispatcher.useState is not a function
• 8.0 - Cannot set property 'current' of undefined

[email protected]

• all older versions fail with Hooks can only be called inside the body of a function component.
• 0.0 - 2.0 - throws
• 3.0 - 7.0-alpha - invariant

honestly, this is kind of an edgecase squared, mismatched versions of react/react-dom and using hooks recently. maybe we shouldn't do anything.

[aweary]

If it works fine, what's the point of being too sensitive about it? In general it doesn't cause issues anymore.

It does cause issues though, and even if it causes less issues now there is still a chance that it will break things in the future. I don’t think there’s any reason to think that this would be less likely in the future? We don’t have any fixtures looking for undefined behavior with mismatched versions before release AFAIK

A single warning doesn’t seem too sensitive either. There’s no case where we recommend using mismatched versions, so it would always signal a real issue to the user.

[gaearon]

@threepointone It "throws" on usage only, right? If we don't use Hooks then it's ok?

[gaearon]

0.0 - 2.0 - throws

throws what?

3.0 - 7.0-alpha - invariant

which invariant?

[threepointone]

@gaearon - they all throw - "Hooks can only be called inside the body of a function component.". 0.0 - 2.0 throw it as a regular error (like, codesandbox reported it as a normal error), the rest as an invariant (with the 'invariant' warning).

[gaearon]

OK. I think the most actionable thing here is to make a doc page (similar to "current owner" error) that explains possible causes (calling outside render, calling inside useMemo, duplicate React, wrong version of React), and add a link to the existing invariant. What do you think?

[threepointone]

Yeah, I think that would gather these loose ends in one place. I'll do it.

[threepointone]

closing