history support (a.k.a. back button support)

[tylersticka]

Although theoretically possible, we should demonstrate some sort of history support in one or all of the demos.

If we find this to be a royal pain, we should consider augmenting the plugin to support it more easily.

(Original Twitter conversation)

[tylersticka]

I think this is working now in this historysupport branch: https://github.com/cloudfour/SimpleSlideView/tree/historysupport

In order to keep things fairly simple/lean, I have basically designed this to play well with History.js out of the box, but with the ability to supply your own history handlers if you'd like.

By default, it will never manipulate the history (since this could be an intrusive action). But if you pass along a library or object with getState, pushState and replaceState methods, it will use those to do so.

So if you're on a page and include History.js, enabling history support is as simple as this:

$('.views').simpleSlideView({ duration: 250, historyLib: History });

But if you want to get more custom, you could do something like this:

$('.views').simpleSlideView({
  duration: 250, 
  historyLib: {
    getState: function () { /* ... */ },
    pushState: function () { /* ... */ },
    replaceState: function () { /* ... */ }
  }, 
  historyChangeEvent: 'myStateChange' 
});

To keep things simple, it doesn't actually change the visible address bar URL right now. (Should it?)

@toddparker @scottjehl Do you think this implementation sounds kosher? Is it too presumptuous or too toe-in-the-water?

[scottjehl]

Hey Tyler!

Hmm. Well, I'm not positive on this but I'd think that if this is intended to be an in-page (single page) toggle, a hash change may be more appropriate than pushstate, and much lighter on its own to boot. Unless each state of your control is intended to map to a different server-side-refreshable page, that is.

I guess if I used this plugin, I'd expect that as I navigate from the list to a leaf node, the URL hash would update to match the ID attribute of the leaf section you navigated to, and focus() would be sent to that new section programatically as well. Then, a hash change back to whatever the URL was before the hash changed would re-show the original list. The hashchange handling logic could run on hashchange and onload to cover a deep link scenario to a leaf node. Naturally, this would allow the back and forward buttons to work as well. I guess with ARIA attrs and focus management tied-in to make it all accessible, the control could map pretty closely to an ARIA tabs control.

That said, if this is meant to map each section to a separate page resources on the server, pushstate and popstate sound like the right tool. An example of that would be something like jQuery Mobile, which updates the view with ajaxed-in full page content, and updates the URL with pushstate to match the deep link to the actual html page being shown.

As an aside: Alternatively, you might even get away with a css-only :target approach to toggling and deep-linking to the content. Not sure, though.

Sorry for the rambling!
Hope that helps
-Scott

[lyzadanger]

Hey guys,

Yeah, I could write a novel on the subtleties between pushing hash versus routing/full-monty-state (and I'm no expert!). For me it feels appropriate to push state for full and reals-like if one is representing a full routed request, and pushing hash when we're effectively "bookmarking" a present state in the (possibly single-page) app. As long as the forward/back buttons work (by god don't screw that up), then going lightweight here is probably for-the-YAY!

I guess this is pretty much rehashing what @scottjehl said ✌️

[tylersticka]

@scottjehl @lyzadanger Thank you both for your comments, I really appreciate them. This all started with me trying to augment just the demo to support history, and discovering lots of unexpected hurdles along the way.

The biggest hurdle: What's the best way of inferring the most appropriate slide direction on a hashchange event where it may not be explicitly defined (for example, an address bar URL change)? DOM order? Or maybe I should track the current "path" in some sort of object so we can guess if this is a "forward" or "backward" change? (I'm leaning toward that one.)

[tylersticka]

@scottjehl @lyzadanger Ah, the other reason why using hash changes kinda sucks... if I respect the same hashes that will resolve to element IDs with JavaScript disabled, I have to reset the scrollTop position or else the browser will "snap" to the top of the elements. Lame.