Link
Embed
Share
Beginning
This slide
Copy link URL
Copy link URL
Copy iframe embed code
Copy iframe embed code
Copy javascript embed code
Copy javascript embed code
Share
Tweet
Share
Tweet
Slide 1
Slide 1 text
jQueryからElmまで Seiya Izumi
Slide 2
Slide 2 text
自己紹介 ❏ Fringe81 Web Engineer ❏ Scala, Golang を書いていましたが 現在は Elm を書いています ❏ Elm Europe 2019 に登壇予定（6月末）
Slide 3
Slide 3 text
このスライドの目的 自分なりのフロントエンドの学びを これまでの歩みと一緒に共有したい! ついでにElmを紹介したい!
Slide 4
Slide 4 text
僕とフロントエンド
Slide 5
Slide 5 text
僕とフロントエンド
Slide 6
Slide 6 text
僕とフロントエンド
Slide 7
Slide 7 text
僕とフロントエンド
Slide 8
Slide 8 text
僕とフロントエンド
Slide 9
Slide 9 text
僕とフロントエンド
Slide 10
Slide 10 text
初めて作ったウェブアプリケーションぽいもの
Slide 11
Slide 11 text
TabStockerの機能 ● ローカルで保存 ● 同期して保存 をそれぞれスイッチできる 並び替えができる
Slide 12
Slide 12 text
HTMLレンダリングを手で ● setAttributeとcreateElementを駆 使してDOM操作全て手書き ● タブスイッチもインラインスタイル の操作で実装
Slide 13
Slide 13 text
HTMLレンダリングを手で ● setAttributeとcreateElementを駆 使してDOM操作全て手書き ● タブスイッチもインラインスタイル の操作で実装 しんどい!!
Slide 14
Slide 14 text
DOM操作は人間には複雑すぎた ● 粘ってSPAのようなものを作ろうとするとすぐ地獄が始まる ● 自前でインクリメンタルサーチやインフィニット・ローディングを作るツラさ ● XSSなどのセキュリティ事故にも繋がる危険性あり
Slide 15
Slide 15 text
人間が手でDOMを書く時代は終わり
Slide 16
Slide 16 text
状態と画面の分離 ● アプリケーションのロジックによる結果を “状態” として画面とは分離して表現 ○ ロジックの影響範囲を限定することでテスタブルに ○ DOMのレンダリングがフレームワークによって行われるようになり安全 ○ 複雑な画面の構築も比較的ラクにできるためアプリケーションの大規模化へ
Slide 17
Slide 17 text
状態と画面の分離 { value: 10 }
Value is {{value}}
Scope HTML Value is 10 ロジックによる計算の結果は Scope（状態）のみに影響を与える
Slide 18
Slide 18 text
状態と画面の分離 { value: 10 }
Value is {{value}}
Scope HTML Value is 10 HTMLはどのように画面を作るかを表現するだけ（画面）
Slide 19
Slide 19 text
状態と画面の分離 { value: calc(2) }
Value is {{value}}
Scope HTML Value is 22 function calc(n) { return (n * 10 + 2) }
Slide 20
Slide 20 text
状態と画面の分離 { value: calc(2) }
Value is {{value}}
Scope HTML Value is 22 function calc(n) { return (n * 10 + 2) } Scopeの依存する ビジネスロジック のみをテストする だけで挙動が担保 できる
Slide 21
Slide 21 text
状態と画面の分離 { value: calc(2) }
Value is {{value}}
Scope HTML Value is 22 function calc(n) { return (n * 10 + 2) } Scopeの依存する ビジネスロジック のみをテストする だけで挙動が担保 できる 画面はビジネスロジックによる影響を受けない
Slide 22
Slide 22 text
大規模化するフロントエンドの苦しみ Component
Slide 23
Slide 23 text
大規模化するフロントエンドの苦しみ Component Component Component
Slide 24
Slide 24 text
大規模化するフロントエンドの苦しみ Component Component Component Component Component
Slide 25
Slide 25 text
大規模化するフロントエンドの苦しみ Component Component Component Component Component A Web API GET
Slide 26
Slide 26 text
大規模化するフロントエンドの苦しみ Component Component Component Component Component A 画面上はココで表示したい ↑
Slide 27
Slide 27 text
大規模化するフロントエンドの苦しみ Component Component Component Component Component A
Slide 28
Slide 28 text
大規模化するフロントエンドの苦しみ Component Component Component Component Component A 親コンポーネントからデータを受け取る口 を各コンポーネントが用意しておかないと いけない → Prop Drilling なんで俺がデータ 持たなアカンねん...
Slide 29
Slide 29 text
大規模化するフロントエンドの苦しみ Component Component Component Component Component Event Emitter
Slide 30
Slide 30 text
大規模化するフロントエンドの苦しみ Component Component Component Component Component Event Emitter A ↑画面上はココで表示したい
Slide 31
Slide 31 text
大規模化するフロントエンドの苦しみ Component Component Component Component Component Event Emitter Subscribe Emit A
Slide 32
Slide 32 text
大規模化するフロントエンドの苦しみ Component Component Component Component Component Event Emitter Subscribe Emit A
Slide 33
Slide 33 text
大規模化するフロントエンドの苦しみ Component Component Component Component Component Event Emitter Subscribe Emit Event Emitter Subscribe Emit
Slide 34
Slide 34 text
大規模化するフロントエンドの苦しみ Component Component Component Component Component Event Emitter Subscribe Emit Event Emitter Event Emitter Subscribe Emit Subscribe Subscribe Emit Subscribe データの交換のためだけにイベントシステムが 使われる → イベント・エミッタ地獄
Slide 35
Slide 35 text
フロントエンドの地獄とはなんだったのか ❖ “状態” と “画面” は分離されたものの、今度は状態の爆発がアプリケーショ ンの課題へ ❖ イベント発火が数珠つなぎになっていて、状態がどのように変化するかは、 動かしてみないと分からない
Slide 36
Slide 36 text
フロントエンドの地獄とはなんだったのか ❖ “状態” と “画面” は分離されたものの、今度は状態の爆発がアプリケーショ ンの課題へ ❖ イベント発火が数珠つなぎになっていて、状態がどのように変化するかは、 動かしてみないと分からない ➢ アプリケーションが予測不可能
Slide 37
Slide 37 text
Fluxアーキテクチャの発見
Slide 38
Slide 38 text
Fluxアーキテクチャの発見 Fluxのユニフローは関数として表現できる
Slide 39
Slide 39 text
関数と予測可能性 N + 10 + V 10 33 なんらかの外部要因 によって変化するV 依存
Slide 40
Slide 40 text
関数と予測可能性 10 33 なんらかの外部要因 によって変化するV 依存 ↑この依存が増えれば増えるほど、予測不可能性が増大する N + 10 + V
Slide 41
Slide 41 text
関数と予測可能性 N + 10 10 20 純粋関数は予測可能性が高い
Slide 42
Slide 42 text
関数型表現がフロントエンドにもたらすもの ❏ アプリケーションを純粋な関数で構成することによって 予測可能性（参照透過性）を高めることができる ❏ コンポーネントに想定外の依存を持たせないことで 意外性を少なくする
Slide 43
Slide 43 text
他フレームワークの趨勢 React ● Class コンポーネントよりも Functional コンポーネント推し ● コンポーネント・ライフサイクルなどの個別の状態表現APIを順次廃止 Vue.js ● 長らく期待されていたクラスAPIのプロポーザルを却下 ● React Hooks インスパイアな関数コンポジションによるコンポーネント定義にシフト
Slide 44
Slide 44 text
フロントエンドと関数型アプローチ
Slide 45
Slide 45 text
大まかなElmの特徴 ● 全ての変数がイミュータブル ● 状態更新、ビューなどをすべて関数として扱う ● アプリケーションのアーキテクチャが 決まっている（TEA） ● Reduxの設計に影響を与えた
Slide 46
Slide 46 text
JSにおける “ミュータブル” な状態表現の例 var status = { value: 10 }; status.value += 5; status.value++; console.log(status.value) // 16
Slide 47
Slide 47 text
イミュータブルな状態更新 SET_VALUE: 5 PLUS_VALUE: 3 PLUS_VALUE: 3 MINUS_VALUE: 2 イベント 状態 5 + 3 + 3 - 2 = 9 最新の状態というのは変更（イベント）の積 み上げから計算（畳み込み）されたものにな る { value: 9 }
Slide 48
Slide 48 text
イミュータブルな状態更新 SET_VALUE: 5 PLUS_VALUE: 3 PLUS_VALUE: 3 MINUS_VALUE: 2 イベント 状態 最新の状態というのは変更（イベント）の積 み上げから計算（畳み込み）されたものにな る { value: 9 }
Value is 9
ビューもまた状態から HTMLをつくる関 数として表現できる
Slide 49
Slide 49 text
TEA (The Elm Architecture) View Model Update レンダリング メッセージ 更新 アプリケーションの状態は 常にModelが表す ModelからHTML を計算する アプリケーションの 次の状態を計算する
Slide 50
Slide 50 text
TEA (The Elm Architecture) View Model Update レンダリング メッセージ 更新 ● イミュータビリティと関数型表現を前提としたアプリケーション・ アーキテクチャ ● 大規模なアプリケーションを作る上での意外性を排除することで、 データ構造やビジネスロジックの設計に注力できる
Slide 51
Slide 51 text
フロントエンドは関数 SET_VALUE: 5 Web API ユーザーの操 作 etc... HTML PLUS_VALUE: 3 PLUS_VALUE: 3 MINUS_VALUE: 2
Slide 52
Slide 52 text
まとめ: 僕から見たフロントエンドの進化
Slide 53
Slide 53 text
まとめ: 僕から見たフロントエンドの進化 アーキテクチャ上のルールと 制約の進化
Slide 54
Slide 54 text
まとめ: 僕から見たフロントエンドの進化 ● フロントエンド・アプリケーションの大規模化 ● Fluxアーキテクチャや関数型アプローチなどの、見方を変えればアプリケーションを 安全に作るための「レール」のようなものが登場 ● 自由とスケーラビリティは二律背反（何を捨てて、何に大事にするか）
Slide 55
Slide 55 text
あなたにとってのフロントエンドの進化はどんなものでしたか？ ぜひ、懇親会で教えて下さい
Slide 56
Slide 56 text
以上！