Dataモードでのデザインパターン/Design Pattern for Data Router/Loader/Action

2026React Osaka 03での発表用スライド

Transcript

1. Data Router/Loader/Actionのデ ザインパターン Design Pattern for Data Router/Loader/Action © Nabe-cyan(t-pot.me)
2. 概要 Summary • React Router V7を使った実装をすることになったので、どういう実装パターンが 良さそうか調べたりした（まだまだ使い始めたばかりなので分からない部分も多 いです） • 今回話すことのほとんどはbulletproof-reactを見れば分かる • アドバイスや指摘はwelcomeです！ • Since I’ve started to use React Router V7, I’ve been researching which implementation patterns seem better (I’m still new to this, so there’s a lot I don’t know yet) • Most of what I’ll be discussing here can be found in the bulletproof-react doc • Any advice or suggestions are very welcome!
3. React Router を使ったことがある /大体知っている 方✋ Anyone who have used React Router / have general understanding about it? ✋
4. React Routerとは / What is React Router • React アプリで「URL（パス）」と「表示する画面（コンポーネント）」を結びつけるための ルーティングライブラリ • 対抗としてNext.jsが挙げられることが多い（私はNext.jsも好きです） • Web標準な処理を書けることが多い（特にフォーム） • A routing library for linking “URLs (paths)” to “displayed screens (components)” in React apps • Next.js is often cited as a competitor; I also like Next.js! • It often allows for writing code that adheres to web standards (especially for forms)
5. bulletproof-reactとは(1) / What is bulletproof-react(1) image is from: https://github.com/alan2207/bulletproof-react
6. bulletproof-reactとは(2) / What is bulletproof-react(2) • Reactアプリのための「設計ガイド」 • スケールしやすい構成を提示するレポジトリ • プロジェクト構成・規約・API層・状態管理・テスト・エラーハンドリング・セキュリティ等をド キュメント化 ◦ 今回はapps/react-viteフォルダの構成を検討 • “Design Guide” for React Apps • A repository that provides a scalable architecture • Doc covering project structure, conventions, API layers, state management, testing, error handling, security, and more ◦ This time, I'll examine the structure of the `apps/react-vite` folder
7. bulletproof-reactとは(3) / What is bulletproof-react(3) src/ ├── app/ │ ├── routes/ ← entry points for each page │ ├── app.tsx ← RouterProvider + AppProvider │ ├── provider.tsx ← global providers │ └── router.tsx ← routes definitions ├── assets/ ├── components/ ← shared components ├── config/ ← global settings, constans ├── features/ ← feature based modules ├── hooks/ ← shared hooks ├── lib/ ← reusable libraries preconfigured for the application like API client ├── stores/ ← global state store ├── testing/ ← tests ├── types/ ← shared type definitions ├── utils/ ← shared functions └── main.tsx ← StrictMode + App のみのシンプルなエントリ
8. Loaderとは / What is Loader • そのルート（ページ）を表示する前に必要なデータを 取ってくる処理 • 例：/users に入る前にユーザー一覧を fetch し、画 面側はその結果を使って描画 ◦ （実装例はコードを見ながら説明）
9. Actionとは / What is Action • フォーム送信など“データを変更する 操作”を受け付ける処理 • 例：ユーザー作成フォームを送信した ら、action が入力を受けて API を叩 き、成功ならリダイレクト・失敗ならエ ラーを返す
10. 注意点・補足 / Notes and Additional Information • LoaderとActionによってAPIリクエストの処理をコンポーネントから分離でき、データ取 得のuseEffectは減るが、タイマーなどでは引き続きuseEffectが必要な認識 • 画面データの再取得が必要な場合は useRevalidator() で再読み込みが可能 • ルートオブジェクト（コンポーネント）のLoaderの再検証（再実行）条件の調整も可能 • Using Loaders and Actions allows you to decouple API request handling from components, which reduces the number of `useEffect` hooks used for data fetching; `useEffect` hooks are still required for tasks such as timers • If you need to re-fetch screen data, you can use `useRevalidator()` to trigger a reload • You can also adjust the revalidation (re-execution) conditions for the Loader associated with the root object (component).
11. まとめ・使ってみての所感（激浅） / Recap・Super shallow first impressions • As is the case with bulletproof-react, for apps that are somewhat complex and large, React-Hook-Form + Zod seems like a better choice than React Router’s default Form component • Since it makes it easy to intuitively understand the connection between routing and components, I think it’s a good option for beginners as well • I can sense a steely determination to separate the API layer from the components using Loaders and Actions ◦ Presumably, no matter how you write it, these elements will be separated to some extent • I’m curious about where the framework’s limits lie, such as the constraints encountered when trying to improve performance