Trying to understand how to work with the History API. It seems to have figured out the main thing. I change the address and title using window.history.pushState(data, title [, url]) , no problem with that.

Now I am trying to understand how the "return to the previous page" should work. Now if the user clicks "back", the address changes, but the page itself does not change.

Suppose there are 2 pages:

www.example.com/

www.example.com/test

The user initially enters the page www.example.com/, clicks on a certain button, which causes the loading of certain forms and the change of the page address to www.example.com/test. If the user presses the back button, the address changes to www.example.com/, but the page itself does not change at all.

Question: so it should be?

Maybe I misunderstood, but, in my understanding, there should have been a return to the status of the www.example.com / ... page. Or does it work differently, and we must also track the return back and prescribe the entire "reverse" on js?

UPD

@TheDoctor , Then I do not understand where I could make a mistake. Maybe not so formulated. I will try to explain in more detail, removing all unnecessary.

Suppose on the main page only 2 div blocks c id "div1" and "div2" respectively. Div2 is initially hidden (display: none). div1 is displayed and occupies a certain area. Clicking on div1 causes the div2 block to be displayed and changes the current address from / to / test (using history.pushState).

This is how it works, if the user initially opened /, if the user opened / test, the server produces all the same 2 blocks, only div2 is already displayed (display: block) immediately.

If the user opens the page /, clicks on div1 (the page address changes to / test and div2 is displayed), then clicks "back", should the div2 block become invisible again? Now the block does not become invisible. Just the address changes and that's it.

  • > then press "back", should div2 become invisible again? No, it should not. - romeo

2 answers 2

You just change the URL (logical transition), i.e. the page "physically" does not change, because the content loads ajax / websocket / other "transport". It is necessary to track the change of URL on the client - routing by URL. See how it is done in Angular or Backbone . Those. SPA turns out.

  • Thanks for the reply and links. In general, there are no problems with the implementation, but it just turns out that you need to write a bunch of code to return to the previous state (after the user returns to the previous page), which I didn’t want and don’t want for now. He sighed and took the path of least resistance, replacing all pushState with replaceState. It seems like not very good, but now the "back" will be at least more understandable to the user than simply changing urls. - Floyat

Also faced today with this issue. Perhaps my decision is fundamentally wrong. In my application, the ajax request returns an array of a new link and a piece of html code

 data['html'], data['link']

I put this array in the first parameter

 history.pushState(data, null, data['link']);

Then I add a handler to switch history. If, when returning to the previous page, information about the previous ajax response exists, then replace the content, otherwise reload the page.

  window.addEventListener('popstate', function(e){ if(e.state != null){ $('.somewrapper').html(e.state.html); } else{ window.location.reload(); } });