ステート管理を超えるRecoil運用の考え方

by uhyo

Slide 1

Slide 1 text

No content

Slide 2

Slide 2 text

イベント趣旨 Recoilがリリースされてから2年半が経った。これだけ経てば使っている人も結構多いはず。しかし、そのわりに具体的な「事例」が世に出ていない気がする。今回は、Recoilを使いこなしている皆さんにお越しいただいて、事例を語ってもらうことにした。

Slide 3

Slide 3 text

イベント趣旨 Twitterで何となくRecoil勉強会したいな～と言ったところ、話したい人・聞きたい人がいたため開催に繋げることができた。ありがとうございますこんな勉強会をしてほしい等のアイデアも募集中！

Slide 4

Slide 4 text

事前アンケート結果参加者の皆さんにアンケートに答えていただきました。 Recoil使われていますか？使ってみたい 194 使っている 160 使う予定はない 19

Slide 5

Slide 5 text

事前アンケート結果参加者の皆さんにアンケートに答えていただきました。 RecoilとJotaiのどちらがお好きですか？ Recoil 142 わからない 202 Jotai 29

Slide 6

Slide 6 text

事前アンケート結果参加者の皆さんにアンケートに答えていただきました。 RecoilとJotaiのどちらがお好きですか？ Recoil 142 わからない 202 Jotai 29 Recoilが優勢だが、浮動票が多くJotaiも巻き返しのチャンス。 ※本イベントはRecoilをテーマにしていますが、 Jotaiもかなり似たライブラリですので、 Jotai派の方は脳内変換しながらお聞きください。

Slide 7

Slide 7 text

ステート管理を超える Recoil運用の考え方 Harajuku.ts Meetup ～Recoilの事例集めました～ uhyo （株式会社バベルプリンシパルエンジニア）

Slide 8

Slide 8 text

登壇者紹介 uhyo 2022年10月から株式会社バベル勤務。最近サーバーサイドを見ていることも多いが、心はフロントエンドエンジニア。 TypeScript入門書好評発売中！→

Slide 9

Slide 9 text

商談解析クラウドでは、フロントエンドに ReactとともにRecoilを使用。移行が終わっていないため他の状態管理手法と混ざっているが、 Recoilに寄せていく狙いがある。 Why? How? をお話しします aileadとRecoil

Slide 10

Slide 10 text

このトークの要約 • 実はFluxって天才だったのでは？ • Recoilくんとならやり直せる気がする

Slide 11

Slide 11 text

事の発端公式サイトによれば、Reactは “A JavaScript library for building user interfaces” である。 https://reactjs.org/ より引用

Slide 12

Slide 12 text

事の発端公式サイトによれば、Reactは “A JavaScript library for building user interfaces” である。ということは、UIを構築する以外の仕事をさせないほうが筋がいいのでは？ UI以外のことはReactから切り離したい。

Slide 13

Slide 13 text

UI以外のことの例 • 外部からのデータの読み込み • アプリケーションの状態の保持 • ビジネスロジックの計算

Slide 14

Slide 14 text

理想的と思われるアーキテクチャ React層コア層 • 状態の保持 • 状態遷移の定義 • DOMへの最適化されたレンダリング整形層 • 外部からのデータの読み込み • UI用にデータを整形 UIへの入力

Slide 15

Slide 15 text

どこかで見たような…… React層コア層整形層 https://facebook.github.io/flux/docs/in-depth- overview/ から引用

Slide 16

Slide 16 text

Fluxとどこが違うのか？ Fluxだと「Store」となっているところが、コア層と整形層に分離した。単純なFluxだと成果物が「でかい状態の塊」になってしまうのでつらい。そもそも、コアな状態は少なければ少ないほどいい。（useMemoで済むのにuseStateを使うべきではないのと同様）あと、アクションの概念は要らない。 React層コア層整形層

Slide 17

Slide 17 text

Recoil運用のアイデアここをRecoilにやってもらうのが良いのでは？ React層コア層整形層

Slide 18

Slide 18 text

Recoilの良いところ atom（自身で状態を保持する）とselector（ほかの状態を見て計算する）があり、コアな状態（atom）がどれなのかを設計上明らかにしやすい。非同期ネイティブであり、非同期処理もselectorとして扱える。（データ読み込みの結果や進捗などはコアな状態として扱う必要がない）思想がReactと近い。「ロジック用のReact」のような使い心地。 • イミュータブル・冪等性が前提のAPI • 計算結果の一貫性保証

