0

1) Which JavaScript hashchange/history library/method should I use for my JavaScript application?
2) And how do I achieve these 3 things using that method?

A) When the page loads I want to parse the url hash/parameters and set the initial application state.
Specifically, my application consists of a Backbone Collection with two models which has attributes such as selectedCountry, selectedYear etc.
(I don't think I can use the Backbone.Router as this is a very customized visualization app with complex states?)

B) I want to set up a hashchange listener or similar that lets me update the app state correspondigly

C) On Backbone Collection change events I'd like to update the url. Important: I want to remove the hashchange listener temporarily while doing this so that there is no feedback loop.

Note: The app is already relying on some HTML5 technologies so the solution does not have to be compatible with the older browsers ... But the "feedback loop" part is important as I've struggled with this before ...

Thanks :)

James Allardice
  • 164,175
  • 21
  • 332
  • 312
dani
  • 4,880
  • 8
  • 55
  • 95
  • I'm working on one at the moment in my spare time. It doesn't work yet, but it will do all the things you want (supporting history object and hashchange as a fallback). If you wanna keep an eye on it or contribute: https://github.com/nathanmacinnes/Historic – Nathan MacInnes Oct 14 '11 at 13:37
  • I always wonder, on questions like this, if people are using hashes to convey data that really should be added to a query string instead. – Blazemonger Oct 14 '11 at 13:38
  • @mblase75 of course they are... that's why it's a bit of a hack. The reason for doing it in hashes is that you don't want the user to have to reload the page every time they do something. – Nathan MacInnes Oct 14 '11 at 13:41
  • hash fragment has been effectively re-purposed as sort of a client-side query string for triggering actions within your app but not triggering a page refresh/reload... – mattacular Oct 14 '11 at 13:57
  • @NathanMacInnes: Ah, cool :) It's a bonus if it will prevent the "feedback loop" and work nicely together with Backbone. How is it different from the other existing libs? Thanks. – dani Oct 14 '11 at 13:59

1 Answers1

3

since your already using Backbone, I would stick with Backbone's Router objects. It will be easier to use what's already available in your app instead of trying to bring something new in the mix.

As for your feedback loop problem, I've solved this by never firing my router methods from code.

The gist of it is that I let my JavaScript objects control the state of the application, and do the work for me. When I do call router.navigate, I never pass true as the second argument. I only call router.navigate in response to a state change in my app, to update the hash fragment in my browser window. Here's the thing: This is purely a response to the state of the application having changed. I never use router.navigate to change the state of my app.

Hope that helps

Derick Bailey
  • 72,004
  • 22
  • 206
  • 219
  • Sounds nice. Would this work with my setup? Model 1: year=1950, country=SE, mode=A. Model 2: year=1980, country=NO, mode=B. STATE => #m[0][year]=1950&m[1][year]=1980 or similar. Or what would it look like? Thanks - I'll read the blog post! :) – dani Oct 14 '11 at 14:04
  • should work fine. backbone routers can handle params on the end of routes like that. – Derick Bailey Oct 14 '11 at 14:04