Make a higher-order component to get the router from context:

[ryanflorence]

When React documented context we were like "YAY! we can just tell everybody to use context for the router." But we were probably over-confident in its stability and people's comfort with that API. I think we can wrap up everything into a higher-order component like:

import { withRouter } from 'react-router'
withRouter(SomeComponent)

// in SomeComponent
this.props.router

• We'll shield our users from context changes in the future and save much JSF
• We won't have to document the infinite ways that React + JavaScript + Babel can get router from context (Expanded API docs for context.router #3346)

We could probably even provide a this.props.confirmOnLeaveRoute shortcut like the Lifecycle mixin used to provide.

Whose with me?

(yes, this has been talked about before, thanks to those who tried to get this in before :)

Potential names:

• connectRouter like Redux. Seems weird to me, not sure if that name is about connecting to the store, or to the data in the store.
• injectRouter like React Intl. I'm also iffy on this since it's not technically "injection", you're asking for it, not injecting it.
• I like withRouter but whatever ... is there a community name for this yet? If not, can we start lobbying for this one?

[timdorr]

Adding it now...

[gaearon]

Yes please
(I like withRouter!)

[ryanflorence]

While we're on the topic, this is my new fav for context: https://gist.github.com/ryanflorence/1e1290571337ebcea1c5a748e8f5b37d

[ryanflorence]

@timdorr awesome :)

[benlesh]

What is the migration strategy for those currently using context? Will there be depreciation warnings with guidance?

[timdorr]

@Blesh Keep using it. This is just a convenience.

[gaearon]

This would be an addition—not breaking existing code. However I’d encourage to use it in case React changes the exact context API.

[ryanflorence]

@Blesh We can't deprecate React's context API, and we'll continue to provide the same object on context as we provide in withRouter, so both APIs are valid. The only problem would be if we decide to provide something different in withRouter than the object we put on context, which is hard for me to ever imagine being the case.

I'd probably suggest using withContext though, so when React change's context again, you can update to the latest React and Router w/o changing your own components.

[dlmanning]

Sounds oddly familiar

[ryanflorence]

@dlmanning

(yes, this has been talked about before, thanks to those who tried to get this in before :)

Was thinking of you :P At the time I don't think what we provided on context was as clean as it is now.

[Download]

I also like withRouter. Simple and clear.

Would it be possible to make this component in such a way that it can be used as a decorator (but doesn't have to be)? I really like how that works with connect from redux-router. I can just see it now:

@connect(myApp.todos.connector)
@withRouter
class Todos extends React.Component {
  clickHandler() {
    this.props.router.push('/yeah');
  }
  // ...
}

The name connectRouter doesn't really make sense. In Redux that term implies that we are listening to changes from the store. withRouter is better (and shorter! :)

[benlesh]

We can't deprecate React's context API,

Yeah, it's problematic that it's not opt-in when it comes to wanting to deprecate usage.

@ryanflorence couldn't you return a proxied router instance from getChildContext that puts a deprecation message in console while in development mode when its methods are called?

getChildContext() {
   var proxiedRouter = {
      actual: router,
      push() {
        console.warn('using router from context is deprecated, please use `withRouter` (docs link here)');
        this.actual.push.apply(this.actual, arguments);
      }
   };
}

(Sorry, I'm not familiar with the code-base, it's just a suggestion).