String Refs Without An Owner Should Fail Gracefully

[sebmarkbage]

Occurs in Fiber with multiple instances of the React package (which can't share current owner).

[flarnie]

Context:

• When users are loading multiple copies of React, it commonly causes this error:
  https://facebook.github.io/react/warnings/refs-must-have-owner.html

We theorize that this may be triggered by different versions of React being required for libraries depending on React. As libraries update to support version 16, this may come up more commonly than in the past.

At the very least, it seems common enough now to be worth fixing, with 300+ issues open across various libraries: https://github.com/search?q=%22Refs+must+have%22&type=Issues&utf8=%E2%9C%93

Folks on this issue are helping out with more info about how to reproduce and debug this state: facebookarchive/draft-js#296

Plan:
MVP:

• Add a warning for any time that multiple copies of React are loaded.
• Link to documentation about how/why this might happen and how to fix it.

Bonus:

• Indicate multiple copies of React with the devtools icon
• (?) Add a work-around in the code itself such that React itself will work ok even when you have loaded multiple copies. -> We might not want to do this, since it allows users to continue in a "broken" state.

[gaearon]

At the very least, it seems common enough now to be worth fixing, with 300+ issues open across various libraries:

To be clear, I think this issue is not about completely fixing this error, but about making the error message comprehensible in Fiber.

Stack produced an error message that linked to the error page. Those issues you linked to are the ones that already have a legible error message. But Fiber doesn't show this message at all—it just crashes with a TypeError. I believe this issue was about Fiber parity with Stack in failing gracefully rather than crashing in internals. So we'd need to add an invariant with this error message to Fiber code (since now it only exists in Stack code).

But surely we could make the message better by including debugging instructions, and improve error page. Adding npm ls react suggestion to the error message (and the page) and making the message more prominently about duplicate React would very likely be helpful.

We can also take a stab at, if not fixing, then reducing how common it is, by extracting a separate package for shared mutable state. But I think that would be worth tracking in a separate issue, and it doesn’t block 16 beta.

Apologies if this is what you meant already! Just want to make sure we’re on the same page re: action item here. Making this more resilient would be great but seems like more work than just putting an invariant in.

[flarnie]

Thanks for clarifying this -

"But Fiber doesn't show this message at all—it just crashes with a TypeError."

I did notice that, you're right that fixing that is the main blocker.

We can improve that error message to make it on par with the "Refs must have owner" warning. Maybe that's an acceptable first step.

It seems to me that reaching that point is just a symptom of the larger problem. We don't support having two versions of React running, and it's usually done by mistake when it happens. If we add a warning and better docs around that I think that will help even more, but that also is not needed for the 16 beta release so I can open a separate issue for that.

Edit: for context, here is what it looks like in Fiber if you load multiple copies of React -

[gaearon]

I think adding a warning was discussed before (#2402) but there was no clear way of how we’d go about it. There are legitimate cases for independent Reacts on the same page (e.g. third party widget that you have no control over), and it works if they don’t “cross” with each other.

I think doing this in DevTools is a great idea though.

[flarnie]

Thanks for linking to that issue - that is great context. Looks like there was a warning, then it was removed, then it was added again, then removed at some point.

Was it a pain point for people to have the warning? I don't open a new issue if we've already decided that we generally support loading two copies of React and are not going to warn for it.

[gaearon]

I think the best explanation is in #3580 (comment). There are legitimate cases for when you’d want to do it. I agree we need to only warn for patterns that are clearly unsupported. DevTools seems like best of both worlds: it lets you know something is suboptimal, but doesn’t spam your console.

[nareshbhatia]

I am running into this issue with my app created with create-react-app. I am pulling in a library that uses react and also using Storybook from tests. I eliminated react from both those and I am down to one copy as indicated by npm ls react:

[email protected] /projects/myrepo/packages/myapp
└── [email protected]

Is there a way to figure out where react thinks the second copy is being loaded from?

[nareshbhatia]

Well, after a full day of trial-and-error, I figured it out. The second copy was coming from Storybook. The moment I removed it, everything started working. Wish React just told me where the second copy was coming from!

[nareshbhatia]

To resolve the issue, I tried to restructure my repo and move storybook to a dev dependency - hoping that it will prevent the second copy from being loaded. Unfortunately it did not solve the issue. I have created a reproducible example here: https://github.com/nareshbhatia/react-multiple-copies-issue. It contains my library in one package and an app in another package (created with create-react-app). Would really appreciate if someone could explain what is going on. How is the second copy being loaded?