Lock in $30 Savings on PRO—Offer Ends Soon! ⏳
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
キッチハイク社内勉強会 / 2021-02-10
Search
Takuma Yamamoto
June 21, 2021
Programming
0
1.4k
キッチハイク社内勉強会 / 2021-02-10
Takuma Yamamoto
June 21, 2021
Tweet
Share
More Decks by Takuma Yamamoto
See All by Takuma Yamamoto
ドメイン駆動設計 勉強会 〜 リポジトリ編 〜 / 2024-04-23
tamago3keran
0
110
スナックミーの開発はワクワクだらけ! / 2024-04-05
tamago3keran
0
190
アウトプットのハードルを下げた! / 2024-03-25
tamago3keran
0
410
ドメイン駆動設計 勉強会 〜 ドメインサービス編 〜 / 2024-03-05
tamago3keran
0
110
ドメイン駆動設計 勉強会 〜 エンティティ編 〜 / 2024-02-20
tamago3keran
0
120
ドメイン駆動設計 勉強会 〜 値オブジェクト編 〜 / 2024-02-06
tamago3keran
1
1.9k
スカウト返信率を倍にするためにやったこと / 2024-01-29
tamago3keran
3
1.1k
Rails 経験者が FastAPI 本を読んで感じたこと / 2023-11-28
tamago3keran
0
1.9k
アウトプットのモチベーションはみんな違ってみんな良い! / 2023-10-06
tamago3keran
0
1.4k
Other Decks in Programming
See All in Programming
脳の「省エネモード」をデバッグする ~System 1(直感)と System 2(論理)の切り替え~
panda728
PRO
0
120
ELYZA_Findy AI Engineering Summit登壇資料_AIコーディング時代に「ちゃんと」やること_toB LLMプロダクト開発舞台裏_20251216
elyza
2
570
Navigation 3: 적응형 UI를 위한 앱 탐색
fornewid
1
440
生成AIを利用するだけでなく、投資できる組織へ
pospome
2
390
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
270
Rubyで鍛える仕組み化プロヂュース力
muryoimpl
0
160
Rediscover the Console - SymfonyCon Amsterdam 2025
chalasr
2
190
Kotlin Multiplatform Meetup - Compose Multiplatform 외부 의존성 아키텍처 설계부터 운영까지
wisemuji
0
110
認証・認可の基本を学ぼう前編
kouyuume
0
260
Patterns of Patterns
denyspoltorak
0
230
実は歴史的なアップデートだと思う AWS Interconnect - multicloud
maroon1st
0
250
堅牢なフロントエンドテスト基盤を構築するために行った取り組み
shogo4131
8
2.5k
Featured
See All Featured
First, design no harm
axbom
PRO
1
1.1k
Kristin Tynski - Automating Marketing Tasks With AI
techseoconnect
PRO
0
110
Conquering PDFs: document understanding beyond plain text
inesmontani
PRO
4
2.1k
Sharpening the Axe: The Primacy of Toolmaking
bcantrill
46
2.6k
Context Engineering - Making Every Token Count
addyosmani
9
540
How to train your dragon (web standard)
notwaldorf
97
6.4k
How to Grow Your eCommerce with AI & Automation
katarinadahlin
PRO
0
70
Un-Boring Meetings
codingconduct
0
160
Lessons Learnt from Crawling 1000+ Websites
charlesmeaden
0
940
The World Runs on Bad Software
bkeepers
PRO
72
12k
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
280
A Soul's Torment
seathinner
1
2k
Transcript
状態管理の歴史を振り返り Recoil の良さを知る 2021/2/10 キッチハイク 社内勉強会
Recoil の良さってなんでしょう? シンプルにかける 学習コストが低い カプセル化できる Hooks との相性が良い などなど
Redux と比べての良さが紹介されることが多い <
先行技術などのメリットを引き継いでいる部分もある 過去 現在 引き継ぐ 引き継ぐ
今日のゴール そのために、 • フロントエンドにおける状態管理の歴史を知ろう • 歴史的変遷の背景を知ろう Recoil の良さを実感を伴って理解することができる
アジェンダ 0限目:Reactの登場 1限目:Flux の登場 2限目:Redux の登場 3限目:Recoil の登場
0限目 React の登場
React という JavaScript ライブラリの登場 • 2013年3月 JSConfUS にて React が
OSS として公表される https://youtu.be/GW0rj4sNH2w
• 変更前後の仮想DOMを作成して、実DOMとの差分を検知する • 差分を実DOMに反映させて、再レンダリングする React が採用した「仮想DOM」という概念 引用元: https://calendar.perfplanet.com/2013/diff/
1限目 Flux の登場
Flux という新しいアーキテクチャの登場 • 2014年5月 Facebook F8 にて Flux というアーキテクチャが提唱される •
アプリケーション内のデータフローを単方向化する https://youtu.be/nYkdrAPrdcw
Facebook の Flux による課題解決ストーリー https://youtu.be/nYkdrAPrdcw • Facebook 自身も Flux によって課題を解決していた
• Facebook F8 にて、実体験と一緒に Flux が紹介された
チャット機能の変遷:ChatTab 機能の実装 • 最初は ChatTab という機能が実装された • メッセージを送信したら、ChatTab にそれを追加するというシンプルな実装 https://youtu.be/nYkdrAPrdcw
チャット機能の変遷:未読数カウント機能の実装 • メッセージが届いたことがわかるよう、未読数カウント機能が実装された • 注目はフォーカスされた ChatTab に届いた場合カウントアップしないこと https://youtu.be/nYkdrAPrdcw
チャット機能の変遷:メッセージビューの実装 • ChatTab 以外でメッセージを閲覧できるメッセージビューが実装された • 注目は表示中のスレッドに送信された場合のみメッセージが追加されること https://youtu.be/nYkdrAPrdcw
未読数カウントが合わないという不具合が何度も発生 • 未読数カウントが表示されているのに、確認しても届いていない不具合 • 修正しても、機能を追加するたびにデグレしてしまっていた 引用元: https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207
Viewがデータの更新にも影響を与えてしまうことが原因 • データ更新がViewに影響を与え、Viewがデータ更新に影響を与える • 双方向に行き来するデータフローに問題があると考えた • Facebook は「予測不可能」な状況になると表現している https://youtu.be/nYkdrAPrdcw
データフローを単方向化し「予測可能」な状態にする • Action → Dispatcher → Store → View というデータフロー
• どこでどんな処理が行われるか、処理の流れを把握できるようになった https://youtu.be/nYkdrAPrdcw
コードベースで Flux を見てみる https://github.com/eggheadio/egghead-react-flux-example
データフローを単方向化によるメリット • データフローの単方向化により、どこで何が行われるのか予測できる • これにより、デバッグしやすく、テストが書きやすくなった • 未読数カウントの不具合がデグレしにくくなった https://youtu.be/nYkdrAPrdcw
• jQuery とかで Flux 実装するとDOM操作が複数回発生 • 画面描画においてレンダリング処理が一番コストが高い • DOM操作を行う度にレンダリング処理が行われる •
DOM操作の回数を減らすことが大切(コードにも見受けられる) なぜ Flux での実装がされてこなかったのか? 参照:https://eh-career.com/engineerhub/entry/2020/02/18/103000
React の登場で UX を損わずに Flux で実装できる • 仮想DOMにより、DOM操作を最小限に抑えることができる • Reactの登場でUXを損わずにFluxで実装ができる
• UXを損なわずにデータを管理しやすくすることを実現 https://youtu.be/nYkdrAPrdcw
2限目 Redux の登場
React/Flux が全てを解決したのか? • Flux には、大きく分けて2つの課題があった • あるアクションに対するデータ更新処理が散在してしまう • データの依存関係がある場合、異なる場所で処理を待たないといけない 参考:https://www.code-experience.com/problems-with-flux/
Create Message Create Thread waitFor
Reducer という概念をもつ Redux が誕生 • Flux の課題を解決する Reducer という概念が生まれる •
Redux は Reducer という概念を持った状態管理ライブラリである • Flux と同様に単方向データフローである https://redux.js.org/
Redux 3原則:State is read-only • Action を受けとって State を変更することは Flux
と同じ • State は常に読み取り専用で、変更は Action を通じてのみ可能 https://redux.js.org/tutorials/essentials/part-2-app-structure
Redux 3原則:Single source of truth • Flux と違い Store がひとつになり、データ管理の場所が一箇所になった
• アプリケーション全体の State をひとつのオブジェクトツリーで表現 https://redux.js.org/understanding/thinking-in-redux/three-principles
Redux 3原則:Changes are made with pure functions • State の更新は
Action を受け取った Reducer で処理される • あるアクションに対する State の更新処理が一箇所にまとまった • State の更新処理の順番を指定しやすくなった https://redux.js.org/tutorials/essentials/part-2-app-structure
Redux によって解決された React の課題 • Store のデータを参照できるので、Props のバケツリレーがなくなる • それにより、不要な仮想
DOM 再レンダリングを抑えることができる 引用元:https://www.techscore.com/blog/2018/12/02/react-when-the-render-will-be-called/
3限目 Recoil の登場
• これまで状態管理ライブラリの主流は Redux だった • そういった状況の中、Redux 系とは異なる状態管理ライブラリが登場 • Hooks との相性の良さやシンプルにかけるという特徴がある
Recoil の登場 https://recoiljs.org/
• Hooks に似た書き方でグローバルに状態を共有できる • Redux と同様コンポーネント外(Atom)で管理しているデータを参照する Recoil は Atom で状態管理を行う
https://recoiljs.org/
• Flux と同様にデータフローは単方向である • Redux と同様に、あるイベントに対する更新処理を一箇所にまとめられる Flux や Redux のメリットを引き継いでいる
• Action や Reducer といった概念がなく、よりシンプルに書くことができる • ボイラープレートのコード量が少なく、シンプルにかける • 少ないコードで Redux
のような状態管理が実現できる Redux と比べた利点:少ないコードでシンプルにかける
• Redux 特有の制約などがないため、学習コストが低い • Hooks と似た書き方なので、学習コストが低い Redux と比べた利点:学習コストが低い
• カスタムフックとしてカプセル化できる • カプセル化することで、意図しないデータの変更を防ぐことができる • Redux だと Reducer からどの State
でも変更できてしまう Redux と比べた利点:より安全にデータ更新ができる
帰りの会 まとめ
Redux と比べて、 • 少ないコードでシンプルにかける • 学習コストが低い • より安全にデータ更新ができる Recoil の良さとはなんですか?
Flux と同様に、 • 単方向データフローで実装できる Redux と同様に、 • あるイベントに対して実行される処理を一箇所にまとめられる