-
Notifications
You must be signed in to change notification settings - Fork 47k
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
nested contexts don't unwind correctly when server side rendering #12984
Comments
Is this the same as #12968? |
I suspect so. I didn't see this when I searched for an existing issue, apologies. |
No problem. Still happy to take a fix :-) |
Working on it ... |
After further analysis, I don't think |
Both issues are symptoms of the same root bug related to how |
…Issue #12984 (#12985) * Fixed an issue with nested contexts unwinding when server rendering. GitHub issue #12984 * Fixed an issue with search direction and stricter false checking * Use decrement infix operator * Streamlined existence checks * Streamlined assignment. Removed redundant comment. Use null for array values * Made prettier * Relaxed type checking and improved comment * Improve test coverage
Fixed in React 16.4.1. |
Do you want to request a feature or report a bug?
bug
What is the current behavior?
When different contexts are nested, as in they have different types, they do not unwind correctly when rendering via
renderToString()
.Here is a snippet that demonstrates the issue:
This results in:
What is the expected behavior?
When context providers are nested, they should correctly unwind such that the contexts return the correct value at each level. No exception should be generated and the output should be:
<div>A<div>B</div></div><div>A</div>
Which versions of React, and which browser / OS are affected by this issue? Did this work in previous versions of React?
This was uncovered using version 16.4.0 of
react-dom
on OSX using node v10.1.0.This only shows up when using
renderToString()
. It works as expected in the browser.** Note **
I wonder if this might be due to the following snippet of
react-dom-server.node.development.js
. Where the previous provider added to the stack is assumed to have the same type as the provider being popped.I am investigating further and hope to provide a pull request soon.
The text was updated successfully, but these errors were encountered: