@kyanny's blog

My thoughts, my life. Views/opinions are my own.

Backbone.History

Backbone.History を読んだ。ざっと眺めただけ。

http://documentcloud.github.com/backbone/docs/backbone.html

  • history.pushState or URL のハッシュ部分 (# 以下) のどっちかをよしなに使ってクロスブラウザで履歴管理を楽にやるためのラッパークラス
  • handlers は Backbone.Router を読んだときに出てきた、「URL がルーティングにマッチしたら呼び出されるコールバック関数」を入れておいたりするためのもの
  • getFragment のなかで、 pushState 利用モードのときは URL をいろいろ調整したうえで fragment にあたる部分を取り出す。 pushState じゃない場合は location.hash をみるだけ。
  • start は多重呼び出しされないようになってる。あと History API が利用できるかどうかなどもここでチェック。そして古い IE の場合は iframe を使うので this.iframe を初期化して navigate を呼ぶ。
  • pushState がある場合は popState もあるので checkUrl を popstate にバインド。 onhashchange があれば checkUrl をバインド。どっちもなければ setInterval で監視。
  • checkUrl で URL の変化を監視して変化してれば loadUrl を呼び出す
  • loadUrl のなかでルーティングにマッチするか調べて、コールバックを実行する
  • navigate のなかで変化後の URL を履歴に保存する。 pushState があればそれを使い、なければ iframe の location に保存する。

このクラスはけっこう動作のキモになるところっぽいけど、具体的に自分でコードを書いて使ってみないとピンとこない。あと、まず自分で pushState なり hash fragment なりを使って URL 遷移を管理するコードを書いてみて、その大変さとか面倒くささとかを体感しないとありがたみが薄くて感動が少ないのかもなーと思った。あと、本当はそれなりに面倒くさいJavaScriptとhistoryとAjaxのお話 - 愛と勇気と缶ビールなどを読むと History API まわりをクロスブラウザでちゃんと扱うのはなかなか難しそうで、 hist.js のソースを眺めて見比べると Backbone.History でちゃんともろもろカバーできてるのか?という疑問が。いちおう、適当な URL をブックマークしておいたり直接アクセスしてきても正しい感じに動作するように書かれてる気はするけど・・・。もしダメだった場合に hist.js なり代替のもっと高機能な何かと置き換えられるか?という点については、 Backbone.History はその他のクラスと全然依存してないので、問題なさそう。