Welcome to WebmasterWorld Guest from

Forum Moderators: open

Message Too Old, No Replies

Headaches Implementing pushState & onpopstate

10:23 am on Nov 19, 2012 (gmt 0)

Junior Member

10+ Year Member

joined:Nov 22, 2004
posts: 140
votes: 0

I built a nice "ajax"ey website that was working pretty well. The homage page was a basic HTML page, and the "last" page was a basic HTML page. There was a middle page you'd use to get from the beginning, to the end. It was one page that would load data dynamically as you interact with it. (technically there are 5 different middle pages, but they are all independent of each other, just 5 different ways to browse the data on my site)

It worked pretty well. But the problem was what would happen when you were on the last page, and hit the back button. After considering my options, I decided to make a series of cookies that live for one hour. So on page load, javascript would look for the cookies, and if it found them, it would essentially reload all of the same data you'd get had you clicked on the real buttons you clicked on to get there in the first place. It "looked" like you were going back to a previous page. It worked really well. With one minor glitch, the URL didn't change. So the different states of the intermediate page were not link-able, and not indexable to any significantly degree.

The cookie thing worked really good, so I was satisfied. But then I added a "stats" page to this site, and it really made no sense to show these stats, if they didn't link back to specific states of the intermediate page, to actually show the data the stat was referring to. That's when I started messing with the new history stuff.

  • First, I used javascript to restore state from cookies on a page load. Rather than doing it in PHP, because it ultimately lead to less code and simpler code. But for these new 'fake' urls, I need to load data in PHP, otherwise the data won't be indexed and then theres very little point in doing this.
  • So I essentially had to duplicate both sides of my duplicate code. On the PHP end, I had pages that loaded the raw data, javascript would GET these urls and insert the data. Now I needed to duplicate that functionality on page load, if GET variables were set (these URL variables are the 'fake' urls being created by pushState). But don't forget about the javascript. I still need the original basic functionality, to load the data when you interact with the page. Then I need to also load the data off cookies when you hit back, for browsers that don't support pushState stuff. So you'd hit back and go from the "final" page, back to the intermediate page, where if I did nothing, would itself be reset back to normal. But now I also need to handle onpopstate events too.
  • Which has become a whole other mess. Besides the fact that FireFox and Webkit fire off onpopstate events at different times. Now I need to act on those events. The easiest way I came up with, was to simply reload the current page on an onpopstate event. That would reload the page, and the correct data would be loaded via PHP, because that info is in the URL at this point. But this doesn't work because the events are not always firing when I want them to.

All of the examples I've seen have have basically used this system to intercept clicking on regular links, so browsers that support state get an ajaxey experience, and browsers that don't jump from page to page the old fashioned way. But that's now how I'm doing things. Everyone gets the ajaxey experience of dynamically loaded data. Browsers that don't support that are not supported by the site. So my site doesn't fit into the mold of most examples that use this system.

Also, to make things a little more complicated: I was storing three pieces of data in "history" cookies, state, city, and a string of eight 1's and 0's, which I was using as switches for further filtering the results. But I'm not, nor do I want to, store the filtering options in the URL. So I still need that to load via cookies.

So at this point, I'm thinking pushState is nor for me. Or at least, not for this web page. I'm thinking I should revert everything back to the way it was a week ago where the only history saving was through cookies. The fact that google can't index the contents of the intermediary page, just ignore. Ultimately, it's probably not very relevant anyway. And as far as the stats pages linking to specific data (if you're following, the intermediary page lets you drill down results through state, city, and then filter those results by other properties), maybe just add on something with #hash links or something. Seems like adding that functionality will be significantly simpler than the mess I'm in right now.

My head is spinning right now, but I'm pretty sure I left out a few more things I had to re-write/duplicate in code to get things working.

I sure wish I could just give you guys a link to the site so you could see for yourself. I've only implemented pushStates on one of the 5 major sections of the site. The rest all still use my full cookie technique.

I'm not sure what the point of this thread is. I guess I'm kind of looking for vindication that pushState is a pain, and that in this case, it's probably best to go back to the cookie system that worked really well. And I guess I'm also asking for help if I'm using this system all wrong. And I'm also just ranting because it's cheaper than breaking things, and I'm definitely going to wait till another day before I start tearing apart all the work I've been doing over the past bunch of days.