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
関数型プログラミングとフロントエンド
Search
ponday
September 12, 2018
Programming
1.1k
1
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
関数型プログラミングとフロントエンド
俺の話を聞け!!LT大会 #11(2018/09/12)の発表資料です。
タイトル詐欺感が漂います。
ponday
September 12, 2018
More Decks by ponday
See All by ponday
関数型でGoFのデザインパターンやってみる
honda
1
1.7k
TypeScriptの型表現
honda
10
3.1k
Web Componentsの今
honda
1
480
これまでのReact、これからのReact
honda
0
340
Gatsbyお試し
honda
0
140
styled-components or emotion?
honda
0
730
Web ComponentsとAngular
honda
0
160
Atomic Design周りについての私見
honda
1
800
え、まだWeb Componentsを未来の技術だと思ってるの?
honda
2
890
Other Decks in Programming
See All in Programming
php-fpmのプロセスが枯渇した日-調査・対処・そして本当にやるべきだったこと-
shibuchaaaan
0
150
型も通る、synthも通る、それでも危ない 〜AIのCDKの権限とコストを機械で検証する〜 / It Passes Type Checks, It Passes Synth Checks, but It’s Still Risky — Automatically Verifying Permissions and Costs in AI’s CDK —
seike460
PRO
1
440
ルールを書いて終わらせないハーネスエンジニアリング
yug1224
4
1.8k
吝嗇家のためのAI活用 / AI development for miser - ChatGPT + Issue Driven Development
tooppoo
0
200
AIキャラアプリkaiwaの低遅延音声通話基盤をどう作ったか - AWS Gravitonで支える低遅延・低コストAI Agent基盤
mogamit
0
190
【やさしく解説 設計編 #1】「ドメイン駆動」と「実装駆動」ってなに? 〜設計の考え方を、たとえ話で学ぼう〜
panda728
PRO
1
140
全PRの83%がAIレビューだけでマージできるようになった開発組織はその後どうなったか
athug
0
470
Apache Hive: Toward a Cloud Native Lakehouse
okumin
0
160
SREの積み重ねがAI駆動開発のガードレールになった ― 7つの実践/SRE Guardrails The 7
tomoyakitaura
8
5.5k
Haskell/Servantを通してWebミドルウェアを捉え直す
pizzacat83
1
610
そこに3びきプロダクトがいるじゃろう——生成AI時代における“価値が届かない理由”の構造
kosuket
0
180
為什麼你並不需要ViewModel / No, you don't need a ViewModel
lovee
1
400
Featured
See All Featured
Tell your own story through comics
letsgokoyo
1
1k
What Being in a Rock Band Can Teach Us About Real World SEO
427marketing
0
1.1k
HDC tutorial
michielstock
2
750
Building Better People: How to give real-time feedback that sticks.
wjessup
370
20k
Performance Is Good for Brains [We Love Speed 2024]
tammyeverts
12
1.7k
Leading Effective Engineering Teams in the AI Era
addyosmani
9
2.2k
Connecting the Dots Between Site Speed, User Experience & Your Business [WebExpo 2025]
tammyeverts
11
980
Designing Powerful Visuals for Engaging Learning
tmiket
1
460
Building a A Zero-Code AI SEO Workflow
portentint
PRO
0
640
What’s in a name? Adding method to the madness
productmarketing
PRO
24
4.1k
Java REST API Framework Comparison - PWX 2021
mraible
34
9.6k
Introduction to Domain-Driven Design and Collaborative software design
baasie
1
910
Transcript
関数型プログラミングとフロントエンド 俺の話を聞け!!LT大会 #11 / Sep 12th, 2018 ponday (@ponday_dev)
Profile - ponday (Honda, Yusuke) - 株式会社ベガコーポレーション エンジニア - Like
: TypeScript / Elixir / Python etc… - フロントエンドの人ではない
最近のフロントエンド - 関数型に影響を受けた(らしい)ライブラリの増加 - React - Redux - Immutable.js -
RxJS - 結局のところ関数型プログラミングって何?
関数型プログラミング? ※ wikiから
何をもって関数型プログラミングとするか、 正確な定義や合意は存在しない
はずなのに
圏論 参照透過性 正格評価 モナド 不変性 副作用 ? ? ? 純粋関数
うわああああ▂▅▇█▓▒░(’ω’)░▒▓█▇▅▂ああああああ
関数型の雰囲気を掴むのに必要なもの
圏論 参照透過性 正格評価 不変性 副作用 ! モナド 純粋関数
関数 - 「引数を取って、計算して、戻り値を返す」もの - プログラミングでは、それ以外の動作をする場合も - コンポーネントの内部状態を変更する - Viewを書き換える -
etc....
副作用 - 関数の戻り値を返す以外の動作全て - 破壊的な操作 = 副作用 - Object.assign -
Array.prototype.push - 極端な話、画面を変化させるのも副作用
副作用 [ array.pushの動作 ] - 要素追加後の配列長を返す - 配列に要素を追加する
副作用 [ array.pushの動作 ] - 要素追加後の配列長を返す - 配列に要素を追加する 副作用!
不変性 - 値が書き換わらない性質。イミュータブルとも - JSのconstは再代入不可能性 ≠ イミュータブル - 値型ならこれだけでも充分 -
参照型の変数だとふいに書き換えられる可能性が
不変性
不変性 - Object.assignはshallow copy - barとobj.barは共有されている - 他の関数で書き換えられてしまう可能性が
不変性
純粋関数 - 副作用がない - 戻り値が引数によってのみ変化する - 何回実行しても、引数が同じなら結果は同じ - ユニットテストが楽に書ける
純粋でない関数 関数 引数 戻り値 外部変数 外部
純粋な関数 関数 引数 戻り値
フロントエンドの例 - ステートレスなコンポーネント - 関数コンポーネント(React) - functionalオプション(Vue) - Flux -
複数の関数の組み合わせ - State -> View、Action -> State
関数コンポーネント(React) 関数 prop View
classコンポーネント(React/純粋でない関数) 関数 引数 戻り値 外部変数
Flux Component State View Dispatcher Action
実際、副作用なしでフロントエンドって作れるの?
無理
副作用とフロントエンド - そもそも、View層が副作用そのもの - 副作用を排除するのは不可能 - 副作用の有無を見分けて、分離する設計 - 副作用がない処理はテストがしやすい -
バグの原因となり得る箇所を小さくできる
まとめ - フロントエンドでも関数型は適用できる - なんとなく使うならそんなに難しくない - それぞれの考え方を理解した設計が必要 - 副作用の排除は不可能という前提 -
純粋な関数として切り分けれる部分はないか - 副作用の有無でレイヤーを分ける