Wanted: blessed access _owner

[mjackson]

Over in the react-router project we would really, really like a "blessed" way to access the component that was on the bottom of the render stack at the time another was rendered. ReactCompositeComponents currently have a reference to their "owner" component using this._owner, but it looks like it's going to be removed.

I'm currently trying to understand the reasons for wanting to get rid of _owner so that we can find a way to satisfy those concerns but still preserve access to a component's owner in some way.

There are lots of places in the DOM API where you can go back up the tree, including parentNode, ownerDocument, parent, and ownerNode. Being able to essentially do the same thing in React's component API would be incredibly useful.

[sophiebits]

Are you asking for the parent or the owner? In the case of passing components around, these are different. Consider:

// A:
return <B><C /></B>;

// B:
return <div>{this.props.children}</div>;

C's owner is A but it's mounted into a div (and that div's "parent" is B, I suppose).

Concrete use cases would be helpful. (It doesn't look like there are any uses of _owner in react-router right now?)

[mjackson]

The thing I'd like access to is owner. I can always get the parent element using a combination of getDOMNode and the DOM methods.

We don't currently use _owner anywhere, but I do have a branch that makes use of _owner to help <Link>s find the <Routes> they are owned by.

My use case is this:

<Link>s in react-router need to know whether or not they are "active". In order to do this, they need to check to see if their path matches the current URL. On the client, this isn't a big deal since there is only ever one URL. So we can just keep active state in a flux-style store and it works fine.

On the server (rendering components server-side) we may have many URLs at once because a server processes multiple requests concurrently. Thus, keeping "active" state in a store doesn't work.

The solution I'm using in the active-routes branch is to keep active state in the <Routes> component, instead of a typical store. We need <Link>s to be able to traverse up the render hierarchy to find the <Routes> they were rendered under. Otherwise we need to pass the <Routes> arg (or some other "state" object) around to all our <Link>s.

[sophiebits]

Sounds like the parent hierarchy would work just as well for this – the Routes component will still be at the top. This is probably best solved by contexts (still undocumented; currently owner-based but soon parent-based per #2112).

It may also be worth encouraging the use of https://github.com/brianmcd/contextify for server rendering so that the execution environments are completely isolated (that's what react-page does).

[mjackson]

Does the parent tree give me access to the component instance? Or just the DOM node?

[sophiebits]

I wasn't proposing any particular API, but it could give access to the instance.

[mjackson]

In that case, yes. That could work.

Does React put any properties on the context by default? Or is it derived solely from an object the user provides to a descriptor?

Edit: Just wondering how I might use this.context to traverse the (currently) owner hierarchy.

[sophiebits]

The idea is you could have the Routes component return in its getChildContext method whatever info the Link needs and then the Link could access this.context.routeInfo.blah or whatever. This commit message and tests gives a general idea of the API:

b91396b

(withContext is probably going away, use getChildContext instead.)

[mjackson]

@spicyj Thank you very much. Contexts work beautifully for my use case. Closing! 🎉