native-data-fetching

native-data-fetching 技能總覽

native-data-fetching 實際能幫上什麼

native-data-fetching 是一份以 Expo 為核心的指南，專門協助你在 React Native 與 Expo app 中實作及除錯網路請求。當你的需求不只是泛泛的「寫一個 fetch call」提示時，它特別有價值：像是 API 請求、auth headers、快取策略、離線行為、依環境切換的 base URL，以及 Expo Router 的資料載入器，都在它的處理範圍內。

最適合 Frontend Development 團隊的情境

如果你正在開發依賴遠端資料的行動端功能，或是 Expo web 功能，並希望採用符合 Expo 生態的慣例，那麼 native-data-fetching for Frontend Development 會很合適。對於正在評估該用單純的 fetch、像 React Query 或 SWR 這類資料層套件，或是 Expo Router 路由層 loader 的開發者來說，尤其實用。

真正要解決的工作任務

使用者通常是想完成以下四種事情之一：

• 上線一個可靠的 API 整合
• 修好壞掉或不穩定的網路流程
• 為某個畫面或路由選定合理的 fetching 模式
• 避開 Expo 在 config、auth 與 loaders 上常見的坑

這也是 native-data-fetching 比起草草瀏覽 repo 更有價值的地方：它把 networking 視為實作決策，而不只是給你一段程式碼片段。

關鍵差異與限制

它最大的差異點在於對 Expo 的明確對齊。原始內容明確偏好 expo/fetch 而不是 axios，而且涵蓋的不只是基本請求，還延伸到快取、離線支援、token 處理，以及 Expo Router loaders。它也提供了聚焦的參考文件，說明 useLoaderData 與 Expo web 在 SDK 55+ 的 server/static 執行模型。

主要限制是：這不是一套完整的 networking framework。它本質上是一份帶有建議與範例的 skill 文件，因此輸出效果很大程度取決於你的 prompt 品質，以及你的 app 架構是否已經足夠清楚。

如何使用 native-data-fetching 技能

native-data-fetching 的安裝情境

從 Expo skills repository 安裝這個 skill：

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

安裝後，先讀這兩個檔案：

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

這樣的閱讀順序會先讓你掌握一般 networking 指引，再補上 Expo Router web apps 的特殊 loader 模型。

什麼時候該啟用 native-data-fetching 技能

只要任務包含以下內容，就該使用 native-data-fetching skill：

• 呼叫外部 API
• 送出表單或 JSON 資料
• 加上 auth headers 或 token refresh 邏輯
• 除錯 timeout、HTTP errors 或 malformed responses
• 在 plain fetch、React Query、SWR 或 loaders 之間做選擇
• 處理 offline/cache 行為
• 設定依環境切換的 API URL
• 實作 Expo Router 路由層級的資料載入

如果任務牽涉到 network state、request lifecycle 或遠端資料架構，最好一開始就啟用，而不是等到 bug 出現後才補救。

這個 skill 需要你提供哪些輸入

如果你提供以下資訊，輸出通常會更好：

• 正在開發的 screen、route 或 feature
• 執行目標：iOS、Android、web，或三者皆有
• 請求類型：GET、POST、mutation flow、polling、preload 等
• API 細節：endpoint 型態、auth 模式、預期回應、錯誤契約
• 資料是否需要快取、refresh、retry，或支援離線
• 你是否使用 Expo Router、React Query、SWR，或單純的 React state
• app 內現有的 environment config 或 base URL 規則

如果缺少這些背景，這個 skill 仍然能產生程式碼，但可能會選錯 fetching 模式。

把模糊目標變成高品質 prompt

弱的 prompt：

Fetch user data for my screen.

更強的 prompt：

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.

後者效果更好，因為它提供了足夠資訊，讓 skill 能在直接寫 fetch、使用 query library，或採用 route-aware 模式之間做正確判斷。

如何選擇正確的 fetching 模式

一條實用的判斷路徑如下：

• 一次性請求與簡單流程，使用 plain fetch 或 expo/fetch
• 如果在意 cache invalidation、背景 refresh 與 request deduplication，使用 React Query 或 SWR
• 如果希望 route 在 Expo web 上 render 前就先載入資料，特別是在 SDK 55+，使用 Expo Router loaders

這也是 native-data-fetching guide 最有價值的用法之一：先請它推薦模式，再開始實作。

使用 Expo Router loader 的注意事項

如果你有使用 useLoaderData，附帶的參考文件就很重要。Expo Router web 裡的 loaders 採用雙重執行模型：

• 初次頁面載入時，可能會在 server side 執行
• 在 client-side navigation 時，瀏覽器會透過 HTTP 抓取 loader data

這代表請求上下文、hosting 與設定方式，會依 "server" 和 "static" 輸出模式而不同。如果你的任務提到 loaders，請一併提供：

• Expo SDK 版本
• web output mode
• 是否需要 headers/cookies/request access
• hosting model

否則產生出的方案，可能會假設你的環境具備實際上沒有的能力。

節省時間的 repository 閱讀路徑

如果你想快速完成 native-data-fetching usage 檢視，不要在 repo 裡亂逛。建議照這條路徑讀：

1. SKILL.md：先看範圍與偏好
2. references/expo-router-loaders.md：如果你的 app 有用 Expo Router data loading，就接著看
3. 你自己 app 裡的 API client、auth utilities 與 environment config 檔案

這個上游 skill 本身不長，真正的瓶頸通常不是讀它，而是如何正確對應到你現有的 app 架構。

實作時的實用工作流程

一個好用的流程是：

