Mainly Devel Notes

Twitter, GitHub, StackOverflow: @ovrmrw (short hand of "overmorrow" that means the day after tomorrow)

Knockout.jsの良いところ

Knockout.js(KnockoutJS)は変数を関数として記述しないといけないからめんどくさいという意見があるかと思うので、ここでいくつかメリットを挙げたいという趣旨の投稿です。
AngularとかVueとかちょっと旬なライブラリでは、おそらく内部的にsetter/getterを使うことでKnockoutのような記述をしなくてもいいようにしています。knockout-es5というプラグインを使えばKnockoutでもそういう書き方はできますが、毎回毎回それをやるかというとそれもめんどくさいので個人的にはあまり使わないです。(それにobservableを取り出す記述もめんどくさい)
ただそんなKnockoutの記述にもメリットはあるわけで。


1. 関数なので名前に日本語が使える
これはプロジェクトによっては重要だったりします。setter/getterを使う仕組みにおいては、JavaScriptにsetterかgetterのどちらかが2バイト文字に対応していないバグ(仕様?)みたいなのがあって日本語が使えません。

2. 関数なので全部参照渡し
これは個人的には大きいところです。特にスイッチのオンオフみたいな仕組みをHTML側に持たせるとBOOL値を切り替える処理をViewModelに実装するわけなんですけど、その値がプリミティブだと値渡しになってしまうので困るときがあるのです。全てが参照渡しなら、外部の関数に処理をぶん投げてそっちで処理するということが簡単にできます。
これに関してはそもそもJavaScriptが値の参照渡しをできるようにしておいてくれていれば問題にはなりません。

3. peek関数を使ってko.computedの発火を抑制できる
Knockoutは通常、ko.computedの中でobservable変数を参照するだけで、その値が変化したときにcomputedが発火する仕様になっています。この仕組みを利用するときもあれば、したくないときもあって、ViewModel側がどんどん大きくなってくるとko.computedの発火タイミングとかも細かく制御したくなってきます。
特に業務アプリケーションではViewModelのボリュームが半端じゃない大きさになるので無視できない部分です。

4. rateLimitを使って処理発生の頻度を抑えることができる
一画面に何百個、何千個のko.observableを描画しようとするとき、どうしてもDOMの処理を先に通したくなるものです。見た目の軽快感を演出するためにrateLimitで適切に処理の頻度を抑えたり先送りすることは必要になります。

5. 古いブラウザにも対応している
公式ページではIE6にも対応とか書いてあるのですがそんなことはどうでも良いのです。古いブラウザでも動くということは、初代iPad(iOS5)でも動くということを意味します。我が家では初代iPadも閲覧用端末として現役なんです。


上記以外にもライブラリの役割が明確で覚えることが特定分野に限られているので全体を把握しやすい、ドキュメントがとても親切で充実しているので(ある程度英語が読めれば)全体を把握しやすい、その気になればソースコード全体に目を通してなんとなく全体を把握しやすい、FirebugのDOMタブと睨めっこしながら開発を進めていけばなんとなく全体を把握しやすい等のメリットもあります。
個人的には伝説のクオリティと言われている公式のチュートリアルJavaScriptを覚えたので、こんなチュートリアルを作る人が作ったライブラリがすごくないわけがないという思いでこれからもKnockoutを使っていくと思います。