native-data-fetching

native-data-fetching スキルの概要

native-data-fetching が実際に役立つこと

native-data-fetching スキルは、React Native と Expo アプリでネットワークリクエストを実装・デバッグするための、Expo に特化したガイドです。単に「fetch を書いて」といった汎用的な指示では足りない場面で特に力を発揮します。API リクエスト、認証ヘッダー、キャッシュ方針、オフライン時の挙動、環境ごとの base URL、Expo Router のデータローダーまで、native-data-fetching の対象範囲に含まれます。

Frontend Development チームに最適なケース

native-data-fetching for Frontend Development は、リモートデータに依存するモバイル機能や Expo web 機能を構築していて、Expo の流儀に沿った実装指針がほしいチームに特に向いています。素の fetch を使うべきか、React Query や SWR のようなデータライブラリを使うべきか、あるいは Expo Router のルート単位ローダーを選ぶべきかを判断したい開発者に、とりわけ有用です。

実際のジョブ・トゥ・ビー・ダン

多くのユーザーは、次の 4 つのいずれかを達成したいと考えています。

• 信頼性の高い API 連携をリリースしたい
• 壊れている、または不安定なネットワーク処理を直したい
• 画面やルートに合った無理のないデータ取得パターンを選びたい
• 設定、認証、ローダーまわりの Expo 特有の落とし穴を避けたい

こうした場面で native-data-fetching スキルは、リポジトリをざっと眺めるだけよりも実践的です。単なるコードスニペットではなく、ネットワーク処理を「実装上の意思決定」として捉えられるようにしてくれます。

主な差別化ポイントと制約

最大の特徴は、Expo の考え方に強く寄せたガイドである点です。ソースでは axios より expo/fetch を明確に推奨しており、基本的なリクエスト例だけでなく、キャッシュ、オフライン対応、トークン処理、Expo Router ローダーまで踏み込んでいます。さらに、useLoaderData と Expo web の server/static 実行モデル（SDK 55+）に関する要点もまとまっています。

一方で制約もあります。これは包括的なネットワークフレームワークではありません。あくまでガイダンスと実例をまとめたスキルドキュメントなので、得られる結果の質は、プロンプトの具体性や、アプリのアーキテクチャがどれだけ明確かに大きく左右されます。

native-data-fetching スキルの使い方

native-data-fetching の導入方法

Expo skills リポジトリからスキルをインストールします。

npx skills add https://github.com/expo/skills --skill native-data-fetching

インストール後は、まず次の 2 つを読むのがおすすめです。

• SKILL.md
• references/expo-router-loaders.md

この順番で読めば、最初に一般的なネットワーク実装の方針を把握でき、その後に Expo Router を使う web アプリ特有のローダーモデルを確認できます。

native-data-fetching を呼び出すべきタイミング

次のようなタスクを含むなら、native-data-fetching skill を使う価値があります。

• 外部 API を呼び出す
• フォームデータや JSON を POST する
• 認証ヘッダーやトークン更新ロジックを追加する
• タイムアウト、HTTP エラー、不正なレスポンスをデバッグする
• 素の fetch、React Query、SWR、ローダーのどれを使うか判断する
• オフライン時やキャッシュ時の挙動を扱う
• 環境ごとの API URL を設定する
• Expo Router でルート単位のデータ取得を実装する

ネットワーク状態、リクエストのライフサイクル、リモートデータの設計に関わるなら、不具合が出てからではなく、早い段階で native-data-fetching を使うほうが効果的です。

native-data-fetching に渡すべき入力情報

より精度の高い出力を得るには、次の情報を最初から渡してください。

• どの画面・ルート・機能を作るのか
• 実行対象は iOS、Android、web、またはそのすべてか
• リクエスト種別は GET、POST、更新フロー、ポーリング、プリロードなどのどれか
• API の詳細: エンドポイントの形、認証方式、期待レスポンス、エラー契約
• データにキャッシュ、再取得、リトライ、オフライン対応が必要か
• Expo Router、React Query、SWR、素の React state のどれを使っているか
• 既存アプリに環境設定や base URL のルールがあるか

こうした前提がない状態でもコード生成はできますが、誤ったデータ取得パターンを選ばれる可能性があります。

曖昧な依頼を強いプロンプトにする

弱いプロンプト:

Fetch user data for my screen.

より良いプロンプト:

Use native-data-fetching to implement a profile screen in an Expo app.
Target platforms: iOS and Android.
Need: authenticated GET /me request with Bearer token, loading state, 401 handling, retry on network failure, and stale data shown while refetching.
Current stack: Expo Router + React Query.
Return: recommended pattern, code, and where to place config for the API base URL.

