implement-rfc

React Router RFC を実装する

以下の GitHub ディスカッションの RFC を実装してください: $ARGUMENTS

ブランチ戦略

RFC の実装はクリーンな作業ツリーから開始する必要があります。コミットされていない変更がある場合は、中断して、続行する前に解決するよう依頼してください。

• すでに main と同じ HEAD にある名前付きブランチにいる場合は、そのブランチを使用します。
• それ以外の場合は、{author}/rfc-{semantic-name} という形式で main からブランチを作成します:

  git branch {author}/rfc-{semantic-name} main
  git checkout {author}/rfc-{semantic-name}
  

ワークフロー

1. RFC を取得して理解する

WebFetch を使用してディスカッションの URL を読み取ります。URL の代わりに GitHub ディスカッション番号が指定されている場合は、以下を構築します: https://github.com/remix-run/react-router/discussions/<number>

以下を抽出します:

• 解決する問題: この RFC はどのような課題に対処していますか?

• 提案された API: 正確な関数シグネチャ、フック名、型、オプションの形状

• 影響を受けるモード: Declarative / Data / Framework / RSC Data / RSC Framework

• 破壊的変更: この変更は既存の公開 API を変更または削除しますか?

• 未解決の疑問点: 明示的に未解決とされているもの、「TBD」とされているもの、または提案内で質問として挙げられているもの

• ステータス: リンクされたトラッキング issue はありますか? 他の GitHub issue へのリンクを探し、追加のコンテキストがあるかどうかを確認するためにそれらを読みます。

  gh issue view <number> --repo remix-run/react-router
  

2. コミュニティのフィードバックを評価する

ディスカッションからすべてのコメントを取得します:

https://github.com/remix-run/react-router/discussions/<number> に対して WebFetch を使用し、スレッド全体を最後までスクロールします。以下を探します:

• コミュニティメンバーやメンテナーによって提起された懸念や反対意見
• 代替案や API の形状に関する提案
• 提案が対処していないエッジケース
• 肯定的なシグナル — 特定のアプローチに対する繰り返しの称賛は、それが正しい方向性であることを示します
• メンテナーの回答 — Ryan Florence、Michael Jackson、または他のコアチームメンバーによる意図の明確化

コミュニティのセンチメントを以下にまとめます:

• 合意点 (そのまま進めて問題ない)
• 争点 (実装前に解決が必要)
• 元の提案からの未回答の疑問点

3. 未解決の疑問点を解決する

コードを書く前に、RFC 自体とコミュニティのフィードバックの両方から、すべての未解決の疑問点を番号付きリストにして提示してください。各疑問点について:

• 疑問点を明確に述べる
• 関連するコミュニティの意見を要約する
• 根拠とともに推奨する回答を提示する

各疑問点について確認するか、上書きするか、スキップするよう依頼してください。すべての疑問点が回答済みであるか、明示的に保留にされるまで、実装に進まないでください。

フォーマット例:

## Unresolved Questions

1. **Should `useRouterState()` accept a path argument for scoped matching?**
   Community feedback: 3 comments in favor, 1 against (concerns about complexity).
   Recommendation: Yes — scoped matching improves type safety for nested routes.
   → Your decision: [confirm / override / defer]

2. **What should happen when the path doesn't match the current location?**
   Recommendation: Return `null` for active state (consistent with `useMatch()`).
   → Your decision: [confirm / override / defer]

解決された決定事項は、実装中の参照用に tasks/rfc-decisions.md のスクラッチファイルに保存します。

4. 実装を計画する

コードを書く前に、以下を網羅した簡潔な実装計画を作成します:

• 追加する新しい型 / インターフェース
• 実装する新しい関数 / フックとそのファイルの場所
• 非推奨にする既存の API (@deprecated JSDoc + 開発環境でのコンソール警告でマークする)
• フューチャーフラグが必要かどうか (以下の §5 を参照)
• 作成または拡張するテストファイル (ユニットおよび / または統合)
• changeset のバンプレベル (新機能には minor、デフォルトで有効になったフューチャーフラグの背後にある破壊的変更には major)

実装する前に計画を提示し、承認を待ちます。

5. 破壊的変更に対するフューチャーフラグ

RFC が既存の公開 API の動作を変更または削除する場合、unstable_ プレフィックスで始まるフューチャーフラグの背後で必ずリリースする必要があります。

フューチャーフラグのパターン:

1. packages/react-router/lib/router/utils.ts の FutureConfig にフラグを追加します:

   export interface FutureConfig {
     // existing flags...
     unstable_myNewBehavior: boolean;
   }
   

