入り口としてのKnockout.js 

自己紹介 ● ソフトウェアエンジニア ● 勉強会ではフロントエンドよりの話をしますがもともとバックエンド側の人です 

実際に仕事や個人プロジェクトで使っているもの ● Vue.js / React.js / Knockout.js ● 日付関係の処理 moment.js / 日付範囲はmoment.rangeで ● その他かゆいところに手が届く lodash ● WebStorage 関連 Store.js ○ WebStorageに絡む細かい差異の吸収 (Safariのプライベートモードで localStorage使えない問題も 代替手段で解決してくれるようで ) ● IndexedDB は lovefield ○ WebSQLさんは犠牲になったのだ 

フロント側のJavaScript ライブラリやフレームワーク 

● Angular ● React ● Backbone ● Vue ● Riot ● 生JSやjQueryで頑張る いろいろありますが今回はKnockout.jsです 

むかしむかし(2011年 震災直後) 当時は社内SEをしていて 社内システム構築をするプロジェクト jQuery + jQuery UI + jQuery 何とかをいっぱい使って、当時としてはかなりリッチなフロン トエンド（グラフィカルなスケジューラつき） PHP(CodeIgniter 2)を使ってバックエンドを構築 じきにこいつはJSONのクエリをSQLに変換して結果をJSONで書き出すだけのBOT化した 無事リリースしてユーザ部門も使い方に慣れて新機能の要望も出てきたあたりで 

あの・・・ いい加減jQueryでDOMいじるの辛いです・・・ 

jQueryだと辛いこと(1) どんだけ頑張ってもフロントからのデータ処理とそのデータをHTML上に反映させるため のDOM操作を書く部分が冗長 var data = {text: ‘Hello’, world: true}; var span = $(‘’).text(data.text); if(data.world){ span.addClass(‘hello-world’); } span.appendChild()・・・ 

jQueryだと辛いこと(2) (1)のせいで、UI部分はデザイン専門の方に奇麗にデザイン→ コーディングしてもらっても、結局プログラマのほうで自力やスクリ プト内でidやclassふるしかない →そのうち要素のidがかぶる、クラス名が長くなる事象が頻発する →かくしてデザイン専門の方がいじれない HTMLのようなおぞましい何かと名状し難い JavaScriptで 書かれたと思われる何かが出来上がり →デザイン用HTMLとプログラム用HTMLの差分が酷く二重管理というアンチパターン 

それでも まだjQuery関係だけで頑張れる範囲ではあったので細々とメンテ してました ただ、さすがにそろそろアカン・・・ということでこの辺の煩わしさか ら解放されるべく色々と調べてみたのが2012年末頃 

第一期　テンプレートエンジンの活用 jQuery.tmpl とか jsRender / jsViewあたり テキスト埋め込みの問題は楽にはなったものの、フォームとの連携 document.on(‘change’, ‘input[name=”foo”]’, function(){ … }); まだ手書きでイマイチ楽になった気がしなかった 

Knockout.js ● このテのライブラリとしてはかなり古参 ● DOMとJavaScript内部のオブジェクトを紐づけること以外は干渉してこない ● リアルなDOMとJS内のオブジェクトとの2way binding ○ Observable(監視対象)なオブジェクトの値が変更されると直接リアルDOMにも 反映しようとする ■ 最近のフレームワークはここをVirtualDOM経由にして差分のみ描画とか ● このリアルDOM直接というのが実はすごく大事で、同じくリアルDOM 直接派のjQuery系と握手できる 

そんなKnockout.jsの2017年現在での立ち位置 Microsoftの中の人が開発していてVisual Studio 2012 で多少日の目をみましたがとか くマイナーでリリース年から見ても「古く機能も少ない」イメージを持たれているのは確か ● SPA(Single Page Application)やRouter ● Virtual DOM ● Flux ● SSR(Server Side Rendering) 今をときめくフレームワークやライブラリには当たり前のように存在しているだろうこの辺の 要素があまりないわけで・・・ 

だが、それがいい 

当時欲しかったものの要件 ● 手っ取り早くはじめられるもの ● 当時はSPAにするつもりはあまりなかったので、ルーティングは要らない ○ URLごとにリロードする普通のWebサイト ● 既存のHTMLへの「ちょい足し」からはじめられる 

Demo Hello World 

Pros(1) ● 敷居が低く学習コストも低い ○ 基本的に超シンプル ○ チュートリアルが充実してる ● 大上段からコンポーネントやディレクティブといったものを作るのではなく既 存のHTMLにちょい足しするというアプローチから ○ Componentsの概念もあるけど他ほど必須ではない 

Pros(2) ● HTML上もdata-bindなどのdata-*属性なのでvalid ○ そこまで気にするご時勢でもない気もしますが一応 ● 書式指定（カスタムバインディング）を作るのも簡単な流儀に沿ったオブジェ クトを生やすだけ ○ 流儀＝createとupdate時のコールバックをプロパティとして持つ(どっち もoptional) ● jQueryプラグインを使いたいときは普通に使える ○ ちなみにknockout.jsはjQueryには依存しないPureJS実装です 

Cons(1) ● RouterがないのでこれだけでSPAは無理 ● 最低限のお約束以外は特にこれといった制約がないので大規模プロジェク トだと収拾がつかなくなる恐れがある ○ 泥縄式にこみいったことをやろうとするとdata-bind属性の中に延々と JSON文字列や挙句の果ては関数をリテラルで書いてることもあるので うまく ViewModel のメソッド化することが肝要 

Cons(2) ● たかだかテキストを表示させるだけにタグを用意してあげなきゃいけない ケースがあったりするなどDOMの制約をうける(HTMLのコメント形式な書き方や Knockout.Punchesという {{value}} な感じのテンプレート構文が使えるSyntax Sugerがプラグインであるのでだいぶマシになる) ● ko.observable() / ko.observableArray()という謎の物体 ○ observableな値の代入は関数呼び出しなので直感的にわかりにくい ○ knockout-es5というプラグインでもう少し楽に書けるようになる 

実際に手を動かしてみましょう https://github.com/takwat/knowledgeBBQ-Session-8 

何を訴えたいか ● XMLHttpRequestで出し入れするデータの保存先 ● データの画面(DOM)上の反映 Knockout.jsに限らず後者を自動的にやってくれる便利なツールは世の中にあふれてい ますので、そこを手書きはやめたほうがいいです Knockout.jsで感じがつかめると、Riot.jsやVue.jsも違和感なく入っていきやすくなります jQueryが辛くなってきたときの選択肢は持っておくべき 

ありがとうございました