後者のほうがうまく機能するのは、スキルが素の fetch ロジック、クエリライブラリ、ルート対応パターンのどれを選ぶべきか判断するための情報が十分に含まれているからです。

適切なデータ取得パターンの選び方

実務上は、次のように判断するとわかりやすいです。

• 単発のリクエストやシンプルな処理なら、素の fetch または expo/fetch
• キャッシュ無効化、バックグラウンド更新、重複リクエストの抑制が重要なら React Query または SWR
• Expo web で、描画前にルート側でデータを読み込みたいなら Expo Router loaders、特に SDK 55+ では有力

これは native-data-fetching guide の中でも特に価値の高い使い方です。実装に入る前に、「どのパターンを採用すべきか」を判断させる使い方ができます。

Expo Router loader を使うときの注意点

useLoaderData を使うなら、同梱されているリファレンスは必読です。Expo Router web における loader には、実行モデルが 2 つあります。

• 初回ページロード時はサーバー側で実行されることがある
• クライアントサイド遷移時は、ブラウザが HTTP 経由で loader データを取得する

この違いにより、リクエストコンテキスト、ホスティング、設定方法は "server" と "static" の出力モードで変わります。タスクに loader が関係するなら、少なくとも次の情報を含めてください。

• Expo SDK のバージョン
• web の出力モード
• headers / cookies / request へのアクセスが必要か
• どのようなホスティング構成か

これらがないと、生成された解決策が、実際の構成では使えない前提に立ってしまうことがあります。

時間を無駄にしないリポジトリの読み方

native-data-fetching usage を手早く確認したいなら、リポジトリを闇雲にたどるのではなく、次の順で見るのが効率的です。

1. SKILL.md で対象範囲と推奨方針を確認する
2. Expo Router のデータロードを使っているなら references/expo-router-loaders.md を読む
3. 自分のアプリ側の API client、auth utilities、environment config files を確認する

この upstream スキル自体は短く、読むこと自体は負担ではありません。実際のボトルネックになりやすいのは、今のアプリ構成にどう当てはめるかを正しく見極める部分です。

実装時の practical な進め方

おすすめの流れは次のとおりです。

1. まずパターン選定を相談する
2. 次に具体的なリクエスト層や hook を作る
3. エラー・ローディング・空状態を追加する
4. 認証と環境設定を組み込む
5. 失敗ケースをテストする
6. 必要なら最後にキャッシュやオフライン対応を強化する

この順番なら、過剰設計を避けやすくなります。多くのチームは、エンドポイント、認証、base URL の挙動確認が済む前に高度なキャッシュ戦略へ進みがちですが、それでは手戻りが増えます。

生成コードに影響する前提

ソースでは axios を避けて expo/fetch を優先するよう明示されています。したがって、あえて axios を要求する場合は、このスキルの基本方針に逆らうことになります。もしコードベース全体ですでに axios に統一しているなら、その前提を明確に伝えてください。そうすれば、既存スタックと衝突しない形に出力を寄せやすくなります。

最初に明示しておきたいリクエスト詳細

最初から実用的なドラフトを得たいなら、次の実装情報を含めるのが効果的です。

• JSON か multipart/form-data か
• 必須ヘッダーは何か
• トークンの取得元と更新挙動
• タイムアウトやリトライの期待値
• non-2xx レスポンスで JSON のエラーボディが返るか
• UI は待機するべきか、ストリーミングするか、古いデータを先に見せるか

こうした情報は、エンドポイントのパスそのもの以上に、実装の成否を左右することがよくあります。

native-data-fetching スキル FAQ

native-data-fetching は Expo アプリ専用ですか？

最も価値が高いのは Expo と React Native の文脈です。特に expo/fetch を推す方針や、Expo Router loader のリファレンスがあるためです。fetch の基本パターン自体は web 全般に通じる部分もありますが、このスキルは明確に Expo エコシステム向けに調整されています。

native-data-fetching は初心者でも使いやすいですか？

はい、ただし目的が具体的であることが前提です。どの画面で、どのエンドポイントを叩き、どう振る舞ってほしいのかを説明できれば、初心者でも native-data-fetching skill を十分活用できます。逆に、完全にオープンエンドな学習用途だと、実装やデバッグの前提が薄いため恩恵は小さくなります。

普通のコーディングプロンプトと何が違いますか？

一般的なプロンプトでも動く fetch コードは返ってくるかもしれませんが、expo/fetch を優先すること、適切なデータロードモデルを選ぶこと、Expo Router loader の挙動を踏まえることなど、エコシステム固有の判断を落としがちです。構文だけでなく、設計やフレームワーク適合性が重要な場面では、native-data-fetching guide のほうが適しています。

native-data-fetching を使うべきでないのはどんなときですか？

