pushStateLocationPlugin does not recognize initial url

[afoninv]

(issue moved from ui-router/react repo, where it originally surfaced)

Seems like, when using pushStateLocationPlugin, whatever location user enters into browser address bar gets ignored by router (depending on configuration, this either redirects you to default state, or gets you nowhere at all).

Steps to reproduce:

1. clone ui-router/react repo
2. modify examples/animating-transitions/index.js to use pushStateLocationPlugin instead of hashLocationPlugin:

    ...
4.  import { UIRouter, UIView, pushStateLocationPlugin } from '@uirouter/react';
    ...
25. <UIRouter plugins={[pushStateLocationPlugin]} states={states} config={config}>

3. cd examples/animating-transitions && npm i && npm start
4. enter into browser address bar http://localhost:3000/about
5. get redirected to /home instead

If you disable initial rule on line 22, you won't even get to home state.
Using links works as intended.
hashLocationPlugin works as intended.

Latest version where pushStateLocationPlugin actually works seems to be 0.5.5 . Discovered this bug when trying to upgrade to newest @uirouter/react version

===

After some investigation, it looks like the offender is this commit: 0251424 .
In absence of <base> tag, it sets baseHref to location.href at the time of router initialization (changed in subsequent commits to location.pathname, but that does not fix the problem in question). This is OK if we use hashLocation, but for pushStateLocation this means, whatever url was originally entered into browser address bar, becomes baseHref.

[christopherthielen]

in case it's not obvious for somebody, a workaround is to add a <base> tag

[afoninv]

@christopherthielen Thanks for the heads up! This differs from the hashLocationPlugin behaviour and from previous versions, hence the confusion.

So the prerequisite to using pushStateLocationPlugin is having a <base> tag, otherwise it is not guaranteed to function correctly? Might be worth mentioning in the docs (although not sure where exactly)

[christopherthielen]

We now fall back to / if no base tag is present, but in general it’s encouraged to use an explicit base tag