1. 先請它推薦模式
2. 再請它產出具體的 request layer 或 hook
3. 補上 error/loading/empty states
4. 加入 auth 與 environment handling
5. 測試失敗情境
6. 確認有需要時，再補快取與離線強化

這樣可以避免過度設計。很多團隊會太早跳進進階快取，卻還沒確認 endpoint、auth 與 base URL 的行為都正常。

會影響產生程式碼的偏好設定

原始內容明確指出應避免 axios，並優先使用 expo/fetch。如果你還是要求 axios，等於是在逆著這個 skill 的既定偏好走。若你的 codebase 已經全面標準化為 axios，請清楚說明，這樣輸出才會配合你的 stack，而不是和它衝突。

一開始就該講清楚的常見請求細節

想拿到可直接使用的第一版，建議一開始就提供這些實作細節：

• JSON 還是 multipart/form-data
• 必要 headers
• token 來源與 refresh 行為
• timeout 或 retry 預期
• 非 2xx 回應是否會回傳 JSON error body
• UI 應該 block、stream，或先顯示 stale data

很多時候，這些細節比 endpoint path 本身更重要。

native-data-fetching 技能 FAQ

native-data-fetching 只適用於 Expo app 嗎？

它在 Expo 與 React Native 情境下最有價值，特別是因為它偏好 expo/fetch，也包含 Expo Router loader 的參考內容。有些 fetch 模式屬於通用 web 知識，但整體來說，這個 skill 明顯是針對 Expo 生態調整過的。

native-data-fetching 對新手友善嗎？

是的，前提是你的目標夠具體。只要你能描述 screen、endpoint 與預期行為，新手也能把 native-data-fetching skill 用得很好。若只是非常開放式地想學 networking，它的幫助就比較有限，因為它預設你正在實作或除錯某個具體功能。

它和一般 coding prompt 有什麼不同？

一般 prompt 也許能回你一段能跑的 fetch 程式碼，但常會漏掉生態系特有的選擇，例如優先使用 expo/fetch、選對資料載入模型，或正確處理 Expo Router loader 的行為。當架構選型與 framework 相容性和語法本身同樣重要時，native-data-fetching guide 會更適合。

什麼情況下不該使用 native-data-fetching？

如果你的任務和遠端資料無關，例如只處理本地 state、UI styling、animations，或完全不涉及 fetch 的 navigation，就不需要用它。另外，如果你需要的是完整的 backend API 設計，或進階的 server infrastructure 規劃，這個 skill 的範圍就太窄了。

已經有 React Query 或 SWR 時還值得搭配使用嗎？

值得，而且這正是它很強的使用情境。告訴 skill 你目前使用哪個 library，以及是否要保留既有的 query keys、invalidation strategy 與 cache 規則。當它是在延伸你現有的 data layer，而不是整個推翻重做時，建議通常更有用。

native-data-fetching 真的有完整涵蓋 Expo Router loaders 嗎？

它有涵蓋採用時最重要的決策點，也有連到聚焦的參考文件，但不是所有 edge case 都會講到。如果 loaders 是你 app 的核心，正式實作 production 行為前，請直接檢查 references/expo-router-loaders.md 裡的設定與執行細節。

如何改善 native-data-fetching 技能的使用效果

提供 native-data-fetching 架構脈絡，而不只是 endpoints

品質提升幅度最大的做法，是告訴這個 skill：這個 request 在你的 app 裡究竟放在哪一層：

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

這樣它才能產出符合你結構的程式碼，而不是一段孤立的 snippet。

先問決策，再問程式碼

一個很強的提問模式是：

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 modes 講清楚

如果你不提失敗處理，最後常只會拿到樂觀路徑的範例。想改善結果，請直接點出真實顧慮：

• 401 token expiry
• 裝置離線
• 連線緩慢
• screen focus 時重複發 request
• 壞掉的 JSON payload
• 帶錯誤訊息的 server 500

這些限制會把 skill 推向更接近 production-grade 的輸出。

常見失敗模式：平台假設太模糊

很多不好的 networking 建議，都是因為混淆了 native 與 web 的前提。請明確說清楚：

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

這很重要，因為不同 setup 下的 loader 行為、request context 與 hosting 限制都不一樣。

常見失敗模式：config 與 base URL 處理不清楚

如果你沒提供環境細節，產生出的程式碼很可能會把 URL 寫死，或把 config 放錯層。請提供：

• dev/staging/prod 的 base URL 規則
• 是否已經有 env vars
• 現在的 config 放在哪裡
• request 是否會依平台不同而不同

這會讓真實 app 中的 native-data-fetching install 與導入流程順利很多。

用真實的 response contract 提升輸出品質

比起只說「會回 user data」，更好的描述是：

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

這能幫助 skill 產出更安全的 parsing 與 error handling，對於除錯不穩定 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

第一輪回答應該先建立模式；後續回合再逐步對齊你 app 的真實限制。

當 web rendering 很重要時，先讀 loader reference

如果你的專案使用 route-level data loading，最快的提升方式就是先讀 references/expo-router-loaders.md，然後在 prompt 中直接使用裡面的術語：useLoaderData、"server" vs "static"、request access，以及 hosting model。這比起只說一句籠統的「render 前先載入資料」，更能得到精準得多的 native-data-fetching usage 輸出。

讓 native-data-fetching 聚焦在 networking 工作本身

當 prompt 聚焦在遠端資料議題時，這個 skill 表現最好。如果你把 networking、state management、UI redesign 與 navigation restructuring 全塞進同一個請求，結果通常會變得很淺。最好把工作拆開，先讓 native-data-fetching 把 API 與 data layer 處理乾淨。