Using absolute URL in pushState() doesn't work about history

[mjackson]

The goal of this library never was to support the pushState spec. Since we only support using pathnames, we don't ever need to check to make sure you're using the same origin, so we don't ever need to throw an exception.

I often run apps on the same host but different base paths. I worked around this by parsing the pathname out of the URL before calling pushState.

I'm not sure I understand your problem here. Can't you just use window.location.pathname?

[jkk]

Not supporting the pushState spec makes sense; I made an assumption based on the similarity in naming and arguments.

Background on my problem: I have an app installed at:

http://localhost/projects/myapp/

and I have a Link component (I am not using React Router) which turns this:

<Link href="/foobar">Foobar</Link>

into:

<a href="http://localhost/projects/myapp/foobar" onClick={...}>Foobar</a>

where the onClick handler interrupts the click and handles it with history -- passing the value of the href attribute to pushState -- instead of actually letting the browser follow the link. I want a valid href for server-side rendering, opening in a new tab, etc.

This worked when I used native HTML5 history, but not when I switched to your lib. Everything else about the transition was easy.

I adapted my code to pass pathnames to pushState, so it's not the end of the world if this library doesn't support absolute URLs. But the behavior -- browser navigating correctly but the listen callback returning bad info -- caught me by surprise and took some time to debug.

[mjackson]

browser navigating correctly but the listen callback returning bad info

What bad info did you get in the listen callback? Did you expect location.pathname to be /foobar?

[jkk]

If I was at the following URL:

http://localhost/projects/myapp/

And ran the code in my original post, location.pathname would be "http://localhost/projects/myapp/" instead of "/projects/myapp/". I.e., the absolute URL that was passed.

[jkk]

I can understand if your position is that, if you pass an absolute URL (bad input), things will act strangely (window.location.pathname will be different from the callback location.pathname).

I would argue, though, that if the lib does not support absolute URLs, an exception should be thrown if one is passed. There may be others, like me, that are transitioning their code from native HTML5 history, and will be confused by the strange behavior.

[mjackson]

Ah, I see now. Yes, that is surprising behavior.

Instead of throwing, what if we just silently do the right thing and give people the correct location.pathname?

[jkk]

Works for me! I would submit a patch but I'm short on time right now.

[mjackson]

Fixed and released in 1.6.0.

[jkk]

Perfect, thank you! This lib has been super helpful.