Upgrade to Pro — share decks privately, control downloads, hide ads and more …

キッチハイク社内勉強会 / 2021-02-10

キッチハイク社内勉強会 / 2021-02-10

41c9dedd1b4c53ace82e040bb09334fe?s=128

Takuma Yamamoto

June 21, 2021
Tweet

Transcript

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

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

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

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

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

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

  7. 0限目 React の登場

  8. React という JavaScript ライブラリの登場 • 2013年3月 JSConfUS にて React が

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

  10. 1限目 Flux の登場

  11. Flux という新しいアーキテクチャの登場 • 2014年5月 Facebook F8 にて Flux というアーキテクチャが提唱される •

    アプリケーション内のデータフローを単方向化する https://youtu.be/nYkdrAPrdcw
  12. Facebook の Flux による課題解決ストーリー https://youtu.be/nYkdrAPrdcw • Facebook 自身も Flux によって課題を解決していた

    • Facebook F8 にて、実体験と一緒に Flux が紹介された
  13. チャット機能の変遷:ChatTab 機能の実装 • 最初は ChatTab という機能が実装された • メッセージを送信したら、ChatTab にそれを追加するというシンプルな実装 https://youtu.be/nYkdrAPrdcw

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

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

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

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

  18. データフローを単方向化し「予測可能」な状態にする • Action → Dispatcher → Store → View というデータフロー

    • どこでどんな処理が行われるか、処理の流れを把握できるようになった https://youtu.be/nYkdrAPrdcw
  19. コードベースで Flux を見てみる https://github.com/eggheadio/egghead-react-flux-example

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

  21. • jQuery とかで Flux 実装するとDOM操作が複数回発生 • 画面描画においてレンダリング処理が一番コストが高い • DOM操作を行う度にレンダリング処理が行われる •

    DOM操作の回数を減らすことが大切(コードにも見受けられる) なぜ Flux での実装がされてこなかったのか? 参照:https://eh-career.com/engineerhub/entry/2020/02/18/103000
  22. React の登場で UX を損わずに Flux で実装できる • 仮想DOMにより、DOM操作を最小限に抑えることができる • Reactの登場でUXを損わずにFluxで実装ができる

    • UXを損なわずにデータを管理しやすくすることを実現 https://youtu.be/nYkdrAPrdcw
  23. 2限目 Redux の登場

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

    Create Message Create Thread waitFor
  25. Reducer という概念をもつ Redux が誕生 • Flux の課題を解決する Reducer という概念が生まれる •

    Redux は Reducer という概念を持った状態管理ライブラリである • Flux と同様に単方向データフローである https://redux.js.org/
  26. Redux 3原則:State is read-only • Action を受けとって State を変更することは Flux

    と同じ • State は常に読み取り専用で、変更は Action を通じてのみ可能 https://redux.js.org/tutorials/essentials/part-2-app-structure
  27. Redux 3原則:Single source of truth • Flux と違い Store がひとつになり、データ管理の場所が一箇所になった

    • アプリケーション全体の State をひとつのオブジェクトツリーで表現 https://redux.js.org/understanding/thinking-in-redux/three-principles
  28. Redux 3原則:Changes are made with pure functions • State の更新は

    Action を受け取った Reducer で処理される • あるアクションに対する State の更新処理が一箇所にまとまった • State の更新処理の順番を指定しやすくなった https://redux.js.org/tutorials/essentials/part-2-app-structure
  29. Redux によって解決された React の課題 • Store のデータを参照できるので、Props のバケツリレーがなくなる • それにより、不要な仮想

    DOM 再レンダリングを抑えることができる 引用元:https://www.techscore.com/blog/2018/12/02/react-when-the-render-will-be-called/
  30. 3限目 Recoil の登場

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

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

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

  34. • Action や Reducer といった概念がなく、よりシンプルに書くことができる • ボイラープレートのコード量が少なく、シンプルにかける • 少ないコードで Redux

    のような状態管理が実現できる Redux と比べた利点:少ないコードでシンプルにかける
  35. • Redux 特有の制約などがないため、学習コストが低い • Hooks と似た書き方なので、学習コストが低い Redux と比べた利点:学習コストが低い

  36. • カスタムフックとしてカプセル化できる • カプセル化することで、意図しないデータの変更を防ぐことができる • Redux だと Reducer からどの State

    でも変更できてしまう Redux と比べた利点:より安全にデータ更新ができる
  37. 帰りの会 まとめ

  38. Redux と比べて、 • 少ないコードでシンプルにかける • 学習コストが低い • より安全にデータ更新ができる Recoil の良さとはなんですか?

    Flux と同様に、 • 単方向データフローで実装できる Redux と同様に、 • あるイベントに対して実行される処理を一箇所にまとめられる