|Headaches Implementing pushState & onpopstate|
| 10:23 am on Nov 19, 2012 (gmt 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)
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.
- 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.