-
44x1carbon
- 1027
- 2
- 0
- 0
-
- いいね！0
関西フロントエンドUG
@frontkansai
【グランフロントエンド2016】SESSION3、@sairoutineさんによる「Mithril-軽量・高速なMVCフレームワーク」が始まりました。 #frontkansai
2016-08-28 14:55:38発表資料
sai 🥝
@sairoutine
Session 3 の発表させていただく資料です〜。 / 「Mithril - 軽量／高速なMVCフレームワーク」slideshare.net/sairoutine/mit… #frontkansai
2016-08-28 14:38:46ツイート
にわタコ
@niwatako
どんなフレームワークか MVC(Model, View, Controller) ViewModelという概念を追加してMVVMで設計するとSPA作るにはより良い設計になると思う #frontkansai
2016-08-28 14:59:54
にわタコ
@niwatako
Model JavaScriptのオブジェクト(Mithrilフレームワークにロックインしていない) Getter-Setterを自動生成（使わなくても良い #frontkansai
2016-08-28 15:00:37
にわタコ
@niwatako
View 稼働DOMを返すJS関数 コントローラの保持する状態を参照できる 更新する旅再描画するので気をつkる #frontkansai
2016-08-28 15:01:04
にわタコ
@niwatako
Controller Viewやモデルの初期化を担当 Modelを持ってViewがControllerを通してModelにアクセス #frontkansai
2016-08-28 15:01:33
にわタコ
@niwatako
ViewModel 使うとより良く出来る 永続化する状態はModel、永続化しない状態はViewModelみたいな形をよく見る。 ここをシングルトンにしておくと、SPAでページ遷移の状態を残しておいたり出来る #frontkansai
2016-08-28 15:02:11
にわタコ
@niwatako
Component Reactと同じような概念で作ることも出来る。ControllerプロパティとViewプロパティを持つ。1ページに1コンポーネントの形で使う。コンポーネントの中で別のコンポーネントを呼び出す再利用可能 #frontkansai
2016-08-28 15:02:58
にわタコ
@niwatako
仮想DOM 何故かそうDOMが必要か HTMLのDOM変更コストはとても高い。ツリー構造のデータを上から走査して座標計算やCSS再計算を行う 。 #frontkansai
2016-08-28 15:04:22
にわタコ
@niwatako
実DOM変更をなるべくブラウザにさせないためにjQueryで差分追加変更削除するコードを書いて、極力DOMの変更を抑えてきた。 #frontkansai
2016-08-28 15:04:27
にわタコ
@niwatako
仮想DOMはDOMのあるべき姿を書いておくだけで、フレームワークが状態の変更前と変更後を比較して、差分だけを買い換えてくれる。何がレンダリングされるのか、プログラムを書いている人が見やすいのがメリット #frontkansai
2016-08-28 15:05:28
にわタコ
@niwatako
差分検知の仕組み 更新前の仮想DOMと変更後の仮想DOMを比較し、異なる場所だけ更新を行う 再帰的に子要素をたどっていって、上記のアルゴリズムを適用していく。 シンプル #frontkansai
2016-08-28 15:06:06
にわタコ
@niwatako
じゃあ何故速いのか ReactとMithrilのやり方はそんなに違わないのになぜMithrilが速いのか、再描画するタイミングを絞っている。 #frontkansai
2016-08-28 15:07:05
にわタコ
@niwatako
MithrilがDOMを再描画するタイミング m.module()かm.routeを使ってコントローラが初期化されたタイミング イベントハンドラが発生した時 m.requestが完了した時 m.redrawを呼んで明示的に再描画を読んだタイミング #frontkansai
2016-08-28 15:07:58