2. フラグに基づいて新しい動作を制御します:

   if (router.future.unstable_myNewBehavior) {
     // new behavior
   } else {
     // legacy behavior
   }
   

3. 存在する場合は docs/upgrading/future-flags.md にフラグを文書化します。

新しく追加される API (既存のコードの動作変更なし) には、フューチャーフラグは不要です。

6. 主要なファイルの場所

エリア	ファイル
コアルーターのロジック	packages/react-router/lib/router/router.ts
ルーターの型/ユーティリティ	packages/react-router/lib/router/utils.ts
React コンポーネント	packages/react-router/lib/components.tsx
React フック	packages/react-router/lib/hooks.tsx
パブリックエクスポート	packages/react-router/index.ts
DOM ユーティリティ	packages/react-router/lib/dom/
フレームワーク/Vite プラグイン	packages/react-router-dev/vite/plugin.ts
RSC ランタイム	packages/react-router/lib/rsc/
ユニットテスト	packages/react-router/__tests__/
統合テスト	integration/
フューチャーフラグのドキュメント	docs/upgrading/future-flags.md

新しいコードを書く前に既存のパターンを確認してください。LSP の使用を推奨しますが、Grep/Glob も使用できます。命名規則とコードスタイルを正確に一致させてください。

7. 機能を実装する

承認された計画に従ってください。各論理的な作業単位ごとに:

1. 実装を書く
2. 適切なパブリックエントリポイント (packages/react-router/index.ts) からエクスポートする
3. 置き換えられる API に @deprecated JSDoc を追加する
4. 型エラーを早期に検出するために型チェックを実行する:

   pnpm typecheck
   

変更は最小限かつ集中的に保ってください。無関係なコードをリファクタリングしないでください。必要に応じて頻繁にコミットしてください。

8. テストを書く

ユニットテスト (フック、純粋なルーターロジック、コンポーネントの動作 — ビルド不要):

• 場所: packages/react-router/__tests__/
• ランナー: Jest → pnpm test packages/react-router/__tests__/<file>
• カバー: ハッピーパス、RFC/コミュニティのフィードバックで特定されたエッジケース、フューチャーフラグのゲーティング (該当する場合)、非推奨の警告

統合テスト (Vite/フレームワークモード、SSR、ハイドレーション向け):

• 場所: integration/
• ランナー: Playwright → pnpm test:integration:run --project chromium integration/<file>
• RFC がフレームワークモード、ファイルシステムルーティング、または SSR の動作に触れる場合に必須

すべてのテストを実行し、合格することを確認する:

pnpm test packages/react-router/
pnpm test:integration:run --project chromium  # only if integration tests were added/changed

9. Lint と型チェック

pnpm lint
pnpm typecheck

続行する前にすべてのエラーを修正してください。

10. チェンジファイルを作成する

packages/<package>/.changes/<bump-level>.<descriptive-name>.md を作成します。RFC のタイトルまたはトラッキング Issue を説明として使用してください:

feat: <brief description matching the RFC title>

Implements the `useRouterState()` RFC (#12358). Deprecates `useLocation`,
`useParams`, `useSearchParams`, `useNavigation`, `useMatches`, `useMatch`,
`useNavigationType`, and `useViewTransitionState` in favor of a unified API.

Enable the `unstable_consolidatedRouterState` future flag to opt in.

バンプレベル:

• patch — バグに隣接する修正のみ
• minor — 新しい追加 API (破壊的変更なし)
• major — 破壊的変更 (稀であるべき。ほとんどの破壊的変更はまずフューチャーフラグの背後で minor として提供されます)
• unstable — まだ安定していない新しい API (例: フューチャーフラグで追加された、または major バンプなしで削除される可能性のある実験的な API)

11. 報告とレビュー

要約:

• どの RFC が実装され、どのような決定がなされたか
• 追加された新しいパブリック API (簡単な使用例付き)
• 非推奨となった API と移行パス
• フューチャーフラグ名 (該当する場合) とオプトイン方法
• 追加されたテストカバレッジ
• 延期された、または明示的にスコープ外とされたもの

PR を開く前に、レビューとイテレーションを依頼してください。

12. コミット

私が承認したら、コミットして main に PR を開いてください:

gh pr create --base main --title "feat: <RFC title>" --body "..."

PR の本文には以下を含めてください:

• RFC ディスカッションへのリンク (Closes または Implements #NNNN)
• 実装された内容の要約
• 該当する場合はフューチャーフラグの手順
• テストに関する注意事項
• 元の提案から逸脱した決定とその理由