Add state support to match()

[insin]

This would make it easy to pass state (e.g. req.body) without having to duplicate match()'s history creation in order to pass a location object in.

match({ routes, location: req.url, state: req.body }, ...

[mjackson]

Ah, clever ;) Thanks for the PR, @insin!

I'm a little uncertain about adding state as an extra option to match though, if only because it's unclear which state takes precedence if the user actually does give me a real location object.

Is it too much to ask people to learn how to use the history.createLocation API?

[insin]

I was going to use createLocation with 1.0.0-rc until I checked the latest source for the router and hsitory and noticed it's now a method; it felt a bit weird to create a object solely to use a utility method when the router would immediately be creating its own version of the same object and making the same method call with one fewer argument.

I could just create a single history object to reuse across all POST requests, so that works fine for me too if it's going to be the official way to pass state on the server.

[mjackson]

Ya, I agree the API is a bit awkward here. In the end, match is purely a convenience API. If I were you, I'd just copy the bits out of it that I need and not use match.

[timdorr]

Maybe it would be best to retire match from the final API? It serves as a boilerplate reducer, but with the caveat of abstracting away some key APIs.

Since most of the magic isn't in the actual wrapping of history.match, but in the creation of the history object, perhaps that should be what is being wrapped. E.g., have a convenience function for creating a server-side history object:

import { createHistory } from 'react-router';
const history = createHistory()
const location = history.createLocation(req.url)
history.match(location, (error, redirectLocation, nextState) => { /* stuff... */ })

Then you can set up your location object however you'd like and get full access to any history APIs.

[mjackson]

a convenience function for creating a server-side history object

Hmm, that's actually a pretty great idea. My only concern is that people are going to start using it client-side, and that's not something we want to encourage. We need to make it extremely clear that the createHistory function in your example is only to be used server-side.

[timdorr]

createMemoryHistory to indicate what's going on under the hood?

[insin]

👍 on having a function for creating a server history object with all the appropriate configuration.

Perhaps a leaf from React's book:

var { DO_NOT_USE_ON_THE_CLIENT_OR_YOU_WILL_BE_FIRED } = require('react-router')
var { createHistory } = DO_NOT_USE_ON_THE_CLIENT_OR_YOU_WILL_BE_FIRED

(Or you could include a non-production check which logs a warning if we appear to be running on the client - people really like not having any of those in their console)

[timdorr]

It's perfectly valid to create a memory history on the client. You lose a lot of benefits, but you won't explicitly break anything. Or get fired.

[mjackson]

I think I would prefer it if, instead of another option to match we allow the location option to contain more information. That scales better IMO.

[mjackson]

So, e.g.

match({
  routes,
  location: {
    pathname: '/the/path',
    state: req.body
  }
}, callback)

[insin]

Looks like a good solution to me. Closing this in favour of whatever comes out of #2186