3 ms·

While in the video he's updating the location hash (which breaks the backbutton), one can implement this using history.replaceState[1] to keep the back button w

While in the video he's updating the location hash (which breaks the backbutton), one can implement this using history.replaceState[1] to keep the back button working normally. He also mentions parsing the animated URL the figure out how far the video was loaded. So if you want you can use the animation in terms of navigation. Or alternatively just put the animation behind a separator and have your router ignore the animation part. This would preserve both the back button as well as bookmarking! Note that this video is more of the hacking nature what fun things can we do with the URL bar, he stated a number of times that it's more cool than actually useful. [1]: https://developer.mozilla.org/en-US/docs/Web/API/History_API#The_replaceState()_method https://developer.mozilla.org/en-US/docs/Web/API/History_API...

dspillett 7y ago
In the article it does state that the history API could be used and why it wasn't. The first point about updating the whole URL is easy to render moot: when you push new state using the history API, replicate the effect of location.hash by making sure you only change the hash part. The second part is the sticky one for the "ain't this cool" factor: the throttle in some browsers effectively limits constant animation to 3fps. This isn't an issue for things like the video progress example though: that only needs to update once per second. If you made a library to wrap this idea for easy reuse you could easily implement change detection and other rapid change throttling to smooth things out (so short bursts of many updates work, but longer bursts don't cause a complete stop until ~30s has passed) rather than having to implement these for each use of the technique. ("if" and "you could", because who in their right mind actually would?!)
- megous 7y ago
  All I know is he tried pushState. Perhaps replaceState is not throttled, because it doesn't create new history entries, just replaces the last one. Try this in chrome console. And yes, it doesn't throttle at all. i=0; setInterval(() => history.replaceState('', '', '/' + (i++)), 50); It's interesting how people will just believe everything, even if the test is 30 seconds away.
  - eridius 7y ago
    I just tested, Safari still throttles history.replaceState().
  - addicted 7y ago
    I'm pretty sure Chrome has different behavior with Dev Tools open and Dev Tools closed, and also with what it does with code posted in the console and code run as part of the page. So just because it is not throttled when run in the console doesnt necessary imply it wont throttle as part of a regular page as well.
    - megous 7y ago
      It does not in this case. It's just not throttled.
  - bspammer 7y ago
    I tried this and it still seems to flood my browser history. I can use the back button properly now though.

dspillett 7y ago

In the article it does state that the history API could be used and why it wasn't. The first point about updating the whole URL is easy to render moot: when you push new state using the history API, replicate the effect of location.hash by making sure you only change the hash part. The second part is the sticky one for the "ain't this cool" factor: the throttle in some browsers effectively limits constant animation to 3fps. This isn't an issue for things like the video progress example though: that only needs to update once per second. If you made a library to wrap this idea for easy reuse you could easily implement change detection and other rapid change throttling to smooth things out (so short bursts of many updates work, but longer bursts don't cause a complete stop until ~30s has passed) rather than having to implement these for each use of the technique. ("if" and "you could", because who in their right mind actually would?!)

megous 7y ago
All I know is he tried pushState. Perhaps replaceState is not throttled, because it doesn't create new history entries, just replaces the last one. Try this in chrome console. And yes, it doesn't throttle at all. i=0; setInterval(() => history.replaceState('', '', '/' + (i++)), 50); It's interesting how people will just believe everything, even if the test is 30 seconds away.
- eridius 7y ago
  I just tested, Safari still throttles history.replaceState().
- addicted 7y ago
  I'm pretty sure Chrome has different behavior with Dev Tools open and Dev Tools closed, and also with what it does with code posted in the console and code run as part of the page. So just because it is not throttled when run in the console doesnt necessary imply it wont throttle as part of a regular page as well.
  - megous 7y ago
    It does not in this case. It's just not throttled.
- bspammer 7y ago
  I tried this and it still seems to flood my browser history. I can use the back button properly now though.