React-router: Add "props" as an attribute when configuring a Route

[atrauzzi]

Plain and simple. Whatever gets passed in here is like as if they were defined as props on the routed component itself.

Reason: My components shouldn't need to be aware of react router conventions just to be passed parameters from wherever they're being called.

Example:

<Router>
    <Route path="/some/path" props={myBagOfData} component={UnawareOfReactRouter} />
</Router>

Can't call it props? Call it passthroughProps, the name doesn't matter. The concept here is that it needs to be easier to preserve standard react conventions without creating a two way coupling between routed components and react-router. Which is what happens when you make the expectation that components now have to access this.props.route to get at any values.

[taion]

You can trivially build an HoC that spreads the properties of this.props.route into the child's props. You can even use a custom route component that automatically applies the HoC.

I don't think it makes sense to explicitly bring this functionality into the router core.

[atrauzzi]

@taion I think you're mistaken. Your suggestion forces people to write boilerplate, essentially offloading extra work created by this library onto it's consumers.

Why should I take on the overhead of writing wrappers for each individual component I need to use?

[atrauzzi]

For what it's worth, I didn't open this ticket without doing prior research... I'm not the first person to need this and it's not exactly been clear over react-router's history as to what the best practice is.

• https://www.reddit.com/r/javascript/comments/2pteth/is_reactrouter_a_joke_how_the_hell_am_i_supposed/
• https://github.com/reactjs/react-router/issues/615
• https://www.reddit.com/r/reactjs/comments/45r58a/reactrouter_passing_props_the_2016_way/

(I don't want to spend my day producing links about this, but I'm sure you get the idea)

A higher order component seems like overkill given that most of the time people just want the props passed down 1:1. So why not include it, or include the _"custom route component that automatically applies the HoC"_? There's a lot of wheel reinventing going on here I bet...

[taion]

The HoC is literally just:

const withRouteProps = Component => (...props) => (
  <Component {...props} {...props.route.props} />
)

The cost to you in adding that is trivial. The cost to _us_ to adding that is expanding the API surface area in an arbitrary way that doesn't actually allow something new, or allow a meaningful change to UX.

Think about it this way. If you want to interact with things like params, you need to map those to locally significant prop names anyway. If reusing higher-level components is important to you, then you should think of your route components as doing that mapping of e.g. params.foo to just foo.

In which sense this is design-wise the wrong thing to ask for.

[ptica]

The cost to you in adding that is trivial.

really, for a newcomer not trivial: 20min reading various stackoverflow/github issues about just passing the dammed props, +20min for grokking the HoC :(

[taion]

Then just use props.route.whatever!

[tj]

I didn't realize how hard this was, I'm not using Redux in this project so it's really apparent now, had to do a ton of searching as well. There's no way something like this would get approved? Everything else feels like a huge hack for stateless apps.

[ryanflorence]

this isn't a pain in v4, just FYI.

[tj]

Nice yea I still have to check that out! Rocking the old style for now. Looks like route will do the trick! Google turns up a ton of crufty hacks but that's not too bad.