Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Sign up for free
Menu
Search
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Features
All features
Private URLs
Password Protection
Custom URLS
Scheduled publishing
Remove Branding
Restrict embedding
Deck Collections
Notes
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Explore
Featured decks
Featured speakers
Programming
Technology
Storyboards
Pricing
Search
Sign in
Sign up for free
ステート管理を超えるRecoil運用の考え方
Search
uhyo
January 20, 2023
Technology
14k
16
Share
Embed
Copy iframe code
Copy JS code
Copy link
Start on current slide
ステート管理を超えるRecoil運用の考え方
Harajuku.ts Meetup 〜 Recoilの事例集めました〜
uhyo
January 20, 2023
More Decks by uhyo
See All by uhyo
Reactの設計論
uhyo
25
16k
型があると何が嬉しいか
uhyo
3
150
Baseline対応のDOMの型定義を作った
uhyo
3
980
AIのReact習熟度を測る
uhyo
2
1.1k
React、まだ楽しくて草
uhyo
7
5.1k
TypeScript 7.0の現在地と備え方
uhyo
6
3.9k
React 19時代のコンポーネント設計ベストプラクティス
uhyo
20
11k
型定義でAIと会話する:型を通じてAIに意図を伝えるテクニック
uhyo
1
120
タグ付きユニオン型を便利に使うテクニックとその注意点
uhyo
3
1.2k
Other Decks in Technology
See All in Technology
いちAWSエンジニアのAI活用を振り返る #devio2026 / devio osaka 2026 kawahara
masahirokawahara
2
380
FinTech 1-2 : Overview of FinTech
ks91
PRO
0
150
雪かき部 #7 もう怖くない!SELECT文!
foursue
0
280
調査タスクをAIと乗り切る 〜過去の調査をナレッジ化し 調査手順をスキルにする〜
mot_techtalk
1
110
Oracle Base Database Service 技術詳細
oracle4engineer
PRO
16
120k
ビジネスを止めない技術的負債の返済のための戦略とその手法 - 技術的負債と向き合う / Complexity and Simplicity
soudai
PRO
3
550
AIは爆速なのに、私が詰まっていた話 ― 音声入力と鳴くマスコットでボトルネックを削る
yama3133
0
520
IR Today: Theory, Practice, and Agents
dtunkelang
0
340
並行性の問題を防げ!実践トランザクション入門
occhi
0
260
オンラインゲームのシステム全体像 - コロプラ 2026年度 新卒研修
colopl
0
450
ai_cording_with_k8s_knowledge.pdf
mochizuki875
1
280
AI時代のAPI開発を加速する品質ガードレール / API Quality Guardrails in the AI Era
yokawasa
0
130
Featured
See All Featured
The Impact of AI in SEO - AI Overviews June 2024 Edition
aleyda
6
1.2k
GraphQLの誤解/rethinking-graphql
sonatard
75
12k
Fireside Chat
paigeccino
43
4k
Public Speaking Without Barfing On Your Shoes - THAT 2023
reverentgeek
1
580
Build your cross-platform service in a week with App Engine
jlugia
234
19k
KATA
mclloyd
PRO
35
16k
Building a Modern Day E-commerce SEO Strategy
aleyda
45
9.2k
Building AI with AI
inesmontani
PRO
1
1.3k
Six Lessons from altMBA
skipperchong
29
4.5k
Breaking role norms: Why Content Design is so much more than writing copy - Taylor Woolridge
uxyall
1
440
Bioeconomy Workshop: Dr. Julius Ecuru, Opportunities for a Bioeconomy in West Africa
akademiya2063
PRO
1
390
The Curious Case for Waylosing
cassininazir
1
550
Transcript
None
イベント趣旨 Recoilがリリースされてから2年半が経った。 これだけ経てば使っている人も結構多いはず。 しかし、そのわりに具体的な「事例」が世に出ていない気がする。 今回は、Recoilを使いこなしている皆さんにお越しいただいて、 事例を語ってもらうことにした。
イベント趣旨 Twitterで何となくRecoil勉強会したいな~と言ったところ、 話したい人・聞きたい人がいたため開催に繋げることができた。 ありがとうございます こんな勉強会をしてほしい等のアイデアも募集中!
事前アンケート結果 参加者の皆さんにアンケートに答えていただきました。 Recoil使われていますか? 使って みたい 194 使って いる 160 使う予定はない
19
事前アンケート結果 参加者の皆さんにアンケートに答えていただきました。 RecoilとJotaiのどちらがお好きですか? Recoil 142 わから ない 202 Jotai 29
事前アンケート結果 参加者の皆さんにアンケートに答えていただきました。 RecoilとJotaiのどちらがお好きですか? Recoil 142 わから ない 202 Jotai 29
Recoilが優勢だが、浮動票が多くJotaiも 巻き返しのチャンス。 ※本イベントはRecoilをテーマにしていますが、 Jotaiもかなり似たライブラリですので、 Jotai派の方は脳内変換しながらお聞きください。
ステート管理を超える Recoil運用の考え方 Harajuku.ts Meetup ~Recoilの事例集めました~ uhyo (株式会社バベル プリンシパルエンジニア)
登壇者紹介 uhyo 2022年10月から株式会社バベル勤務。 最近サーバーサイドを見ていることも 多いが、心はフロントエンドエンジニア。 TypeScript入門書 好評発売中!→
商談解析クラウド では、フロントエンドに ReactとともにRecoilを使用。 移行が終わっていないため他の状態管理手法と混ざっているが、 Recoilに寄せていく狙いがある。 Why? How? をお話しします aileadとRecoil
このトークの要約 • 実はFluxって天才だったのでは? • Recoilくんとならやり直せる気がする
事の発端 公式サイトによれば、Reactは “A JavaScript library for building user interfaces” である。
https://reactjs.org/ より引用
事の発端 公式サイトによれば、Reactは “A JavaScript library for building user interfaces” である。
ということは、UIを構築する以外の仕事をさせないほうが筋が いいのでは? UI以外のことはReactから切り離したい。
UI以外のことの例 • 外部からのデータの読み込み • アプリケーションの状態の保持 • ビジネスロジックの計算
理想的と思われるアーキテクチャ React層 コア層 • 状態の保持 • 状態遷移の定義 • DOMへの最適化された レンダリング
整形層 • 外部からの データの読み込み • UI用にデータを整形 UIへの入力
どこかで見たような…… React層 コア層 整形層 https://facebook.github.io/flux/docs/in-depth- overview/ から引用
Fluxとどこが違うのか? Fluxだと「Store」となっているところ が、コア層と整形層に分離した。 単純なFluxだと成果物が「でかい状態 の塊」になってしまうのでつらい。 そもそも、コアな状態は少なければ 少ないほどいい。 (useMemoで済むのにuseStateを使うべきではない のと同様) あと、アクションの概念は要らない。
React層 コア層 整形層
Recoil運用のアイデア ここをRecoilにやってもらうのが 良いのでは? React層 コア層 整形層
Recoilの良いところ atom(自身で状態を保持する)とselector(ほかの状態を見て計算する) があり、コアな状態(atom)がどれなのかを設計上明らかに しやすい。 非同期ネイティブであり、非同期処理もselectorとして扱える。 (データ読み込みの結果や進捗などはコアな状態として扱う必要がない) 思想がReactと近い。「ロジック用のReact」のような使い心地。 • イミュータブル・冪等性が前提のAPI •
計算結果の一貫性保証
atomとselectorの使い分け 他に従属しない状態がatom。それ以外は何が何でもselectorに する。 例: 検索画面 • 検索条件: atom (ユーザーが独立に変更できるため) •
ページ数: atom (ユーザーが独立に変更できるため) • 検索結果: selector (上2つ(+サーバーの状態)から計算できるため) ※ページングがカーソルベースだった場合はすこし迷うが、サーバーから可能な 選択肢を取得してそのなかから選んだと考えてカーソルをatomに保存するか
Recoil層とReact層のつなぎ込み React層 コア層 整形層 出力用フック 入力用フック Recoil層とReact層の境界は当然 フック。 出力用フックは無くてもいいという 説もあるが、useMemoやuseEffect
が必要になったときのエスケープ ハッチとしては有用か。
具体例 React層 検索 条件 ページ 数 検索 結果 useSearchResult useSearchQuery
usePagination atomから始まるデータの流れが RecoilのAPIを用いて定義される。 (データフローグラフ)
具体例 React層 検索 条件 ページ 数 検索 結果 useSearchResult useSearchQuery
usePagination React層からの入力は基本的にコア 状態の変更として作用するので、 入力用フックを介してコア状態を 更新する。 グローバルなアクションといった 概念は存在せず、ユースケースに 応じた個別の入力用フックがある。 入力用フックもコア層の一部と して扱うのが筋良さそう
具体例 React層 検索 条件 ページ 数 検索 結果 useSearchResult useSearchQuery
usePagination Reactコンポーネントツリーの 上から下にデータが流れる様子に 似ているが、 Recoilを使う場合はReactに入る前 に計算が終わっているという 点が異なる。
Reactにロジックを乗せると良くない点 ReactにUI以外のことを無理にやらせると、アプリケーションの 整合性を保つのが困難になる。 例: Reactでやる場合 const [検索条件] = useState(); useEffect(()
=> { 検索結果取得(); }, [検索条件]); 検索条件変更 ↓ レンダリング ↓ useEffect発火 ↓ 検索結果取得開始 ↓ …
Reactにロジックを乗せると良くない点 ReactにUI以外のことを無理にやらせると、アプリケーションの 整合性を保つのが困難になる。 例: Reactでやる場合 const [検索条件] = useState(); useEffect(()
=> { 検索結果取得(); }, [検索条件]); 検索条件変更 ↓ レンダリング ↓ useEffect発火 ↓ 検索結果取得開始 ↓ … 検索条件が変わったのに 検索結果が前のままと いう中途半端な状態が レンダリングされて しまっている
Reactにロジックを乗せると良くない点 ReactにUI以外のことを無理にやらせると、アプリケーションの 整合性を保つのが困難になる。 例: Recoilでやる場合 検索条件変更 ↓ 検索結果取得開始 ↓ レンダリング
Recoil内部で整合性の とれた状態を計算し 終わってからReactに ステートが伝達される 検索 条件 ペー ジ数 検索 結果
ReactとRecoilの整合性保証 Reactの整合性保証 レンダリングの際は、 ある瞬間の状態がコンポーネント ツリー全体に反映される。 古い状態と新しい状態が 画面上で混在することはない。 状態→画面の整合性 Recoilの整合性保証 グラフの状態計算の際は、
ある瞬間の状態がグラフ全体に 反映される。 古い状態と新しい状態が React上で混在することはない。 グラフ→状態の整合性
ReactとRecoilの整合性保証 ここの整合性をRecoilが担当 ここの整合性はReactが担当 React層 コア層 整形層
Recoilを活用するデータフロー設計 Recoilの魅力は、atomやselectorをはじめとする シンプル・ローレベルなAPIから構成されているところ。 これらを組み合わせることで独自の機能を持ったノードを作ること ができる。 さらに、Reactよりも無理がきかない(エスケープハッチが無い)。 望ましい設計を保ちやすい。
Recoilを活用するデータフロー設計 例: 検索 条件 Graph QL GraphQLリクエストを行う selector 検索 条件
ページ 数 他の状態が変化したら リセットされるatom
まとめ Recoilをロジックに用いる設計を試している。 改めて見てみると、Fluxの良いところを受け継ぎつつ良くない ところを直したような構成になっている。 ReactはそろそろUIライブラリに専念させてあげたい。 文章で読みたい方はこちらもどうぞ(宣伝): Recoilにロジックを載せる運用戦略 https://zenn.dev/babel/articles/recoil-for-babel