Hacker News Reader

Comment by spotman | Hacker News Reader

> Today, the only option for ensuring an XHR request is made when the user re-visits a page via the back button is to (1) add an unload handler then (2) use cache busting.

I'm sure there is exceptions, but in general, the last thing I want my browser to do when i press back, is to start making requests. I expect the requests to have been already made.

View on HN

The result of this thinking is when I press the back button, I have to refresh the page manually because the data is stale.

My daily use case for this is Github Issues. Simple repro: Click an issue, make a change, press back.

Now the list view is out of date and doesn't show my changes. So I have to refresh.

I think a background XHR request is the best approach (until browsers fix this issue for real). On page load: pull latest from server (if network is down, then no-op). If no changes, then don't change. If there are changes then replace inline without a new page reload.

No!

If I click back I want to see what I saw last time. e.g. I might have seen 3 news articles I was interested in, I click though and read the first one. When I click back I want to see the exact same list as before, and be able to read the next article I saw; not new articles that have been written while I was reading the last one.

You can s/news article/github issue/ and my response is the same.

Perhaps the Back button should really be split into Back (cached) and Back (reload), since both of those are equally valid use cases. (Edit: the fact that the parent comment and another sibling comment here currently completely disagree is evidence enough that both options are necessary. I personally want both behaviours, depending on the situation.) No doubt the "UX experts" will complain that it's too complicated for "average users", but we aren't and don't want to be "average users" --- we want a powerful browser UI that lets us control our browsing experience better; that's something that seems to be rare in this age of increasingly dumbed-down UIs.

The difference is that you can go back and reload to do that with the preserved state model, but there's no way to go back to old state with a back-and-fetch model.

> The result of this thinking is when I press the back button, I have to refresh the page manually because the data is stale.

Okay. C-r is quick and easy to type. But if Back automatically destroys the old version of the page, then there is no way to restore that old page.

> My daily use case for this is Github Issues. Simple repro: Click an issue, make a change, press back.

> Now the list view is out of date and doesn't show my changes. So I have to refresh.

How is that different from one tab with the list of issues, and one tab with a specific issue? In the tab instance, GitHub has added JavaScript to the issue list page to refresh on changes; in the Back button instance, it should work identically: the list view is 'rehydrated,' the JavaScript does its thing and the list view is updated.

Reloading the page is completely, totally wrong.

Reply on news.ycombinator.com