Tweet
Tweet

Slide 1

Slide 1 text

状態管理の歴史を振り返り Recoil の良さを知る 2021/2/10 キッチハイク 社内勉強会

Slide 2

Slide 2 text

Recoil の良さってなんでしょう？ シンプルにかける 学習コストが低い カプセル化できる Hooks との相性が良い などなど

Slide 3

Slide 3 text

Redux と比べての良さが紹介されることが多い <

Slide 4

Slide 4 text

先行技術などのメリットを引き継いでいる部分もある 過去 現在 引き継ぐ 引き継ぐ

Slide 5

Slide 5 text

今日のゴール そのために、 ● フロントエンドにおける状態管理の歴史を知ろう ● 歴史的変遷の背景を知ろう Recoil の良さを実感を伴って理解することができる

Slide 6

Slide 6 text

アジェンダ 0限目：Reactの登場 1限目：Flux の登場 2限目：Redux の登場 3限目：Recoil の登場

Slide 7

Slide 7 text

0限目 React の登場

Slide 8

Slide 8 text

React という JavaScript ライブラリの登場 ● 2013年3月 JSConfUS にて React が OSS として公表される https://youtu.be/GW0rj4sNH2w

Slide 9

Slide 9 text

● 変更前後の仮想DOMを作成して、実DOMとの差分を検知する ● 差分を実DOMに反映させて、再レンダリングする React が採用した「仮想DOM」という概念 引用元: https://calendar.perfplanet.com/2013/diff/

Slide 10

Slide 10 text

1限目 Flux の登場

Slide 11

Slide 11 text

Flux という新しいアーキテクチャの登場 ● 2014年5月 Facebook F8 にて Flux というアーキテクチャが提唱される ● アプリケーション内のデータフローを単方向化する https://youtu.be/nYkdrAPrdcw

Slide 12

Slide 12 text

Facebook の Flux による課題解決ストーリー https://youtu.be/nYkdrAPrdcw ● Facebook 自身も Flux によって課題を解決していた ● Facebook F8 にて、実体験と一緒に Flux が紹介された

Slide 13

Slide 13 text

チャット機能の変遷：ChatTab 機能の実装 ● 最初は ChatTab という機能が実装された ● メッセージを送信したら、ChatTab にそれを追加するというシンプルな実装 https://youtu.be/nYkdrAPrdcw

Slide 14

Slide 14 text

チャット機能の変遷：未読数カウント機能の実装 ● メッセージが届いたことがわかるよう、未読数カウント機能が実装された ● 注目はフォーカスされた ChatTab に届いた場合カウントアップしないこと https://youtu.be/nYkdrAPrdcw

Slide 15

Slide 15 text

チャット機能の変遷：メッセージビューの実装 ● ChatTab 以外でメッセージを閲覧できるメッセージビューが実装された ● 注目は表示中のスレッドに送信された場合のみメッセージが追加されること https://youtu.be/nYkdrAPrdcw

Slide 16

Slide 16 text

未読数カウントが合わないという不具合が何度も発生 ● 未読数カウントが表示されているのに、確認しても届いていない不具合 ● 修正しても、機能を追加するたびにデグレしてしまっていた 引用元: https://code-cartoons.com/a-cartoon-guide-to-flux-6157355ab207

Slide 17

Slide 17 text

Viewがデータの更新にも影響を与えてしまうことが原因 ● データ更新がViewに影響を与え、Viewがデータ更新に影響を与える ● 双方向に行き来するデータフローに問題があると考えた ● Facebook は「予測不可能」な状況になると表現している https://youtu.be/nYkdrAPrdcw

Slide 18

Slide 18 text

データフローを単方向化し「予測可能」な状態にする ● Action → Dispatcher → Store → View というデータフロー ● どこでどんな処理が行われるか、処理の流れを把握できるようになった https://youtu.be/nYkdrAPrdcw

Slide 19

Slide 19 text

コードベースで Flux を見てみる https://github.com/eggheadio/egghead-react-flux-example

Slide 20

Slide 20 text

データフローを単方向化によるメリット ● データフローの単方向化により、どこで何が行われるのか予測できる ● これにより、デバッグしやすく、テストが書きやすくなった ● 未読数カウントの不具合がデグレしにくくなった https://youtu.be/nYkdrAPrdcw

Slide 21

Slide 21 text

