深層フロントエンド
第3層::SPAフレームワーク
Webフロントエンドの今
DOM
§1 DOM
DOMって何
Document Object Model
HTMLを木構造で表したデータ
＝ JSのオブジェクト
HTMLを動的に変化させるためのインターフェース
動的に ＝ ページの表示後に
§1 DOM
document
document or window.document ＝ 木構造の本体
§1 DOM
const element = document.querySelector('.foo')
if (element.classList.contains('bar')) {
element.classList.remove('bar')
} else {
element.classList.add('bar')
}木構造
Node, NodeList, Element, HTMLElement, ...からなる木構造
§1 DOM
html
head
body
ul
li
li
h1
p
title
meta
DOMいつ使うの
動的なHTML書き換え == DOMツリーの書き換え
リッチなUIのためにはDOMを触らなければならない
ブラウザ毎に仕様の細かい部分が異なる（特にIE）ので
普通はjQueryで代替する
jQueryすら使わないときはDOMのAPIを直で使う
§1 DOM
jQuery
§2 jQuery
jQueryって何
ブラウザ毎の仕様差を吸収したDOM操作ライブラリ
独自の「jQueryオブジェクト」の木構造でDOMをラップ
DOM操作、アニメーション等を、1つのコードでクロスブラウザ対応できる。
Google Maps で話題になったAjaxも。
「リッチなUI？とりあえずjQuery使っとけばおｋ」
§2 jQuery
jQueryつらくね？
デファクトスタンダードと呼ばれるまでに普及
JS（jQuery）をふんだんに使ったWebアプリケーションが流行
Webアプリケーションの巨大化
→ あれ？jQueryつらくね？
§2 jQuery
状態管理がつらい
HTMLの構造（＝状態）は殆ど無限パターンある
条件分岐やnullチェックを大量に行い、
例外処理を徹底しなければならない
いちいちそんなコードを書いてるとコスパが悪い
規模が大きくなるほど他人のコードが読めなくなる
＝書いた人にしか分からないコードが生まれる
§2 jQuery
密結合がつらい
jQueryはDOM全体にアクセス可能。
「上手い」人が疎結合に実装しても、抜け道はたくさん残る
「とりあえず動けばいい」思想の人が手を付けるとすぐに壊れる
（余談：CSSにおいても大体同じことが言えます）
§2 jQuery
jQueryの規模ではなくなった
jQueryはあくまでライブラリであってフレームワークではない
スケーラブルなアプリケーションを作るのための仕組みが無い
デザインやHTML/CSSコーディングの延長の気持ちで巨大なJSを書くと、すぐに苦しくなる
「Webアプリケーション」はjQueryだけで統治できる規模ではなくなった
§2 jQuery
SPAフレームワーク
§3 SPAフレームワーク
SPAフレームワークのおこり
jQueryでは耐えきれなくなったWebフロントエンド界に
GUIアプリケーションとなるためのフレームワークが誕生。
！！！Webフロントエンドのパラダイムシフト！！！
Vue Angular React ...
「MVVM」と「Flux」というアーキテクチャが主流
※アーキテクチャ … 設計。構造。
§3 SPAフレームワーク
MVVMアーキテクチャ
Model View ViewModel → MVVM
View ＝ UIを描画する部分。
ViewModel ＝ ViewとModelの仲介。抽象化やデータ変換等
Model ＝ ビジネスロジック。
「このアーキテクチャに則って開発しましょう」
§3 SPAフレームワーク
MVVMとWeb
MVVMをWebに実際に当てはめてみると
Backend ↔ Model ↔ ViewModel ↔ View ↔ User
View ＝ DOM
ViewModel ＝ VDOM（VirtualDOM, 仮想DOM）
Model ＝ 我々が書くJS
§3 SPAフレームワーク
フレームワークがもたらすもの
jQuery時代から変わったこと
→ VDOMがDOMをレンダリングする
→ 双方向バインディング
→ コンポーネント指向
§3 SPAフレームワーク
レンダリング
§4 レンダリング
すべてがJSになる
SPAフレームワークでは全てがJavaScriptの上に乗っかる。
サーバに配置するのは「index.html」と「index.js」だけ。
§4 レンダリング
<body>
<div id="app"></div>
<script src="index.js"></script>
</body>あとはJSが、DOMを通じてHTML（とCSS）を
「レンダリング」する。
でも今HTML書いてるよ？
Vueの「.vue」、Reactの「.jsx」、Angularでは「.html」で
普通にHTML（のようなもの）を書く。
→ 「ビルド」時に「そういうHTMLを生成するJS」になる
§4 レンダリング
<MyButton color="blue" shadowSize={2}>
Click Me
</MyButton>React.createElement(
MyButton,
{color: 'blue', shadowSize: 2},
'Click Me'
)jQuery以前のJS
DOMの状態に応じて、DOMの状態を変化させる
DOMが基準で → JSが動き → DOMへ出力
コーディング時の気持ち：
巨大なDOMを大胆かつ緻密に組み替えるJS処理を書く
§4 レンダリング
SPAフレームワークのやりかた
JSの状態に応じて、VDOMがDOMを生成（レンダリング）する
JSが基準で → VDOMが動き → DOMを出力
コーディング時の気持ち：
小さなObjectを書き換えるJS処理を書く
+ Objectに応じて変化するDOMを書く
§4 レンダリング
双方向バインディング
§5 双方向バインディング
双方向バインディング
val = 'fuga' → テキストボックス「fuga」
テキストボックス「piyo」→ val == 'piyo'
§5 双方向バインディング
data() {
return {
val: 'hoge',
}
}<input type="text" v-model="val">
コンポーネント指向
§6 コンポーネント指向
コンポーネント
「コンポーネント」と呼ばれる小さな部品をいくつも作り、
コンポーネントの集合体が1つのアプリケーションとなる。
コンポーネントを組み合わせて新たなコンポーネントを作れる
テキスト入力欄 ＋ 送信ボタン ＝ テキスト送信フォーム
§6 コンポーネント指向
カスタムタグ
テキスト入力欄 ＋ 送信ボタン ＝ テキスト送信フォーム
§6 コンポーネント指向
<form>
<input type="text">
<button type="submit">送信</button>
</form><SubmitTextForm />ページレイアウト
ヘッダー ＋ サイドメニュー ＋ 記事 ＋ フッター
§6 コンポーネント指向
<div>
<GlobalHeader />
<SideMenu />
<ArticleContent />
<GlobalFooter />
</div><ArticlePage />なぜコンポーネント化するのか
重要なのは「カプセル化」と「疎結合」
これによってソースコードの見通しを良くする
＝ 気持ちよく開発・保守できるようにする
＝ 他人のコードを読んで理解できるようにする
＝ スケーラブル（追加・変更・削除が容易）になる
§6 コンポーネント指向
カプセル化
そのコンポーネントだけが必要とするデータは、
コンポーネント内部に隠蔽する。
外部との連携が必要なもののみ外部に公開する。
→「データの依存」が明確化される
§6 コンポーネント指向
Username
2 hours ago
隠蔽： 形状・配置・現在時刻
公開： 画像URL・名前・比較時刻
疎結合
コンポーネントが機能するために他のモジュールへの依存が少ない状態
→ そのコンポーネントを簡単に消せる状態
被依存が少ない
→ 他のコンポーネントとの入れ替えが容易な状態
インターフェースが単純である
§6 コンポーネント指向
深層フロントエンド
第3層::SPAフレームワーク
つづく
深層フロントエンド 第3層 SPAフレームワーク
By Shigeki Suwa
