Is patching window.history necessary?

[jaskp]

I've noticed that Wouter reassigns 'window.history.pushState' and 'window.history.replaceState'.

On first thought, it seems like this is quite sensitive to the order in which libraries load, one could for example store const pushState = window.history.pushState in some closure before Wouter patches it. Doing this with window.history.go causes an illegal invocation error but it doesn't seem that way with pushState.

So is there anything to lose from creating a wrapper around window.history instead of patching it? The navigate function is exported anyway, so I don't think it would change anything to have a wrapped history object in its closure. This is the way react-router does it, see createBrowserHistory().

What do you think? Did I miss something that's only possible with the patching method? Thanks!

[molefrog]

Hi, that is a good question. This patch is needed in order to intercept pushState and replaceState calls. There are events popstate (back/forward buttons) and hashchange, but for some reasons browsers don't expose anything that would allow to listen to pushState navigation. Imagine that you have an app that calls pushState outside or react for example a microfrontend. We need these events to keep location in sync.

[jaskp]

Thanks for the very quick answer! Will the navigate event solve this once it's widely available?

Meanwhile, is it correct that if your application code never calls methods on the window.history object directly, then Wouter doesn't need to listen to it? If so, then I believe it would be beneficial to be able to opt-in to pure behavior, many React users already have the intuition that state needs to be changed via hooks for React to know about it.

I would be more confident in suggesting this library instead of react-router to my team if we could somehow avoid the patching. Would you consider enabling something like that? I think avoiding the patching and writing useBrowserLocation ourselves isn't currently possible unless there's some way to write Symbol.for("wouter_v3") before Wouter loads, but that's pretty hacky

[molefrog]

Thanks for the very quick answer! Will the navigate event solve this once it's widely available?

Yes!

I would be more confident in suggesting this library instead of react-router to my team if we could somehow avoid the patching.

Well, this can be done via custom hook that uses global state instead. Here is a quick sketch (haven't tested, doesn't work with base paths etc.)

import { memoryLocation } from "wouter/memory-location";

// global in-memory location to store current path
const { hook } = memoryLocation({ path: location.pathname });

const useSafeBrowserLocation = () => {
  const [loc, setLoc] = hook();
  
  const navigate = (to, { replace = false, state = null } = {}) => {
    history[replace ? eventReplaceState : eventPushState](state, "", to);
    setLoc(to);
  }
  
  return [loc, navigate]
}

[jaskp]

While I'm still not totally comfortable with monkey-patching globals, I've come to the conclusion that

• if only wouter accesses history.pushState/history.replaceState, then patching them isn't a problem
• if some other code does access history.pushState/history.replaceState, then not patching would be a problem

That way it makes sense to me