深層フロントエンド

第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」になる

 

 


https://ja.reactjs.org/docs/jsx-in-depth.html

§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フレームワーク

つづく

Made with Slides.com