V4 Router methods in props

[porfirioribeiro]

In my project i need to call transitionTo("/some/path") in a function to go to a different location.

That function is available in the router context, why not pass it down as a prop to the matched component?

My solution was to wrap match with the router from the context

import React from 'react';
import {Match, propTypes} from 'react-router';

const CustomMatch = (props, context) => {
  return (
    <Match {...props} render={(matchProps) => {
      const newProps = {...matchProps, router: context.router, ...props};
      if (props.component)
        return React.createElement(props.component, newProps);
      else
        return props.render(newProps);
    }}/>
  );
};

CustomMatch.contextTypes = {
  router: propTypes.routerContext
};
export default CustomMatch;

[timdorr]

I think we want to discourage imperative code as much as possible. It's almost always possible to do things declaratively.

However, there are edge cases and it's a matter of seeing how common they are. I know the plan is to put up resistance to API bloat because we want to be careful not to have to maintain too many APIs or make bad decisions with them. That was problematic in the 0.x and 1.0 days, so we don't want to repeat history (pun intended).

[rossipedia]

I think we want to discourage imperative code as much as possible. It's almost always possible to do things declaratively.

That's fine, but don't make it impossible. Sometimes imperative code is the right tool for the job.

[jampy]

I think we want to discourage imperative code as much as possible. It's almost always possible to do things declaratively.

This is just as saying that there should be no event handlers in React, IMHO.

[ryanflorence]

This is just as saying that there should be no event handlers in React, IMHO.

Once you're rendering, react gives you 4 imperative methods: setState, forceUpdate, replaceState, and isMounted.

setState and forceUpdate are the only ones that we are encouraged to use, and even forceUpdate should be used rarely, which leaves us with effectively only one imperative method: setState. So I don't think it's like saying there should be no event handlers. Otherwise there would would be no way to set state!

The whole point of setState is to change the state of your app and render something else.

The idea behind hiding all of our imperative API behind components is an effort to push all changes to state in your app (including the URL) to setState. Using router.transitionTo we now would have two ways to change the state of an app. It's the same reason we use controlled inputs instead of refs and DOM API like value or setAttribute.

By using Just Components™, we have effectively pushed all imperative code up to your app's opinions on state management. Are you using redux? Navigate with dispatch, component state? navigate with setState.

In other words, by using components and attempting to completely hide our imperative API, every question about routing can be answered by your app instead of our docs. How do you provide values to inputs? How do you change the active tab? How do you add another row to this table? You setState and render a component. Or with redux you dispatch and render. Or with mobx you set observable values and render.

The push-back we're getting is identical to the push-back we see when we talk about controlled inputs at our workshops. It's hard to rewire your brain to think this way, but I think it's worth it.

There's also a chance we've pushed the idea a bit too far here. I'm open to that, so we'll provide a withRouter HOC that passes the router as a prop to any component you want, but the docs will discourage its use while we continue exploring declarative routing.

[AsaAyers]

I have an example where router.transitionTo seems to be much better than <Redirect.

This morning I was working on building an Overlay view for my app. It's just a container that animates in. So that means it actually needs to always be mounted. I can do that by passing a function to Match:

                        <Match pattern=":id/edit">
                            {({matched, ...props}) => (
                                <Overlay
                                    {...props}
                                    open={matched}
                                    component={EditCollection} />
                            )}
                        </Match>

The overlay includes a button that closes itself by navigating to where the user came from. (not a back button, but pushing a new item into history that is the same as the previous one). If I setState and <Redirect, then if the user navigates back to the overlay it instantly redirects.

I can solve this by checking this.state in componentDidUpdate and reset the redirect flag if it shows up, but there's probably a reason that's a bad idea. I assume this eslint rule exists for some reason I don't now the details of. The intro talks about "property/layout thrashing" by causing extra renders. That probably won't break anything here, but setting a state for a single render and automatically resetting it doesn't seem like a good idea to me.

    componentDidUpdate(prevProps, prevState) {
        if (this.state.redirect) { // I'm not sure if I need this check
            this.setState({ redirect: null })
        }
    }

So for this situation where I have a component that doesn't unmount when the route changes, using router.transitionTo was a better fit.

[ryanflorence]

Why not use a ?

[ryanflorence]

blast, i'm on a phone so i can't edit the previous comment.

Why not use a <Link/>?

[AsaAyers]

Our Overlay is a modal with a specific style/animation. The child typically contains a form of some kind and needs to be able to close itself after a Save, Cancel, or Delete operation. Because Save and Delete should not close until the operation completes, it needs closeOverlay() to be passed down.

Cancel and the built in close button could be <Link, but then that pushes this same problem down into the form. Now the form needs to setState and render a <Redirect for the Save and Delete operations.

[ryanflorence]