リモートデータと関係ない作業なら向いていません。たとえばローカル state だけの処理、UI スタイリング、アニメーション、データ取得を伴わないナビゲーションなどです。また、バックエンド API 全体の設計や高度なサーバー基盤設計が必要な場合も、このスキルの範囲を超えています。

React Query や SWR をすでに使っていても併用できますか？

はい。むしろ非常に相性の良いケースです。すでに使っているライブラリ名に加え、既存の query key、invalidatation 戦略、キャッシュルールを維持したいかどうかも伝えてください。データ層を丸ごと置き換えるより、今の構成を踏まえて補強する形のほうが、ガイダンスの価値は高まります。

native-data-fetching は Expo Router loaders を完全にカバーしていますか？

導入判断に必要な主要ポイントは押さえており、さらに焦点を絞ったリファレンスにもつながっています。ただし、すべてのエッジケースを網羅しているわけではありません。loader がアプリの中核なら、本番実装に入る前に references/expo-router-loaders.md を直接確認し、設定や実行詳細を把握しておくべきです。

native-data-fetching スキルをより良く使う方法

native-data-fetching にはエンドポイントだけでなく設計上の文脈も渡す

出力品質が最も大きく伸びるのは、リクエストがアプリ内のどこに属するのかを伝えたときです。

• component
• custom hook
• query layer
• route loader
• shared API client

ここが分かると、単発の断片的なコードではなく、今の構成に合った形で native-data-fetching が提案しやすくなります。

コードの前に意思決定をさせる

強い使い方のひとつは、次のように依頼することです。

Use native-data-fetching to choose the best approach for this feature.
Compare plain fetch vs React Query vs Expo Router loader for my constraints.
Then implement the winning option.

この流れなら、最初の出力が単なる生成コードではなく、設計判断になります。結果として手戻りを減らせます。

本当に気にしている failure mode を伝える

失敗時の扱いを指定しないと、楽観的なサンプルだけが返ってきやすくなります。次のような現実的な懸念を明示すると、結果は大きく改善します。

• 401 token expiry
• offline device
• slow connections
• duplicate requests on screen focus
• bad JSON payloads
• server 500s with error messages

こうした制約を入れることで、native-data-fetching は本番運用に近い出力へ寄っていきます。

よくある失敗: プラットフォーム前提が曖昧

質の低いネットワーク実装アドバイスは、native と web の前提を混同したときに起こりがちです。次の点は明確にしてください。

• native only
• web only
• universal app
• Expo Router web with loaders
• static export vs server rendering

これが重要なのは、loader の挙動、request context、hosting 制約が、これらの条件によって変わるからです。

よくある失敗: 設定と base URL の扱いが不明確

環境情報を省くと、生成コードが URL をベタ書きしたり、設定の置き場所を間違えたりしやすくなります。次の内容を渡してください。

• dev/staging/prod の base URL ルール
• すでに env vars があるか
• 現在 config がどこにあるか
• プラットフォームごとにリクエスト差分があるか

この情報があるだけで、実アプリでの native-data-fetching install 後の導入はかなりスムーズになります。

現実的なレスポンス契約を与えて出力品質を上げる

「ユーザーデータが返る」とだけ書くより、次のように具体化したほうが良いです。

GET /me returns 200 { id, name, avatarUrl }.
401 returns { error: "token_expired" }.
500 may return HTML from an upstream proxy.

このレベルで伝えると、パースやエラーハンドリングをより安全に組み立てやすくなります。特に不安定な API をデバッグするときに有効です。

最初の回答のあとに反復する

初回出力のあと、次のような追加依頼をすると精度が上がります。

• convert this to React Query
• adapt this to Expo Router loader usage
• add optimistic mutation handling
• refactor into a reusable API client
• harden error states for offline mode

最初の回答ではパターンを固め、その後のやり取りで実アプリの制約に合わせて仕上げていくのが理想です。

web レンダリングが重要なら loader リファレンスを読む

プロジェクトでルート単位のデータロードを使っているなら、最短で改善につながるのは references/expo-router-loaders.md を読み、その用語を使ってプロンプトを書くことです。たとえば useLoaderData、"server" と "static"、request access、hosting model などです。こうした語彙を使うだけで、曖昧に「描画前にデータを読みたい」と頼むより、native-data-fetching usage の出力はかなり鋭くなります。

native-data-fetching はネットワーク作業に絞って使う

このスキルは、プロンプトがリモートデータの課題に集中しているときに最も力を発揮します。ネットワーク処理、state 管理、UI 再設計、ナビゲーション変更を一度にまとめて依頼すると、出力は浅くなりがちです。まず native-data-fetching に API とデータ層をきれいに整理させ、その後で別の論点を進めるほうがうまくいきます。