Nobukazu Hanada
あるところでは、「サンタさん」というあだ名で呼ばれる事が在ります。 花田 (はなだ） 恒一（のぶかず）と申します。 恒一（こういち）とは読みません。 Lispが好きです。
仮想DOMと宣言性、Reactivityについて
VanillaJSでGUIを作る人間から見たSvelteの良さ
— はなだ のぶかず
大まかに話すこと
- はなだ のぶかず
- Lisp/Rust/Scala/Haskellが大好きです。
- Visual Programming Languageをつくるのが仕事だったり趣味です
- ダンスとボードゲーム
- @nobkz
自己紹介
VanillaJSとGUI
とりあえず、Svelteの話をする前に簡単に
- http://vanilla-js.com/
- ただ「ライブラリやフレームワーク」を使わないJSのことではない。
- それらをまず前提としない考え方。
- DOM APIなどをちゃんと勉強しましょうよ
- 根本的に作りたいUIの正しい設計について考えましょうよ
- フレームワークをWebアプリをつくるための設計思想や実装技術を"プラグイン"として考える
VanillaJSとは?
- 定番の難しいことや、面倒なことをやってくれる
- フレームワークを使うことで、ある程度、設計の認識の共有ができる
- 一定の品質担保
ライブラリやフレームワークの利点
- UIに関するフレームワークは基本的には、未だに抽象化されていない。
- 設計の多様性
- UIの多様性
- ○○フレームワークをつかえばどんなUIでも可能になるわけではない。
- ○○フレームワークで可能な範囲のUIに制限されている。
- もし、範囲を越えたUIをつくるとしたら、その設計に合わない実装になり、苦しみを抱える。
フレームワークがUIを制限する
- Visual Programming Languageは基本的には、GUIの範疇を越えることが多い。
- ゲーム。これはそもそもゲームエンジンを利用するだろう
- ワードや、Google Mapみたいな、ビジュアルなツール
- 基本的には、Viewに強い独自ロジックが必要な場合、GUIフレームワークは適さない
- ジェスチャーなど独自で状態管理をしないといけない場合など。
抽象化されてないUI
- Viewに状態やデータやロジックを持たせることが悪だと言われやすい
- 確かにビューに状態を持たせると、更新処理が複雑化したりする場合が多い
- 実はDirect Manipulationの観点から考えると必ずしもそうではない。
- 必要なのは、上手な状態管理である。ビューも状態を持つ方が良い場合もある。
Viewが状態を持つということ
- DOMはグローバル
- どこからでもアクセスできて変更できる
- 構造が貧弱なフォームに合わせてデータ保持する必要がある
- JSオブジェクトとの変換が必要になる
DOM(≠View)で状態を持つと辛くなる理由
- Vanillaとして考える（フレームワークを使わない意味ではない。）
- コードやチームなどの寿命を考える
- まずはキチンと設計する
- フレームワークのコードを断片的にも読むべき
- フレームワークもメンテする
- 全部捨ててスクラッチで作り直してもいいやと思えるぐらい
結局フレームワークはどう向き合うべきか？
- レイヤーアーキテクチャ
- Observer or Polling
- 疎結合
- コンポーネント
- 汎化
- 境界
- 共通化
- 状態管理
GUIに必要なもの
- 抽象化
- カプセル化、情報隠蔽
- モジュール化
- 関心の分離
- 結合度と凝集度
- 参照の一点性
- 分割統治
GUIに必要なもの-ソフトウェア設計
- MVC：モデル-ビューコントローラで分離する設計
- Model : GUIアプリケーションの中核機能や中核データ
- View: 情報をユーザに表示
- Controller : ユーザ入力
GUIの設計 - MVCなど
勘違いされやすいMVなんとか
Original MVC
MVVM
Web MVC (MVC2)
Client MVC (Flux)
Original MVCもいろいろ
- 素朴なMVC
- 依存MVC
- プラガブルMVC
とりあえず依存性のMVC
View
Controller
Model
入力
操作
通知
表示
参照
よくあるダメなパターン
- 表示しかない
- リストが何個あるか？
- リストをどうやって削除するか？
なぜダメなのか。
モデルと通知
- モデルとビューに分けられている
- 分けることによって、追加や削除が実装しやすい
- ビューは表示に集中できる。
- すごく簡単な実装なので、実際はもっとちゃんとやる
モデルとビューの分離
No 仮想DOMについて
No仮想DOMについて整理するね。
そもそも仮想DOMとは？
Virtual DOM
update
Real DOM
最初の疑問
最初からこう書けばよくね？
- 仮想DOMで目指したかったのはまずは宣言性である
- UIの更新を直接書くのは手続き的になりがち（実のところ宣言的に書けないわけではない。）
- データを入力として、仮想DOMを出力するという関数を定義することで宣言性を作り上げている。(render関数）
仮想DOMの宣言性
つまりこういうこと
Model
通知
Model
仮想Dom
仮想Dom
ここが状態を持たない関数になればいい!!!
=宣言的!!!
仮想Domの差分比較
実DOMの操作
もしリアルDOMだったら?
Model
通知
Model
仮想Dom
いやいや、Dom API呼びすぎて、
遅いでしょ?
実Dom
- たしかに、そうやって宣言的に書きたいなら、そうかもだけど
- でも、仮想Domの差分比較更新の分だけ、更新処理を地道に書いた方が速いよなー
- また、Virtual DomやReactComponentのレイヤーのおかげでランタイムが大きくなる
- あと、そもそもReactのやってる更新っての、枝刈りだしなー。
Vanilla JSerの気分
こっちの方がいいね!
Model
通知
View
通知メッセージに合わせて適切に更新!
差分検知の分だけ、更新するのだるい。
なんだったら、自分で枝刈りしてるし..
Viewオブジェクトを生成して、
- とても宣言的に書ける
- 無駄なViewの更新処理を書かなくていい
- 更新処理はコンパイラが書いてくれる
SvelteはNo 仮想Dom
コード例
とても宣言的
<form on:submit|preventDefault={submit}>
<input bind:value={text}>
</form>
<ul>
{#each post as aPost}
<li on:click={e=>{ deletePost(aPost) }}>{aPost}</li>
{/each}
</ul> 更新処理について
for (i = 0; i < each_value.length; i += 1) {
const child_ctx = get_each_context(ctx, each_value, i);
if (each_blocks[i]) {
each_blocks[i].p(child_ctx, dirty); // リストの更新
} else {
each_blocks[i] = create_each_block(child_ctx);
each_blocks[i].c(); // リストの追加
each_blocks[i].m(ul, null); // リストのマウント
}
}
for (; i < each_blocks.length; i += 1) {
each_blocks[i].d(1); // リストの削除
}書いてくれる!
- SvelteコンパイラがVanillaJSにおける、Viewの更新を書いてくれる。
- 掃き出したコードを見ても、悪くない
- 若干VanillaJSで書くより、無駄な処理があるけど
- 宣言的に書きやすい
Vanilla JSから見たSvelte
- Reactiveの話は、Alan KayのReactive Engineから始まる
- 式の構文木を持ち、入力が変化すると、式が再評価されるモデル
- Functional Reactive ProgrammingはこのReactive Engineに対して、明示な連続時間変化の型を中心において、強い保証
- SvelteのReactivityは、ちょっと異なっているような...(時間がない)
Reactivityについて
- Reactを初めとするVirtual Domは宣言的に書けるける一方、でも遅い
- Svelteも宣言的に書いてコンパイルしてくれる。
- Vanilla JSerから見たらSvelteはとても、Vanilla JSの人達が書きたいViewの処理を出力している。
- Reactivityについてはまたこんど
まとめ
仮想DOMと宣言性、Reactivityについて
By Nobukazu Hanada
仮想DOMと宣言性、Reactivityについて
- 111
