-
Notifications
You must be signed in to change notification settings - Fork 47.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
react-is breaking change, re AsyncMode #13958
Comments
(Note that this blocks full enzyme support of react v16.6) |
Can you explain more about the case in which it’s breaking? |
sure - the enzyme react 16 adapter needs to maintain support for all versions of React 16. It provides a "getDisplayNameOfNode" function, which needs to be able to return the string In the 16.3-specific adapter, this isn't an issue, but it does have to lock the version of If |
I think that sounds okay, we could do it. PR? |
Sure, I'll try my hand at it! |
- Partial revert of facebook#13732 - Fixes facebook#13958.
- Partial revert of facebook#13732 - Fixes facebook#13958.
This is our mistake because we should have prefixed isAsyncMode with unstable_ which the actual api was. Or not included it at all. We’re treating unstable_ effectively as private and will break between minors. Are you ok with not supporting calls that are unstable_ in the future? Because we’ll break them several times between releases and don’t want to keep them all around in bundles. |
Prefix or not, renaming things is still going to break consumers. However, I understand react decides to accept this breakage in minor versions. Either way, the value of In this case, the bundle size difference is negligible - when this is the case, it seems worth trying to keep back compat, even on things react has decided are effectively private. |
The alternative is that we put it behind a feature flag and don’t expose the featur at all. But then it’s much harder for people to try it out for cases where breakages are ok. It’s really hard for people in many environments to use alpha builds. |
I understand the dilemma. In this case, the functionality hasn't changed, and I'm not sure why it was renamed - iow i'm not sure how it helps people try it out to have the name change now, when it's still going to have to change again when it gets promoted to being stable. The tradeoffs seem to be somewhere between "difficult for people to try it out", "cause breakage in some amount of downstream tooling", or "incur a tiny additional bundle cost to maintain back compat". It's a tough call, and I'm not asking for a policy change - but in this case, the bundle size increase of #13959 seems pretty close to zero (i can't imagine it's more than a handful of bytes), and the benefit is that enzyme (and presumably other downstream tools) will be able to continue using |
…k#13959) - Partial revert of facebook#13732 - Fixes facebook#13958.
It seems like react-is v16.6 no longer is compatible with React v16.3 - v16.5, in that React v16.3 - v16.5 will use
Symbol(react.async_mode)
, butreact-is
'sAsyncMode
export will instead beSymbol(react.concurrent_mode)
.It seems like the async mode symbol needs to remain the same in react-is 16.6+, and the
isAsyncMode
function would need to check both the AsyncMode and ConcurrentMode symbols.The text was updated successfully, but these errors were encountered: