プロダクト改善のために新しいことを始める -useContextからの卒業、Zustandへ-

「useContextじゃもう無理かも」──そんな気づきから始まった、Zustand導入の話。 フロントエンド・バックエンドの垣根なく開発を進めるRebaseの現場で、担当プロダクトの大規模改修を機に、Reactの状態管理や再レンダリングの課題にどう向き合ったのかを振り返ります。

Transcript

1. プロダクトを少人数でスケールさせてきた僕ら Rebase Tech #0 プロダクト改善のために新しいことを始める ~ useContextからの卒業、 zustandへ ~ 株式会社 Rebase @y-okai 1
2. 2つ紹介したい • Main ) 新しい技術を導入するのに必要な準備とは何か • Sub ) useContextからどうやってzustandへ移行するか 今日のゴール 2
3. • TOIROについて • プロダクトで生まれた課題と提案 • zustandを導入してみて • まとめ 目次 3
4. 自己紹介 株式会社Rebase エンジニアリング @y-okai 経歴 • 不動産テック企業 エンジニア・スクラムマスター • 株式会社Rebase エンジニア 主な仕事 • コミュニティイベントサービス「TOIRO」の開発全般を 担当 • フルスタックには動いていますが、 どちらかというとフロントエンド寄り 4
5. 5 TOIRO について
6. 事業紹介 ・ イベントの作成 ・ 集客 ・ クレジットカード決済 ・ QRコード受付 ・ オープンチャット（TOIROG） TOIRO（https://toiro.com/） これまでにない新たなイベント体験を提供するコミュニティイベントサービス イベントを主催する方々にとって便利な機能を順次開発し実装していく予定です
7. 使っている主な技術 • フロントエンド ◦ TypeScript ◦ React.js ◦ Next.js ◦ TailwindCSS • バックエンド ◦ TypeScript ◦ Node.js ◦ GCP, Firebase ◦ Terraform TOIROについて 7
8. 8 プロダクトで生まれた 課題と提案
9. 生まれた課題 前提 • TOIROには「イベントを作成する」フォームがある ◦ タイトル、詳細、日程、場所、公開設定、色設定、 etc. • 入力内容によって、他のフォームの表示・非表示や必須項目が変わる 課題 • 機能拡張するにつれて、状態管理が複雑化すること • 状態変化による再レンダリング問題 プロダクトの中で生まれた課題と提案 9
10. プロダクトの中で生まれた課題と提案 10 サンプルを使って解説します
11. 例) ToDoアプリの場合 プロダクトの中で生まれた課題と提案 11 (1)色の変更
 (2)タスクの追加
 (3)タスクの追加 (モーダル)
 (4)タスクの表示
 (5)タスクの保存

12. どのように実装していたか • useContext + useReducerでページ全体の状態を管理 ◦ アクション(色の変更、タスクの追加)ごとに状態を反映 • 「一旦保存する」ボタンでDBへ保存 例) ToDoアプリの場合 プロダクトの中で生まれた課題と提案 12
13. 実際に動かしてみると • 選択対象以外で再レンダリングが起 こる... 例) ToDoアプリの場合 プロダクトの中で生まれた課題と提案 13
14. 解決策を考える • 案1) リファクタリングしてなんとかする ◦ Contextを分割する ◦ React.memoを利用する ◦ useMemoを利用する • 案2) 新しいツールを導入する プロダクトの中で生まれた課題と提案 14
15. 解決策を考える • 案1) リファクタリングしてなんとかする ◦ Contextを分割する ◦ React.memoを利用する ◦ useMemoを利用する • 案2) 新しいツールを導入する プロダクトの中で生まれた課題と提案 15 課題1) 
 　管理が必要な状態が増える 
 課題2)
 　対象箇所全てにメモ化処理が必要(開発者に依存) 

16. 解決策を考える • 案1) リファクタリングしてなんとかする ◦ Contextを分割する ◦ React.memoを利用する ◦ useMemoを利用する • 案2) 新しいツールを導入する(こっちで考える) プロダクトの中で生まれた課題と提案 16
17. プロダクトの中で生まれた課題と提案 17 新しいことを始めたい
18. プロダクトの中で生まれた課題と提案 18 新しいことを始めたい → 調査が必要
19. 調査すること (1) ツールの選定 (2) 導入するタイミング (3) 見積もり時間 (4) コード変更の範囲 (5) チームの学習コスト 19 プロダクトの中で生まれた課題と提案
20. (1)ツールの選定 • 候補 プロダクトの中で生まれた課題と提案 20 ライブラリ 記述量 Provider必須 設計の柔軟性 グローバル状態 ライブラリサイズ Zustand 少ない 不要 高い 可能 小さい Jotai 少ない 不要 高い 可能 小さい Redux Toolkit 多い 必要 標準的 可能 中〜大 • 考慮したいこと ◦ 機能拡張の増加(== 管理する状態が増える)に耐えられるもの ◦ 学習コストを減らすため、記述量が少なくシンプルなもの
21. (1) Zustand vs Jotai プロダクトの中で生まれた課題と提案 21 Zustand 
 Jotai 
 const countAtom = atom(0) const textAtom = atom('') const flagAtom = atom(false) function SampleComponent() { const [count, setCount] = useAtom(countAtom) const [text, setText] = useAtom(textAtom) return ( <div> <div>{count}</div> <button onClick={() => setCount(c => c + 1)}>+1</button> <input value={text} onChange={e => setText(e.target.value)} /> </div> ) } const useStore = create((set) => ({ count: 0, text: '', flag: false, inc: () => set(s => ({ count: s.count + 1 })), setText: (text) => set(() => ({ text })), toggleFlag: () => set(s => ({ flag: !s.flag })), })) function SampleComponent() { const { count, text, inc, setText } = useStore(useShallow((state) => { count: state.count, text: state.text, inc: state.inc, setText: state.setText } )) return ( <div> <div>{count}</div> <button onClick={inc}>+1</button> <input value={text} onChange={e => setText(e.target.value)} /> </div> ) } • ZustandはuseReducer、JotaiはuseStateに コード設計が近い • Zustandはセレクタもstoreのなかで管理できる 　→ Zustandを選択
22. (2)導入するタイミング 新しい機能開発プロジェクトと同時に行う ◦ 大規模なコードの変更が発生することになった ◦ 細部までシナリオテストを実施することになり、degradeもここで防げる プロダクトの中で生まれた課題と提案 22
23. (3)見積もり時間 細かな見積もりは難しい。 1機能だけに絞り、おおよそで見積 もる。 ◦ アプリケーション全体に適用するのは工数が読めない ◦ まずは1機能(イベントを作成するフォーム)のみ適用してみるこ とに ▪ 理由: アプリ内で状態管理が最も複雑な場所、かつ新規開発で 最も変更が入るため プロダクトの中で生まれた課題と提案 23
24. (4)コード変更の範囲 まずは1機能に絞り、変更の範囲を最小限にする ◦ 最終的にはシナリオテストを実施するので、degradeもここで 防げると判断 プロダクトの中で生まれた課題と提案 24
25. (5)チームの学習コスト 既存のコード設計に近いツールを選択する ◦ Zustand自体、現在利用しているuseReducerの設計に近い ◦ 実は一部すでにZustandを使っていたり、メンバーが利用経験 あったりした ◦ Zustand自体がシンプルであり、ドキュメントもしっかりしている ▪ -> チームで簡易的なハンズオンを行えば問題ないと判断 プロダクトの中で生まれた課題と提案 25
26. プロダクトの中で生まれた課題と提案 26 導入してみよう！
27. 導入までの流れ 1. 新規プロジェクトが動き出すタイミングで「新しいツールを導入したい」旨を チームに伝える a. 現状何に課題を持っているのか、それを導入することでどう変わるか 2. 事前調査を行い、一部コードに適用してみる 3. チーム内で成果を共有し、最終的な同意をとる 4. コード全体に適用 27 プロダクトの中で生まれた課題と提案
28. 導入までの流れ(現在) 1. 新規プロジェクトが動き出すタイミングで「新しいツールを導入したい」旨を チームに伝える a. 現状何に課題を持っているのか、それを導入することでどう変わるか 2. 事前調査を行い、一部コードに適用してみる 3. チーム内で成果を共有し、最終的な同意をとる 4. コード全体に適用 28 プロダクトの中で生まれた課題と提案 実はまだ終わってません。。😅 (どこかでお話しできたらいいなぁ。。)
29. 29 Zustandを導入してみて (実装の話)
30. 実装の話: 前提条件 • ページを初回開いたとき、DBから保存したデータを読み取り初期化する • 保存ボタンを押すと、DBへデータを反映する 30 Zustandを導入してみて
31. 実装の話: useContextの場合 31 Zustandを導入してみて export default function ContextPage() { ... // 初期データの読み込み useLoadInitialContextData(); return ( <ContextProvider> {/** body */} </ContextProvider> ); }
 export const ColorSelector = () => { const { buttonColor, setButtonColor } = useContextStore(); return ( ... <label className='flex items-center gap-2'> <input type='radio' name='color' value='#3B82F6' checked={buttonColor === '#3B82F6'} onChange={(e) => setButtonColor(e.target.value)} /> <span>青</span> </label> ... ); }; 
 /(root)/page.tsx /(root)/components/ColorSelector.tsx 何が問題か... 

32. 実装の話: useContextの場合 32 Zustandを導入してみて export default function ContextPage() { ... // 初期データの読み込み useLoadInitialContextData(); return ( <ContextProvider> {/** body */} </ContextProvider> ); }
 export const ColorSelector = () => { const { buttonColor, setButtonColor } = useContextStore(); return ( ... <label className='flex items-center gap-2'> <input type='radio' name='color' value='#3B82F6' checked={buttonColor === '#3B82F6'} onChange={(e) => setButtonColor(e.target.value)} /> <span>青</span> </label> ... ); }; 
 /(root)/page.tsx /(root)/components/ColorSelector.tsx 何が問題か... 
 buttonColorを変更すると、useContextStoreを参 照している他コンポーネントも再レンダリングが発 生する

33. 実装の話: Zustandの場合 33 Zustandを導入してみて export default function ClientZustandPage() { ... // 初期データの読み込み useLoadInitialClientData(); return ( <> {/** body */}</> ); } export const ColorSelector = () => { const { buttonColor, setButtonColor } = useZustandClientStore( useShallow((state) => ({ buttonColor: state.buttonColor, setButtonColor: state.setButtonColor, })) ); return ( ... <label className='flex items-center gap-2'> <input type='radio' name='color' value='#3B82F6' checked={buttonColor === '#3B82F6'} onChange={(e) => setButtonColor(e.target.value)} /> <span>青</span> </label> ... ); }; /(root)/page.tsx /(root)/components/ColorSelector.tsx POINT
 ・Providerが不要になる 
 ・各コンポーネントで必要な値のみ参照することで、 他のコンポーネントにも影響が出ない 

34. 実装の話: Zustandの場合 34 Zustandを導入してみて 実際に動かしてみると • 影響範囲のみに再レンダリングが走 ることが確認できる
35. 補足: Next.js + Zustand で気をつけたいこと • (1)storeをクライアント側で管理すること • (2)storeをまるごと参照しないこと 35 Zustandを導入してみて
36. (1)storeをクライアント側で管理すること • Next.jsでは、サーバー側でstoreを作成・管理できる • ただし、サーバーでstoreを持つと任意のユーザと状態が共有されてしまう 可能性がある ◦ -> 例) プライバシーの侵害、意図しない値の更新など 参考：https://zustand.docs.pmnd.rs/guides/nextjs 36 Zustandを導入してみて
37. (2)storeをまるごと参照しないこと • ページコンポーネントでstoreをまるごと参 照する ◦ -> いずれかの値が変更された時、ページ全体 が再レンダリングされる • 回避するには... ◦ 参照用に部分的にuseContextを使う ◦ 参照用のグローバル変数を別で定義する ◦ (他にもあるかも) 37 Zustandを導入してみて export const TodoContainer = () => { const { data, openModal, saveToStorage } = useZustandClientStore( useShallow((state) => ({ data: state, ... })) ); // DBへ保存 const handleSave = useCallback(async () => { await saveToStorage(data); }, [saveToStorage, data]); return ( <> {/** 各入力フォーム */} <button onClick={handleSave} > 一旦保存する </button> </> ); }; /(root)/page.tsx
38. より深く掘り下げたいあなたへ • サンプルコード(拙いコードです、ご了承ください ) https://github.com/ooyoshi00/zustand_context_comparison • 公式: Zustand > Comparison https://zustand.docs.pmnd.rs/getting-started/comparison • 公式: Jotai > Comparison https://jotai.org/docs/basics/comparison 38 Zustandを導入してみて
39. 39 まとめ
40. 何を伝えたかったか • 新しいことを始めるには、準備とタイミングが大事。 • (規模によるが)導入までには時間がかかる。熱量が大事。 • Zustandはイイゾ！ 最後に これから新しいツールを導入したい！ となったときの事例として、活用していただければ幸いです。 40 まとめ
41. 41 ご清聴ありがとうございました
42. 街中ですれ違う名前も知らない「あの人」も、「あなた」も誰もが無限の可能性を 持っている。そして、「あなた」がどんな場所に暮らしていても、どんなに他人から 無理だと言われても、諦めて欲しくない。 そんな想いから、 Rebaseは生まれました。挑戦の一歩を軽くすることで、人生に 大きな変化を生み出すサポートをしたい。 誰かの人生に彩を与える「ことのはじまり」を、一緒に作りませんか。 Let's work together! https://jobs.rebase.co.jp/