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
キッチハイク社内勉強会 / 2021-02-10
Search
Takuma Yamamoto
June 21, 2021
Programming
0
1.3k
キッチハイク社内勉強会 / 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
68
スナックミーの開発はワクワクだらけ! / 2024-04-05
tamago3keran
0
150
アウトプットのハードルを下げた! / 2024-03-25
tamago3keran
0
370
ドメイン駆動設計 勉強会 〜 ドメインサービス編 〜 / 2024-03-05
tamago3keran
0
79
ドメイン駆動設計 勉強会 〜 エンティティ編 〜 / 2024-02-20
tamago3keran
0
86
ドメイン駆動設計 勉強会 〜 値オブジェクト編 〜 / 2024-02-06
tamago3keran
1
1.5k
スカウト返信率を倍にするためにやったこと / 2024-01-29
tamago3keran
2
980
Rails 経験者が FastAPI 本を読んで感じたこと / 2023-11-28
tamago3keran
0
1.4k
アウトプットのモチベーションはみんな違ってみんな良い! / 2023-10-06
tamago3keran
0
1.2k
Other Decks in Programming
See All in Programming
バグを見つけた?それAppleに直してもらおう!
uetyo
0
210
PHPとAPI Platformで作る本格的なWeb APIアプリケーション(入門編) / phpcon 2024 Intro to API Platform
ttskch
0
370
PSR-15 はあなたのための ものではない? - phpcon2024
myamagishi
0
380
生成AIでGitHubソースコード取得して仕様書を作成
shukob
0
610
なまけものオバケたち -PHP 8.4 に入った新機能の紹介-
tanakahisateru
1
140
Monixと常駐プログラムの勘どころ / Scalaわいわい勉強会 #4
stoneream
0
330
create_tableをしただけなのに〜囚われのuuid編〜
daisukeshinoku
0
340
見えないメモリを観測する: PHP 8.4 `pg_result_memory_size()` とSQL結果のメモリ管理
kentaroutakeda
0
910
数十万行のプロジェクトを Scala 2から3に完全移行した
xuwei_k
0
1.1k
CQRS+ES の力を使って効果を感じる / Feel the effects of using the power of CQRS+ES
seike460
PRO
0
230
テストケースの名前はどうつけるべきか?
orgachem
PRO
1
260
Kaigi on Railsに初参加したら、その日にLT登壇が決定した件について
tama50505
0
140
Featured
See All Featured
jQuery: Nuts, Bolts and Bling
dougneiner
62
7.6k
Become a Pro
speakerdeck
PRO
26
5.1k
Building Adaptive Systems
keathley
38
2.3k
RailsConf 2023
tenderlove
29
960
Code Review Best Practice
trishagee
65
17k
ピンチをチャンスに:未来をつくるプロダクトロードマップ #pmconf2020
aki_iinuma
113
50k
How to Create Impact in a Changing Tech Landscape [PerfNow 2023]
tammyeverts
49
2.2k
YesSQL, Process and Tooling at Scale
rocio
170
14k
Fontdeck: Realign not Redesign
paulrobertlloyd
82
5.3k
Intergalactic Javascript Robots from Outer Space
tanoku
270
27k
Rails Girls Zürich Keynote
gr2m
94
13k
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
28
9.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 と同様に、 • あるイベントに対して実行される処理を一箇所にまとめられる