The redirect would go away w/ the form state so it should work, right?

Anyway, like I said, we'll provide a HOC that'll pass router as a prop.

[jampy]

The whole point of setState is to change the state of your app and render something else.

Exactly. But to me the current route (the URL) is effectively a state, it's not rendered itself. It's a state that causes other components to render in a specific way (thanks to react-router).

We should "Make the URL your first thought, not an after-thought.", so why not manipulate the URL first and let the app render accordingly..

By using Just Components™, we have effectively pushed all imperative code up to your app's opinions on state management.

So let's say I have a component where the user can click to any x/y coordinate and this should navigate to a new URL containing the coordinates. How should that be done, then?

Like so?

handleXYClick(x, y) {
  this.setState({navigateTo: `/just/a/example/${x}/${y}`});
}

render() {
  return (
    <Whatever>
      <FancyUI />
      <SomeInputForm 
         foo=1
         bar=2
         baz="whoo
      />
      <ImageMap onClick={handleXYClick} />

      { this.state.navigateTo && <Redirect to={this.state.navigateTo} />}
    </Whatever>
  );
}

Maybe (probably) I'm completely missing something, but if that's the way to do - how is that any better than using an imperative method? In the end, this looks still like imperative style to me and just makes the code harder to read...

This is just a completely fictitious example - I'm just trying to show my point.

Are you using redux? Navigate with dispatch

Yes, I'm using Redux, but since react-router is still in "alpha" state, there is no matching react-router-redux version, yet.

Until we're there, I'm using my own implementation that's based on an react-router-redux fork. That fork does not (yet) give me the necessary dispatch action to navigate, that's why I added my own changes.

I was having a really hard time to figure out how to change the URL in my Redux routerMiddleware() as I can't use <Redirect>there.

In the end I gave up and simply did a (really, really ugly) window.location.hash = location.pathname; hack. It works absolutely fine, but... you know... don't tell anybody...

After all, I really hope that V4 will be released soon and react-router-redux will follow soon thereafter (a great combination!) - then I will throw away that hack and just use that...

[mikesparr]

Similar issue here. I pop up a modal for social network login and pass it callback. The callback, upon success, needs to then redirect the page to close the modal. The callback function is in index.js (same as my <BrowserRouter> ... <Match>) so unsure after social login how to call a redirect?

I tried importing browserHistory and passing it to ... and then in my function browserHistory.push('/dashboard')... It complains cannot find method push of undefined.

This seems way too difficult for something so trivial in any app. How in a function (not a component) could I leverage the <Redirect to='/dashboard'/> without building a component and calling render() ???

[ryanflorence]

Anyway, like I said, we'll provide a HOC that'll pass router as a prop.

[mikesparr]

If I want to access the router from the same file I imported it, how can I access it? I have no problem accessing it from sub components called during Match (using context), but from the original file with my routes (where my function for auth lies), it cannot access it to do redirects?

import Match from 'react-router/Match';
import Miss from 'react-router/Miss';
import Link from 'react-router/Link';
import Redirect from 'react-router/Redirect';
import {BrowserRouter, browserHistory} from 'react-router';

const auth = {
   uid: null,
   authenticate() {

   },
   authHandler(err, authData) {
      if (authData) {
           // store in database

           // redirect ?????????
      }
   }
}

// ...  followed example from your docs on Redirect(Auth) workflow
// needed to be able to call 'auth' from other components which I passed via props
// since callback from social login (Firebase) performs here, cannot figure how to access router to redirect???

const Root = () => {
    return (
      <BrowserRouter history={browserHistory}>
        {({ router }) => (
          <div>
            {auth.isAuthenticated ? (
              <p>
                Welcome! {' '}
                <button onClick={() => {
                  auth.logout(() => {
                    router.transitionTo('/')
                  })
                }}>Sign out</button>
              </p>
            ) : (
              <p>You are not logged in.</p>
            )}

            <Match pattern="/login" component={Login}/>
            <MatchWhenAuthorized 
              pattern="/dashboard" 
              render={() => <App auth={auth}/>}
            />
            <Match pattern="/" render={() => <Home auth={auth}/>}/>
            <Miss component={NotFound}/>
          </div>
        )}
      </BrowserRouter>
    )
}

render(<Root/>, document.querySelector('#main'));

[ryanflorence]

It's right there in your BrowserRouter child callback. Unless there's a bug, that's the exact same thing on context.

[mikesparr]

Outside of Root, however, no access to it. See above I have some other objects declared in file like you guys did fakeAuth...

So I perform Match on / which takes me to Home. Within home I have login button and call this.props.auth.authenticate() which is reference back to the index.js file with routes... it calls authenticate() which calls Firebase facebook login and gives it authHandler as callback.

After Firebase authenticates and executes authHandler, that object does not have access to router to perform redirect.