You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'm pretty convinced at this point that Contexts are more useful in the Parent tree than the Owner tree. It also opens up new use cases for parent->child communication that wasn't possible before.
@sebmarkbage I'm not entirely sure exactly what problem contexts are meant to solve. But in the hypothetical context of reinvented styles (without selectors) I can imagine a benefit in being able to propagate hoveringOverTheBigButton (active/etc) to all descendants... and same for implicitly passing props from far up the hierarchy to far down (as is often requested). This should obviously be in the Parent tree then.
It seems that using a GUID style approach would be preferable for avoiding any and all conflicts, components would instead opt-in. Something like:
If someone who is more familiar with the React internals would care to put together a short summary of what needs to be done here, I'd be glad to give it a shot and make a PR. react-router depends heavily on context, and it's starting to break for some people's use cases.
Things I don't fully understand:
What exactly is the difference between the parent and the owner trees? Is one DOM-based and the other a React thing?
How might this change affect users currently using context?
I'd love to know more about when/if this might happen and what it will take to get there. I share @1st1's belief that this will make component/library composition better. In my particular case, I'm working on a library that wraps ReactRouter, and I'd like to be able to pass data down from my library, through the routes, and into the app's components. I can't presently do this without either a) changes by ReactRouter to support this directly, or b) the ability to pass a context into an app's already-created routes.
@sebmarkbage I assume we'll want to support reparenting someday… is there anything we need to keep in mind while doing this? Guessing not but wanted to check.
Things I learned yesterday while talking to @sebmarkbage about this:
The parent tree is made up of parent components, not necessarily DOM elements. The owner tree is made up of components that were on the bottom of the render stack at the time a given component was rendered.
Changing context to use the parent tree gets us one step closer to being able to remove _owner entirely, which is a good thing.
The vast majority of people currently using context should be unaffected by this change since the owner tree is by definition a subset of the parent tree.
Cool, glad to know this is on the way! I've also used context to pass down stores, out of a desire to avoid singletons. I've used them in a few other cases as well.
Activity
1st1 commentedon Sep 30, 2014
I'd be a big +1 for this. This would really make it much easier to design complex components in react.
syranide commentedon Oct 1, 2014
@sebmarkbage I'm not entirely sure exactly what problem contexts are meant to solve. But in the hypothetical context of reinvented styles (without selectors) I can imagine a benefit in being able to propagate
hoveringOverTheBigButton
(active/etc) to all descendants... and same for implicitly passing props from far up the hierarchy to far down (as is often requested). This should obviously be in the Parent tree then.It seems that using a GUID style approach would be preferable for avoiding any and all conflicts, components would instead opt-in. Something like:
But again, I'm not exactly sure what contexts are meant to solve so I could be way way of the mark here.
mjackson commentedon Oct 16, 2014
If someone who is more familiar with the React internals would care to put together a short summary of what needs to be done here, I'd be glad to give it a shot and make a PR. react-router depends heavily on
context
, and it's starting to break for some people's use cases.Things I don't fully understand:
context
?appsforartists commentedon Oct 16, 2014
I'd love to know more about when/if this might happen and what it will take to get there. I share @1st1's belief that this will make component/library composition better. In my particular case, I'm working on a library that wraps ReactRouter, and I'd like to be able to pass data down from my library, through the routes, and into the app's components. I can't presently do this without either a) changes by ReactRouter to support this directly, or b) the ability to pass a context into an app's already-created
routes
.sophiebits commentedon Oct 24, 2014
@sebmarkbage I assume we'll want to support reparenting someday… is there anything we need to keep in mind while doing this? Guessing not but wanted to check.
mjackson commentedon Oct 25, 2014
Things I learned yesterday while talking to @sebmarkbage about this:
context
to use the parent tree gets us one step closer to being able to remove_owner
entirely, which is a good thing.context
should be unaffected by this change since the owner tree is by definition a subset of the parent tree.sebmarkbage commentedon Nov 6, 2014
cc @JSFB
Start monitoring uses of withContext, related to issue facebook#2112
Don't log the callback function, related to issue facebook#2112
Fixed CR comments, related to issue facebook#2112
Fixed all unit tests for issue facebook#2112
62 remaining items
Switch to parent-based context. Fixes facebook#2112.
Switch to parent-based context. Fixes facebook#2112.
Merge pull request #3615 from jsfb/enable-new-context
Revert "Switch to parent-based context. Fixes facebook#2112."
Switch to parent-based context. Fixes facebook#2112.
danscan commentedon Jul 20, 2015
Does React Native use parent context now as well? Seems like it still uses owner context.
sophiebits commentedon Jul 20, 2015
React Native is still on React 0.13.2. We'll update after the 0.14 final release.
jedwards1211 commentedon Jul 23, 2015
Cool, glad to know this is on the way! I've also used context to pass down stores, out of a desire to avoid singletons. I've used them in a few other cases as well.
Remove superfluous form recontexting of Form children