Expose params on context?

[taion]

I'm writing a bit of code that uses this and I'm hitting something that touches on #2255, #2261, and #2172.

It's a little bit weird that I can access the current Location object from this.context.location, but I can't similarly access the route params via something like this.context.params and instead have to explicitly pass those params down.

It seems like for consistency it'd be ideal to treat the two identically - for doing something like building a relative Link, I'd like to have access in a nested component both to the current URL parameters (from params) and the query parameters (from location).

[timdorr]

This seems like a good idea. Literally the only problem I have is the name params being somewhat generic. routeParams maybe?

[taion]

routeParams means something different though. We'd have to call it like routerParams or routingParams or something. But both location and history are also somewhat generic-sounding as well.

[srph]

I feel that RR is polluting props and context. I want it to namespace to router (as in this.context.router.location), the same for props. But it would be a breaking change.

[timdorr]

@srph react-router only puts two things into context and props only reach down one level below the route, where you should have a component aware that it's in a router anyways.

I don't consider it unacceptable to add another context item, especially considering it's undocumented as of yet.

[taion]

It's actually documented now: https://facebook.github.io/react/docs/context.html

[timdorr]

s/undocumented/advanced and experimental/

[srph]

Desperately need this for <Link to={/users/${this.context.params.uuid}}> .. </Link>. Is there another way?

[taion]

I have a top-level App route that just puts the relevant bits of params on getChildContext.

[srph]

Thanks 👍, but I would still like to have this out of the box.

[taion]

I feel the same, obviously. It's a pretty trivial fix - just want to make sure that we're okay with this change.

[knowbody]

🚥 green light. Go for it @taion.

[taion]

@mjackson

Per 9d346fc#commitcomment-13933868 -

My first choice would actually be to only have history on child context. The motivation here is that it seems odd to expose location but not params.

I can revert #2336, but would it make sense to drop location? Or is it not worth making another breaking API change for that?

[timdorr]

I would leave location for now. This is supposed to be an rc version, so we won't ever get to 1.0.0 if we keep breaking APIs 😄

[taion]

Yeah /: Should we just back out #2336 then? Personally, it's really the inconsistency that bothered me more than not having access to params.

[timdorr]

Yeah, just revert that and we can discuss how we want to do it for a post-1.0.0 release.

[taion]

#2363

[knowbody]

closing for now with the revisit tag

[taion]

Eh, on second thought let's just not do this.

[timdorr]

Why not?

[taion]

For a use case like 9d346fc#commitcomment-13942354, #2186 is a much better way forward.

For something like relative navigation, this doesn't really help anyway without something like #2177 (comment).

On its own this change isn't really useful - it's essentially an XY problem, and it'd make more sense to track actual use cases.