Usage of history API in Redirect/onEnter

[chrisui]

I've hit a bit of a blocker trying to implement enhancers on the History api which is then used by React Router. It turns out that the onEnter callback does not have any access to the history like other first-class consumers, such as Link, do. This means that we miss out on any of the enhancement we provide to history in redirects.

Pointer to usage in Redirect: https://github.com/rackt/react-router/blob/master/modules/Redirect.js#L34

I can see why having access to history.pushState and other side-effect history methods would be dangerous but how about being able to call history.createPath etc? This may also simplify the implementation of Redirect.

Just wondering if anyone else has come across this limitation or whether it has been considered?

As an example of my usage I have allowFullyQualified (allows linking/redirecting outside of current app - ie. http://google.com/) and allowNamed (yes, named routes ;) enhanchers on our history.

[taion]

What specifically are you trying to do?

Our goal for this sort of use case is something like remix-run/history#141, where enhancers just wrap push and replace to handle everything you need.

[taion]

So to be more concrete, for named routes, you'd do something like history.push({name, params}), or in your case just call the replace callback with a {name, params} object or whatever.

[chrisui]

One example is pretty much this (we have several apps which share components and different routes):

<Redirect from="/reset-password" to="http://manage-user.com/reset-password">

The allowFullyQualified enhancer will detect that there's a fully qualified redirect match and so update link href's accordingly but, sadly, the redirect cant do this.

That history api change looks like it might do the trick though! Would createPath etc receive the same object?

[taion]

Okay, I see - I think you might just want a separate <Redirect> helper in your case. The current one is pretty fixed on only doing internal redirects, and I'm not sure that there's a really great way to evolve it to be generic with the current relative path handling, and the way it merges the previous state.

The history API doesn't really use createPath directly, but the idea would be that e.g. a useNamedRoutes history enhancer would take care of everything.

[taion]

Anyway, I think you'd want a separate <ExternalRedirect> for the above case. Ideally the APIs we're adding will let you call e.g. replace({name: "foo", params: {...whatever}}) for the other case. Going to close this for now, but let me know if I've missed some use case.