Navigating to a url, then hitting browser back, followed by attempting to navigate to the same page again dosen't work. about history HOT 5 CLOSED

Hello, thanks for your interest in this library. Hopefully we can get everything sorted out.

How do you know this is a issue caused by distinctUntilChanged()? Any chance you could get us some example code to which we would be able to reproduce this?

Regarding your question, there is a reason it was put into the library. When I was writing this I wanted a way to avoid rendering the same page over and over when 'navigating' to the route that I am currently on, and Rx provides distinctUntilChanged() which seems like the simplest way to accomplish this.

from history.

https://gist.github.com/hsubra89/bc54e3e4b471d0df019d

^ That Gist above is a small app that demonstrates what the bug is. Open the app, then hit "link 1". You'll notice the url has changed to reflect the change in history and will go to "/link1". Now go back and try hitting "link 1" again. You'll notice it won't change back. Clicking on "link 2" will work since its a different url. Removing .distinctUntilChanged will remove that issue.

I don't see a scenario where you'll end up rendering the same page over and over again, when the app is driven by url history. If it is necessary, the user can add .distinctUntilChanged to the url$ so that it becomes explicit to the user what the behaviour is.

from history.

I appreciate the gist, I've been able to recreate the bug in which you have described. I'd like to first gather feedback from the community to reach an agreed upon resolution to this behavior. Basically I want to find if others believe this behavior should be changed.

from history.

Its a fairly obvious problem that people are bound to hit on SPA applications where they move through the history a fair bit. Having .distinctUntilChanged in your code means that there's no way a user could over-write the behaviour without overwriting your function. However, making the user specify that makes things a lot more explicit and extensible. I'm not sure why we need to wait for community feedback on a rather obvious problem with a "history" library not doing what its supposed to. And again, I don't see how having .distinctUntilChanged helps at all. It dosen't actually do anything at that point since user interaction drives the history. and If people want the same page rendered multiple times, it should go through that sequence unless the developer wants to prevent them from doing it explicitly.

from history.

This is now fixed with npm version 1.1.0

from history.