Proposal: Add props argument to willTransitionTo

[mjackson]

It would be nice to have a mutable props argument in willTransitionTo so we can derive props from the params and/or query that will be passed to the route handler component.

var User = React.createClass({

  statics: {

    willTransitionTo: function (transition, params, query, props) {
      transition.wait(
        getUser(params.userID).then(function (user) {
          if (user) {
            // Mutate the props arg to set custom props.
            props.user = user;
          } else {
            transition.redirect('home');
          }
        })
      );
    }

  },

  // Now we can more clearly declare what props we need.
  propTypes: {
    user: React.PropTypes.instanceOf(User).isRequired
  },

  render: function () {
    var user = this.props.user;
    // ...
  }

});

[ghempton]

👍 I was just looking for something like this in our app.

[ghempton]

Along the same vein, it would be nice to have access to the context in these hooks. In our app we store an object in the context that performs our ajax methods for us. This would also be analogous with a lot of the hooks in React proper.

[mjackson]

@ghempton awesome, thx for the feedback. Agree about the context. That would be great to have here.

Quick question: is there ever a time when you need to asynchronously set props? i.e. without using transition.wait ? In other words, do you think there is a valid use case for allowing the transition to proceed, but still allow the user to set props sometime later?

[ghempton]

Seems like an anti-pattern to set props in that hook if the transition is sync– akin to calling setProps on itself. These corner cases make me think that all transitions should be async.

[mjackson]

If the transition is sync, the example I posted doesn't really change much. Just gives you a place to derive props from the params/query. This lets you use React's props validation, which is a nice benefit.

var User = React.createClass({

  statics: {

    willTransitionTo: function (transition, params, query, props) {
      props.userID = params.userID;
    }

  },

  // Now we can more clearly declare what props we need.
  propTypes: {
    userID: React.PropTypes.string.isRequired
  }

  // ...

});

[ghempton]

Ah I thought you meant still setting the props async even in a sync transition...

In the sync case, however, manipulating props in willTransitionTo seems redundant. Should be done in componentWillReceiveProps and just read the params in there.

[rickharrison]

One thing to think about is what is shown during transition.wait. Is it a blank screen? Can we specify a loading component to render until the transition is completed?

[mjackson]

@ghempton componentWillReceiveProps is not called for the initial render, only when props change, so it's not a good place to derive props. Also, it's an instance method, and instances aren't supposed to set props on themselves. The fact that willTransitionTo is a static method means we can set props using the router.

@rickharrison Yes, calling transition.wait prevents the router from proceeding with the transition until the promise resolves. If you'd like to show a spinner or something then don't use transition.wait. Instead, just check for the props/state you need in render as you normally would.

What I'm asking is if there's a real use case for async props...

@rpflorence Any thoughts?

[rickharrison]

@mjackson I definitely have a use case for async props. For my particular use case of authentication, it is not as simple as storing that they are logged in. I need to hit my API to check and make sure that their token is valid. Currently, I do this in willTransitionTo with a mixin. If I wanted to show a loading in render, I would have to duplicate the code in every single route that requires authentication rather than sticking it in a mixin. That is why I would like some way to show a loading state during transition.wait

[mjackson]

@rickharrison Sounds like you need getAsyncProps ...

[ryanflorence]

@mjackson I once thought it would be nice to send the route descriptor in, just sending props is probably safer. 👍

[ryanflorence]

@mjackson hmm ... I think I'd rather have getAsyncProps allow you to do it sync or asynchronously, otherwise you have two places you're setting the props for a handler.

Furthermore, if we do the handlerProps thing discussed elsewhere (#314) now we've got all sorts of props stuff going on. Then when I'm trying to decide how to get props into my handlers I'm like

[mjackson]

The whole story around props has changed with 0.11, so I don't think this is necessary any more. Closing for now.