Replacement of RefreshLocation?

[jlongster]

In 0.13 there was a concept of a RefreshLocation which told he router to refresh the page for every URL change. I don't see a similar history for that. I can see how that makes sense, but how should I go about using react-router but wanting full refreshes?

I know it's not a common use case. Right now I just use normal a tags instead of Links, and I do window.location.href = ... instead of the previous router.replaceWith. But it would be nice to not have to change make once I can make my site use pushState.

[knowbody]

@jlongster there are couple of issues on that already. See #2097 or #2038

[jlongster]

None of those issues really address this. In 0.13 I could just use Link and write code against react-router like normal, but just like you tell react-router to use hash history or browser history, you tell it to use "refresh" history and it would just do a full refresh for each URL instead of re-rendering React and using pushState.

This was a core design of previous react-router versions and it makes me sad to see it go away.

[jlongster]

The reason this is important is integration with non-React systems. I'm not trying to do anything weird. I just can't only rerender the React parts, and other things mutate the page so I need to fully refresh.

[taion]

This should really go on rackt/history, no? i.e. you're saying that there should be a createRefreshHistory that always refreshes, rather than just as a fallback to createBrowserHistory when HTML5 history isn't available.

[jlongster]

@taion Good point. I'm not really sure what the solution is. I'm doing some thinking about it right now. It's easy for me to create own thing that sort of works, but the thing I don't like is not being able to use Links, but I might be able to get around that too. I'm up for figuring out how to do this in userland, but I'm not sure there's a clean non-hacky way yet.

[mjackson]

When I extracted the history stuff into its own package, it seemed sufficient to me to think about the problem in terms of URL schemes instead of behavior. What I mean by that is, there are two URL schemes: "clean" URLs (using pushState) and hash-based URLs. My thinking was that you would just choose one scheme and the lib would do the right thing based on what the browser supported. In the case of clean URLs, if the browser supports pushState we use that. Otherwise, we use full page refreshes.

Let's follow up in remix-run/history#95

[knowbody]

interesting, thanks for opening it @jlongster. Now I understand what you meant. sorry for closing.