-
Notifications
You must be signed in to change notification settings - Fork 46.4k
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
Fix context warning with non-pure getChildContext #3711
Conversation
It's a little hard for me to tell exactly why/if this is working/fixed, but it looks like there is a change in functionality here... Is ReactContext.current is getting merged when it wasn't before? Have we thought through the ramifications of that? Specifically, with regards to when the child warnings fire (or don't fire) based on the presence/value of a context variable? Is that the only functionality change? I'm not entirely convinced this is correct. Might be worth running through it in person? |
No, the merge happened before too; here I split _processChildContext into _getValidatedChildContext and _mergeChildContext. |
It looks like before the context was just from the element: https://github.com/facebook/react/pull/3711/files#diff-2ee62d642502ef4bdc3a6b3d18cd4f99R807 Where/how was it being merged before? Can you briefly describe why this works (ie. what did actually change in this diff)? |
Oh, no, you're right, there is a process context there. What is the diff changing? |
_processChildContext previously called getChildContext, then merged the result on top of its argument (which was either owner-based |
Ah, got it. You're right, child context doesn't need to be called twice because it's part of the current component. Duh; I was thinking about the wrong invocations of getChildContext. Ok, lgtm. |
Pulled in here: 80ea01d |
(Requesting merge to 0.13-stable.)
Fixes #3709.