Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
jQueryからElmまで
Search
Seiya IZUMI
June 01, 2019
Programming
1
1.5k
jQueryからElmまで
Seiya IZUMI
June 01, 2019
Tweet
Share
More Decks by Seiya IZUMI
See All by Seiya IZUMI
Elm, the functional frontend
izumisy
3
1k
Elmの歩き方2019
izumisy
5
3.3k
Our Journey with the Biggest Elm App in Japan
izumisy
0
140
Ordering and Ordered
izumisy
1
71
僕が新卒として意識している4つのこと
izumisy
0
100
Choo: Fun Functional Framework
izumisy
1
450
StackoverflowでREPを稼ぐ技術
izumisy
1
770
フロントエンド・バリデーション
izumisy
5
3.5k
ROM.rb: Another Approach to Persistence
izumisy
1
830
Other Decks in Programming
See All in Programming
Identifying User Idenity
moro
6
7.9k
Streams APIとTCPフロー制御 / Web Streams API and TCP flow control
tasshi
1
290
とにかくAWS GameDay!AWSは世界の共通言語! / Anyway, AWS GameDay! AWS is the world's lingua franca!
seike460
PRO
1
550
Modern Angular: Renovation for Your Applications
manfredsteyer
PRO
0
210
推し活としてのrails new/oshikatsu_ha_iizo
sakahukamaki
3
1.7k
Honoの来た道とこれから
yusukebe
19
3k
Kaigi on Rails 2024 - Rails APIモードのためのシンプルで効果的なCSRF対策 / kaigionrails-2024-csrf
corocn
5
3.4k
AWS IaCの注目アップデート 2024年10月版
konokenj
3
3.1k
カスタムしながら理解するGraphQL Connection
yanagii
1
1.2k
VR HMDとしてのVision Pro+ゲーム開発について
yasei_no_otoko
0
100
LLM生成文章の精度評価自動化とプロンプトチューニングの効率化について
layerx
PRO
2
140
Googleのテストサイズを活用したテスト環境の構築
toms74209200
0
270
Featured
See All Featured
Easily Structure & Communicate Ideas using Wireframe
afnizarnur
191
16k
Save Time (by Creating Custom Rails Generators)
garrettdimon
PRO
27
790
Designing on Purpose - Digital PM Summit 2013
jponch
115
6.9k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
3
370
The Cult of Friendly URLs
andyhume
78
6k
Rebuilding a faster, lazier Slack
samanthasiow
79
8.6k
Docker and Python
trallard
40
3.1k
Thoughts on Productivity
jonyablonski
67
4.3k
BBQ
matthewcrist
85
9.3k
The MySQL Ecosystem @ GitHub 2015
samlambert
250
12k
The Success of Rails: Ensuring Growth for the Next 100 Years
eileencodes
43
6.6k
Fight the Zombie Pattern Library - RWD Summit 2016
marcelosomers
231
17k
Transcript
jQueryからElmまで Seiya Izumi
自己紹介 ❏ Fringe81 Web Engineer ❏ Scala, Golang を書いていましたが 現在は
Elm を書いています ❏ Elm Europe 2019 に登壇予定(6月末)
このスライドの目的 自分なりのフロントエンドの学びを これまでの歩みと一緒に共有したい! ついでにElmを紹介したい!
僕とフロントエンド
僕とフロントエンド
僕とフロントエンド
僕とフロントエンド
僕とフロントエンド
僕とフロントエンド
初めて作ったウェブアプリケーションぽいもの
TabStockerの機能 • ローカルで保存 • 同期して保存 をそれぞれスイッチできる 並び替えができる
HTMLレンダリングを手で • setAttributeとcreateElementを駆 使してDOM操作全て手書き • タブスイッチもインラインスタイル の操作で実装
HTMLレンダリングを手で • setAttributeとcreateElementを駆 使してDOM操作全て手書き • タブスイッチもインラインスタイル の操作で実装 しんどい!!
DOM操作は人間には複雑すぎた • 粘ってSPAのようなものを作ろうとするとすぐ地獄が始まる • 自前でインクリメンタルサーチやインフィニット・ローディングを作るツラさ • XSSなどのセキュリティ事故にも繋がる危険性あり
人間が手でDOMを書く時代は終わり
状態と画面の分離 • アプリケーションのロジックによる結果を “状態” として画面とは分離して表現 ◦ ロジックの影響範囲を限定することでテスタブルに ◦ DOMのレンダリングがフレームワークによって行われるようになり安全 ◦
複雑な画面の構築も比較的ラクにできるためアプリケーションの大規模化へ
状態と画面の分離 { value: 10 } <div class=”value-box”> <div>Value is {{value}}</div>
</div> Scope HTML Value is 10 ロジックによる計算の結果は Scope(状態)のみに影響を与える
状態と画面の分離 { value: 10 } <div class=”value-box”> <div>Value is {{value}}</div>
</div> Scope HTML Value is 10 HTMLはどのように画面を作るかを表現するだけ(画面)
状態と画面の分離 { value: calc(2) } <div class=”value-box”> <div>Value is {{value}}</div>
</div> Scope HTML Value is 22 function calc(n) { return (n * 10 + 2) }
状態と画面の分離 { value: calc(2) } <div class=”value-box”> <div>Value is {{value}}</div>
</div> Scope HTML Value is 22 function calc(n) { return (n * 10 + 2) } Scopeの依存する ビジネスロジック のみをテストする だけで挙動が担保 できる
状態と画面の分離 { value: calc(2) } <div class=”value-box”> <div>Value is {{value}}</div>
</div> Scope HTML Value is 22 function calc(n) { return (n * 10 + 2) } Scopeの依存する ビジネスロジック のみをテストする だけで挙動が担保 できる 画面はビジネスロジックによる影響を受けない
大規模化するフロントエンドの苦しみ Component
大規模化するフロントエンドの苦しみ Component Component Component
大規模化するフロントエンドの苦しみ Component Component Component Component Component
大規模化するフロントエンドの苦しみ Component Component Component Component Component A Web API GET
大規模化するフロントエンドの苦しみ Component Component Component Component Component A 画面上はココで表示したい ↑
大規模化するフロントエンドの苦しみ Component Component Component Component Component A
大規模化するフロントエンドの苦しみ Component Component Component Component Component A 親コンポーネントからデータを受け取る口 を各コンポーネントが用意しておかないと いけない
→ Prop Drilling なんで俺がデータ 持たなアカンねん...
大規模化するフロントエンドの苦しみ Component Component Component Component Component Event Emitter
大規模化するフロントエンドの苦しみ Component Component Component Component Component Event Emitter A ↑画面上はココで表示したい
大規模化するフロントエンドの苦しみ Component Component Component Component Component Event Emitter Subscribe Emit
A
大規模化するフロントエンドの苦しみ Component Component Component Component Component Event Emitter Subscribe Emit
A
大規模化するフロントエンドの苦しみ Component Component Component Component Component Event Emitter Subscribe Emit
Event Emitter Subscribe Emit
大規模化するフロントエンドの苦しみ Component Component Component Component Component Event Emitter Subscribe Emit
Event Emitter Event Emitter Subscribe Emit Subscribe Subscribe Emit Subscribe データの交換のためだけにイベントシステムが 使われる → イベント・エミッタ地獄
フロントエンドの地獄とはなんだったのか ❖ “状態” と “画面” は分離されたものの、今度は状態の爆発がアプリケーショ ンの課題へ ❖ イベント発火が数珠つなぎになっていて、状態がどのように変化するかは、 動かしてみないと分からない
フロントエンドの地獄とはなんだったのか ❖ “状態” と “画面” は分離されたものの、今度は状態の爆発がアプリケーショ ンの課題へ ❖ イベント発火が数珠つなぎになっていて、状態がどのように変化するかは、 動かしてみないと分からない
➢ アプリケーションが予測不可能
Fluxアーキテクチャの発見
Fluxアーキテクチャの発見 Fluxのユニフローは関数として表現できる
関数と予測可能性 N + 10 + V 10 33 なんらかの外部要因 によって変化するV
依存
関数と予測可能性 10 33 なんらかの外部要因 によって変化するV 依存 ↑この依存が増えれば増えるほど、予測不可能性が増大する N + 10
+ V
関数と予測可能性 N + 10 10 20 純粋関数は予測可能性が高い
関数型表現がフロントエンドにもたらすもの ❏ アプリケーションを純粋な関数で構成することによって 予測可能性(参照透過性)を高めることができる ❏ コンポーネントに想定外の依存を持たせないことで 意外性を少なくする
他フレームワークの趨勢 React • Class コンポーネントよりも Functional コンポーネント推し • コンポーネント・ライフサイクルなどの個別の状態表現APIを順次廃止 Vue.js
• 長らく期待されていたクラスAPIのプロポーザルを却下 • React Hooks インスパイアな関数コンポジションによるコンポーネント定義にシフト
フロントエンドと関数型アプローチ
大まかなElmの特徴 • 全ての変数がイミュータブル • 状態更新、ビューなどをすべて関数として扱う • アプリケーションのアーキテクチャが 決まっている(TEA) • Reduxの設計に影響を与えた
JSにおける “ミュータブル” な状態表現の例 var status = { value: 10 };
status.value += 5; status.value++; console.log(status.value) // 16
イミュータブルな状態更新 SET_VALUE: 5 PLUS_VALUE: 3 PLUS_VALUE: 3 MINUS_VALUE: 2 イベント
状態 5 + 3 + 3 - 2 = 9 最新の状態というのは変更(イベント)の積 み上げから計算(畳み込み)されたものにな る { value: 9 }
イミュータブルな状態更新 SET_VALUE: 5 PLUS_VALUE: 3 PLUS_VALUE: 3 MINUS_VALUE: 2 イベント
状態 最新の状態というのは変更(イベント)の積 み上げから計算(畳み込み)されたものにな る { value: 9 } <div> <div>Value is 9</div> </div> ビューもまた状態から HTMLをつくる関 数として表現できる
TEA (The Elm Architecture) View Model Update レンダリング メッセージ 更新
アプリケーションの状態は 常にModelが表す ModelからHTML を計算する アプリケーションの 次の状態を計算する
TEA (The Elm Architecture) View Model Update レンダリング メッセージ 更新
• イミュータビリティと関数型表現を前提としたアプリケーション・ アーキテクチャ • 大規模なアプリケーションを作る上での意外性を排除することで、 データ構造やビジネスロジックの設計に注力できる
フロントエンドは関数 SET_VALUE: 5 Web API ユーザーの操 作 etc... HTML PLUS_VALUE:
3 PLUS_VALUE: 3 MINUS_VALUE: 2
まとめ: 僕から見たフロントエンドの進化
まとめ: 僕から見たフロントエンドの進化 アーキテクチャ上のルールと 制約の進化
まとめ: 僕から見たフロントエンドの進化 • フロントエンド・アプリケーションの大規模化 • Fluxアーキテクチャや関数型アプローチなどの、見方を変えればアプリケーションを 安全に作るための「レール」のようなものが登場 • 自由とスケーラビリティは二律背反(何を捨てて、何に大事にするか)
あなたにとってのフロントエンドの進化はどんなものでしたか? ぜひ、懇親会で教えて下さい
以上!