● jQuery とかで Flux 実装するとDOM操作が複数回発生 ● 画面描画においてレンダリング処理が一番コストが高い ● DOM操作を行う度にレンダリング処理が行われる ● DOM操作の回数を減らすことが大切（コードにも見受けられる） なぜ Flux での実装がされてこなかったのか？ 参照：https://eh-career.com/engineerhub/entry/2020/02/18/103000

Slide 22

Slide 22 text

React の登場で UX を損わずに Flux で実装できる ● 仮想DOMにより、DOM操作を最小限に抑えることができる ● Reactの登場でUXを損わずにFluxで実装ができる ● UXを損なわずにデータを管理しやすくすることを実現 https://youtu.be/nYkdrAPrdcw

Slide 23

Slide 23 text

2限目 Redux の登場

Slide 24

Slide 24 text

React/Flux が全てを解決したのか？ ● Flux には、大きく分けて2つの課題があった ● あるアクションに対するデータ更新処理が散在してしまう ● データの依存関係がある場合、異なる場所で処理を待たないといけない 参考：https://www.code-experience.com/problems-with-flux/ Create Message Create Thread waitFor

Slide 25

Slide 25 text

Reducer という概念をもつ Redux が誕生 ● Flux の課題を解決する Reducer という概念が生まれる ● Redux は Reducer という概念を持った状態管理ライブラリである ● Flux と同様に単方向データフローである https://redux.js.org/

Slide 26

Slide 26 text

Redux 3原則：State is read-only ● Action を受けとって State を変更することは Flux と同じ ● State は常に読み取り専用で、変更は Action を通じてのみ可能 https://redux.js.org/tutorials/essentials/part-2-app-structure

Slide 27

Slide 27 text

Redux 3原則：Single source of truth ● Flux と違い Store がひとつになり、データ管理の場所が一箇所になった ● アプリケーション全体の State をひとつのオブジェクトツリーで表現 https://redux.js.org/understanding/thinking-in-redux/three-principles

Slide 28

Slide 28 text

Redux 3原則：Changes are made with pure functions ● State の更新は Action を受け取った Reducer で処理される ● あるアクションに対する State の更新処理が一箇所にまとまった ● State の更新処理の順番を指定しやすくなった https://redux.js.org/tutorials/essentials/part-2-app-structure

Slide 29

Slide 29 text

Redux によって解決された React の課題 ● Store のデータを参照できるので、Props のバケツリレーがなくなる ● それにより、不要な仮想 DOM 再レンダリングを抑えることができる 引用元：https://www.techscore.com/blog/2018/12/02/react-when-the-render-will-be-called/

Slide 30

Slide 30 text

3限目 Recoil の登場

Slide 31

Slide 31 text

● これまで状態管理ライブラリの主流は Redux だった ● そういった状況の中、Redux 系とは異なる状態管理ライブラリが登場 ● Hooks との相性の良さやシンプルにかけるという特徴がある Recoil の登場 https://recoiljs.org/

Slide 32

Slide 32 text

● Hooks に似た書き方でグローバルに状態を共有できる ● Redux と同様コンポーネント外（Atom）で管理しているデータを参照する Recoil は Atom で状態管理を行う https://recoiljs.org/

Slide 33

Slide 33 text

● Flux と同様にデータフローは単方向である ● Redux と同様に、あるイベントに対する更新処理を一箇所にまとめられる Flux や Redux のメリットを引き継いでいる

Slide 34

Slide 34 text

● Action や Reducer といった概念がなく、よりシンプルに書くことができる ● ボイラープレートのコード量が少なく、シンプルにかける ● 少ないコードで Redux のような状態管理が実現できる Redux と比べた利点：少ないコードでシンプルにかける

Slide 35

Slide 35 text

● Redux 特有の制約などがないため、学習コストが低い ● Hooks と似た書き方なので、学習コストが低い Redux と比べた利点：学習コストが低い

Slide 36

Slide 36 text

● カスタムフックとしてカプセル化できる ● カプセル化することで、意図しないデータの変更を防ぐことができる ● Redux だと Reducer からどの State でも変更できてしまう Redux と比べた利点：より安全にデータ更新ができる

Slide 37

Slide 37 text

帰りの会 まとめ

Slide 38

Slide 38 text

Redux と比べて、 ● 少ないコードでシンプルにかける ● 学習コストが低い ● より安全にデータ更新ができる Recoil の良さとはなんですか？ Flux と同様に、 ● 単方向データフローで実装できる Redux と同様に、 ● あるイベントに対して実行される処理を一箇所にまとめられる