Switch the Context to use the Parent tree instead of the Owner tree

[sebmarkbage]

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.

[1st1]

I'd be a big +1 for this. This would really make it much easier to design complex components in react.

[syranide]

@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:

var Child = React.createClass({
  contextSources: {
    ancestorIsHovered: Parent...hovered
  },
  render: function() {
    return <div>{this.context.ancestorIsHovered ? 'Ancestor hovered' : 'Ancestor not hovered'}</div>;
  }
});

var Parent = React.createClass({
  childContextTypes: {
    hovered: React.PropTypes.boolean
  },
  getChildContext: function() {
    return {hovered: true};
  },
  render: function() {
    return <Child />;
  }
});

But again, I'm not exactly sure what contexts are meant to solve so I could be way way of the mark here.

[mjackson]

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?

[appsforartists]

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]

@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]

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.

[sebmarkbage]

cc @JSFB

[gaearon]

+1 for this. So happy this is finally being worked on!

We use context indirectly through react-router, and use it directly for analytics (e.g. in which of several "areas" of the screen / on which screen was "Sign Up" button pressed).

Another use case is when we want some pages to be "themed" with a specific background color and we'd like all controls, no matter how deep in hierarchy, be able to use this color (can't do this in CSS because we want to calculate whether text needs to be dark or light based on that, etc).

[natew]

@jamesknelson is this enabled in RC2 or would it be worth updating and trying the patch there?

[zenlambda]

Is there any chance that we might get some documentation on how contexts work? I've seen a vague mention of this feature on the React blog. I've seen it in use in other projects such as React-router and perhaps also Reapp. There is code in those projects that throws warnings and needs migrating. I'd love to contribute but I feel unable to help make the situation better because I'm still in the dark about how contexts are supposed to work.

[esamattis]

@zenlambda maybe this will help https://www.tildedave.com/2014/11/15/introduction-to-contexts-in-react-js.html

[natew]

Just as a heads up to anyone using the contextPatch and running into type.toUpperCase() is undefined errors, this just bug bit me and drove me mad for the last couple hours.

If your child Class is attempting to use an undefined component this happens. In my case I was trying to import "Textarea" rather than "TextArea".

I was certain the error was due to how I was mounting routes (in the parent class) and funny enough both children routes I tried had this same Textarea bug, so I spent forever changing the parents until I got this. 💀

[1st1]

Any chance this will land to 0.14?

[sophiebits]

@1st1 That's the plan.

[danscan]

Does React Native use parent context now as well? Seems like it still uses owner context.

[sophiebits]

React Native is still on React 0.13.2. We'll update after the 0.14 final release.

[jedwards1211]

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.