Slide 19

Slide 19 text

atomとselectorの使い分け他に従属しない状態がatom。それ以外は何が何でもselectorにする。例: 検索画面 • 検索条件: atom （ユーザーが独立に変更できるため） • ページ数: atom （ユーザーが独立に変更できるため） • 検索結果: selector （上2つ（＋サーバーの状態）から計算できるため） ※ページングがカーソルベースだった場合はすこし迷うが、サーバーから可能な選択肢を取得してそのなかから選んだと考えてカーソルをatomに保存するか

Slide 20

Slide 20 text

Recoil層とReact層のつなぎ込み React層コア層整形層出力用フック入力用フック Recoil層とReact層の境界は当然フック。出力用フックは無くてもいいという説もあるが、useMemoやuseEffect が必要になったときのエスケープハッチとしては有用か。

Slide 21

Slide 21 text

具体例 React層検索条件ページ数検索結果 useSearchResult useSearchQuery usePagination atomから始まるデータの流れが RecoilのAPIを用いて定義される。（データフローグラフ）

Slide 22

Slide 22 text

具体例 React層検索条件ページ数検索結果 useSearchResult useSearchQuery usePagination React層からの入力は基本的にコア状態の変更として作用するので、入力用フックを介してコア状態を更新する。グローバルなアクションといった概念は存在せず、ユースケースに応じた個別の入力用フックがある。入力用フックもコア層の一部として扱うのが筋良さそう

Slide 23

Slide 23 text

具体例 React層検索条件ページ数検索結果 useSearchResult useSearchQuery usePagination Reactコンポーネントツリーの上から下にデータが流れる様子に似ているが、 Recoilを使う場合はReactに入る前に計算が終わっているという点が異なる。

Slide 24

Slide 24 text

Reactにロジックを乗せると良くない点 ReactにUI以外のことを無理にやらせると、アプリケーションの整合性を保つのが困難になる。例: Reactでやる場合 const [検索条件] = useState(); useEffect(() => { 検索結果取得(); }, [検索条件]); 検索条件変更 ↓ レンダリング ↓ useEffect発火 ↓ 検索結果取得開始 ↓ …

Slide 25

Slide 25 text

Slide 26

Slide 26 text

Reactにロジックを乗せると良くない点 ReactにUI以外のことを無理にやらせると、アプリケーションの整合性を保つのが困難になる。例: Recoilでやる場合検索条件変更 ↓ 検索結果取得開始 ↓ レンダリング Recoil内部で整合性のとれた状態を計算し終わってからReactにステートが伝達される検索条件ページ数検索結果

Slide 27

Slide 27 text

ReactとRecoilの整合性保証 Reactの整合性保証レンダリングの際は、ある瞬間の状態がコンポーネントツリー全体に反映される。古い状態と新しい状態が画面上で混在することはない。状態→画面の整合性 Recoilの整合性保証グラフの状態計算の際は、ある瞬間の状態がグラフ全体に反映される。古い状態と新しい状態が React上で混在することはない。グラフ→状態の整合性

Slide 28

Slide 28 text

ReactとRecoilの整合性保証ここの整合性をRecoilが担当ここの整合性はReactが担当 React層コア層整形層

Slide 29

Slide 29 text

Recoilを活用するデータフロー設計 Recoilの魅力は、atomやselectorをはじめとするシンプル・ローレベルなAPIから構成されているところ。これらを組み合わせることで独自の機能を持ったノードを作ることができる。さらに、Reactよりも無理がきかない（エスケープハッチが無い）。望ましい設計を保ちやすい。

Slide 30

Slide 30 text

Recoilを活用するデータフロー設計例: 検索条件 Graph QL GraphQLリクエストを行う selector 検索条件ページ数他の状態が変化したらリセットされるatom

Slide 31

Slide 31 text

まとめ Recoilをロジックに用いる設計を試している。改めて見てみると、Fluxの良いところを受け継ぎつつ良くないところを直したような構成になっている。 ReactはそろそろUIライブラリに専念させてあげたい。文章で読みたい方はこちらもどうぞ（宣伝）: Recoilにロジックを載せる運用戦略 https://zenn.dev/babel/articles/recoil-for-babel