Changing hash in URL causes getInitialProps to be re-fired

[ldthorne]

Changing the hash in the URL causes getInitialProps to be fired, which I think should've been fixed in this PR. See the following example repo: https://github.com/ldthorne/nextjs-back-reproduction.

• I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

If the user clicks the go somewhere link that leads to an anchor -- which will add a hash to the url -- and then clicks the back button, getInitialProps should not be called.

Current Behavior

If the user clicks the go somewhere link that leads to an anchor -- which will add a hash to the url -- and then clicks the back button, getInitialProps is called.

Steps to Reproduce (for bugs)

1. Clone repo: https://github.com/ldthorne/nextjs-back-reproduction.
2. yarn.
3. Open dev tools.
4. Click the go somewhere link. Notice that nothing is logged.
5. Click the browser's back button. Notice that getInitialProps is logged.

Your Environment

Tech	Version
next	3.0.6
node	8.1.2
OS	macOS 10.12.6
browser	All

[ldthorne]

@arunoda it seems like you might have experience with this (based on the PR you opened) -- any thoughts on this issue?

[timneutkens]

So the issue here is that the hash change only checks as and you've not provided it. I guess this is kind of a bug 🤔 @arunoda will be able to give a definitive answer on how to fix it, since he wrote it 😄

[arunoda]

@ldthorne I'm looking into this today.

[ldthorne]

Hi @arunoda, any chance you've had any luck tracking down the issue?

[coluccini]

If you don't want to use route in anyway, I think has more sense to just use <a href="#somewhere">somewhere</a> instead using the Link component. Maybe your real use case has some other implication?

[ldthorne]

Thanks for the suggestion, @coluccini. I tried that in my example repo, but it still fires getInitialProps.

[coluccini]

Ups, I didn't read that this was happening when clicking back button. Sorry.

[ldthorne]

No worries. Thanks for your help!

[ldthorne]

Hi @arunoda, any chance you have any updates?

[michaeljonathanblack]

I'm looking into this now and I think I have a fix.

It appears to be that this.asPath was not getting set inside the Router hash change event, so the function which checks whether or not a hash navigation has occurred was using incorrect data.

I think I might take a look at a bunch of hash-navigation related bugs and see if I can make PRs for a them while I'm digging around in here...