react18-legacy-context
ReactのレガシーコンテキストAPI(`contextTypes`・`childContextTypes`・`getChildContext`)を現代の`createContext` APIへ移行するための完全なマイグレーションパターンを提供します。クラスコンポーネントのレガシーコンテキスト移行時は必ずこのスキルを使用してください。この移行はプロバイダーとすべてのコンシューマーを同時に更新する必要があるため、常に複数ファイルにまたがる作業となります。プロバイダーのみ、またはコンシューマーのみを先に更新するとランタイムエラーが発生するため、`contextTypes`や`childContextTypes`のコードに触れる前に必ず参照し、ファイル間の連携手順に従って最も一般的な移行バグを防いでください。
description の原文を見る
Provides the complete migration pattern for React legacy context API (contextTypes, childContextTypes, getChildContext) to the modern createContext API. Use this skill whenever migrating legacy context in class components - this is always a cross-file migration requiring the provider AND all consumers to be updated together. Use it before touching any contextTypes or childContextTypes code, because migrating only the provider without the consumers (or vice versa) will cause a runtime failure. Always read this skill before writing any context migration - the cross-file coordination steps here prevent the most common context migration bugs.
SKILL.md 本文
React 18 従来のコンテキスト移行
従来のコンテキスト (contextTypes、childContextTypes、getChildContext) は React 16.3 で非推奨となり、React 18.3.1 では警告が表示されます。React 19 では削除されます。
これは常にファイル横断的な移行です
ほとんどの他の移行は一度に 1 つのファイルに対応しますが、コンテキスト移行には以下の調整が必要です:
- コンテキストオブジェクトを作成する(通常は新しいファイル)
- プロバイダーコンポーネントを更新する
- すべてのコンシューマーコンポーネントを更新する
いずれかのコンシューマーを見落とすと、アプリが壊れてしまい、間違ったコンテキストから読み込んだり undefined を取得したりします。
移行ステップ(必ずこの順序に従ってください)
ステップ 1: プロバイダーを見つける (childContextTypes + getChildContext)
ステップ 2: すべてのコンシューマーを見つける (contextTypes)
ステップ 3: コンテキストファイルを作成する
ステップ 4: プロバイダーを更新する
ステップ 5: 各コンシューマーを更新する (クラスコンポーネント → contextType、関数コンポーネント → useContext)
ステップ 6: 検証 - アプリを実行し、従来のコンテキスト警告が残っていないことを確認する
スキャンコマンド
# すべてのプロバイダーを見つける
grep -rn "childContextTypes\|getChildContext" src/ --include="*.js" --include="*.jsx" | grep -v "\.test\."
# すべてのコンシューマーを見つける
grep -rn "contextTypes\s*=" src/ --include="*.js" --include="*.jsx" | grep -v "\.test\."
# this.context の使用を見つける (従来のものか最新のものかは確認が必要)
grep -rn "this\.context\." src/ --include="*.js" --include="*.jsx" | grep -v "\.test\."
リファレンスファイル
references/single-context.md- 1 つのコンテキスト(テーマ、認証など)の完全な移行、プロバイダー + クラスコンシューマー + 関数コンシューマー付きreferences/multi-context.md- 複数の従来のコンテキストを持つアプリ(ネストされたプロバイダー、異なるコンテキストの複数のコンシューマー)references/context-file-template.md- 新しいコンテキストモジュールの標準的なファイル構造
ライセンス: MIT(寛容ライセンスのため全文を引用しています) · 原本リポジトリ
詳細情報
- 作者
- github
- ライセンス
- MIT
- 最終更新
- 不明
Source: https://github.com/github/awesome-copilot / ライセンス: MIT
関連スキル
doubt-driven-development
重要な判断はすべて、本番環境への展開前に新しい視点から対抗的レビューを実施します。速度より正確性が重要な場合、不慣れなコードを扱う場合、本番環境・セキュリティに関わるロジック・取り消し不可の操作など影響度が高い場合、または後でバグを修正するよりも今検証する方が効率的な場合に活用してください。
apprun-skills
TypeScriptを使用したAppRunアプリケーションのMVU設計に関する総合的なガイダンスが得られます。コンポーネントパターン、イベントハンドリング、状態管理(非同期ジェネレータを含む)、パラメータと保護機能を備えたルーティング・ナビゲーション、vistestを使用したテストに対応しています。AppRunコンポーネントの設計・レビュー、ルートの配線、状態フローの管理、AppRunテストの作成時に活用してください。
desloppify
コードベースのヘルスチェックと技術負債の追跡ツールです。コード品質、技術負債、デッドコード、大規模ファイル、ゴッドクラス、重複関数、コードスメル、命名規則の問題、インポートサイクル、結合度の問題についてユーザーが質問した場合に使用してください。また、ヘルススコアの確認、次の改善項目の提案、クリーンアップ計画の作成をリクエストされた際にも対応します。29言語に対応しています。
debugging-and-error-recovery
テストが失敗したり、ビルドが壊れたり、動作が期待と異なったり、予期しないエラーが発生したりした場合に、体系的な根本原因デバッグをガイドします。推測ではなく、根本原因を見つけて修正するための体系的なアプローチが必要な場合に使用してください。
test-driven-development
テスト駆動開発により実装を進めます。ロジックの実装、バグの修正、動作の変更など、あらゆる場面で活用できます。コードが正常に動作することを証明する必要がある場合、バグ報告を受けた場合、既存機能を修正する予定がある場合に使用してください。
incremental-implementation
変更を段階的に実施します。複数のファイルに影響する機能や変更を実装する場合に使用してください。大量のコードを一度に書こうとしている場合や、タスクが一度では完結できないほど大きい場合に活用します。