-
Notifications
You must be signed in to change notification settings - Fork 51k
Fixed an issue with nested contexts unwinding when server rendering. Issue #12984 #12985
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
Changes from 2 commits
8ff3f62
27bb329
8d38f45
037c4d5
e69904c
731c686
6d31d3a
5114a3e
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -689,14 +689,21 @@ class ReactDOMServerRenderer { | |
| this.providerStack[this.providerIndex] = null; | ||
| this.providerIndex -= 1; | ||
| const context: ReactContext<any> = provider.type._context; | ||
| if (this.providerIndex < 0) { | ||
| context._currentValue = context._defaultValue; | ||
| } else { | ||
| // We assume this type is correct because of the index check above. | ||
| const previousProvider: ReactProvider<any> = (this.providerStack[ | ||
| this.providerIndex | ||
| ]: any); | ||
| // find the correct previous provider based on type | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This comment is redundant, IMO the code speaks for itself
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK |
||
| let previousProvider; | ||
| if (this.providerIndex > -1) { | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Seems like we can remove this condition? For loop already covers it.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK. |
||
| for (let i = this.providerIndex; i >= 0; i -= 1) { | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. If you don't mind,
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Done. I'm used to not allowing infix from our projects lint rules, old habits. |
||
| if (this.providerStack[i] !== null && this.providerStack[i] !== undefined && | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. So, do we actually need those checks? I wouldn't expect a provider "below" to ever be
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Agreed. But, Flow doesn't seem to be aware of that. Perhaps we need some special Flow syntax I'm not aware of, which is highly likely?
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I addressed this by changing the array definition to be stricter and pop via setting the length. It didn't seem right to allow |
||
| (this.providerStack[i]: ReactProvider<any>).type === provider.type) { | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This comment was about why we felt comfortable using Flow // We assume this type is correct because of the index check above.Please keep it above the // We assume this Flow type is correct because of the index check above.
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK. |
||
| previousProvider = this.providerStack[i]; | ||
| break; | ||
| } | ||
| } | ||
| } | ||
| if (previousProvider) { | ||
|
Collaborator
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Let's initialize it to
Contributor
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Good idea. |
||
| context._currentValue = previousProvider.props.value; | ||
| } else { | ||
| context._currentValue = context._defaultValue; | ||
| } | ||
| } | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does
.lengthassignment do in V8? I'd like to make sure it doesn't think the array length change is likely to "stay" because it changes all the time. I think just usingnullis more straightforward and less surprising to the engine (even though the typing isn't as nice for us).There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. But, going back to using
nullseems to require testing fornullwhen accessing array items by index, since Flow has been told thatnullandundefinedare expected array item values. Or, is there an alternate Flow syntax that allows us to remove the explicit checks?