native-data-fetching

Overview of native-data-fetching skill

What native-data-fetching actually helps with

The native-data-fetching skill is an Expo-focused guide for implementing and debugging network requests in React Native and Expo apps. It is most useful when you need more than a generic “write a fetch call” prompt: API requests, auth headers, caching decisions, offline behavior, environment-specific base URLs, and Expo Router data loaders all sit in scope.

Best fit for Frontend Development teams

native-data-fetching for Frontend Development is a strong fit if you are building mobile or Expo web features that depend on remote data and you want conventions that match the Expo ecosystem. It is especially relevant for developers choosing between plain fetch, a data library like React Query or SWR, and route-level loaders in Expo Router.

Real job-to-be-done

Users are usually trying to do one of four things:

• ship a reliable API integration
• fix a broken or flaky network flow
• choose a sane fetching pattern for a screen or route
• avoid common Expo-specific mistakes around config, auth, and loaders

This is where the native-data-fetching skill is more useful than a shallow repo skim: it frames networking as an implementation decision, not just a code snippet.

Key differentiators and constraints

The main differentiator is opinionated Expo alignment. The source explicitly prefers expo/fetch over axios, and it extends beyond basic requests into caching, offline support, token handling, and Expo Router loaders. It also includes a focused reference on useLoaderData and the server/static execution model for Expo web in SDK 55+.

The main constraint: this is not a full networking framework. It is a skill document with guidance and examples, so results depend heavily on the quality of the prompt and on whether your app architecture is already clear.

How to Use native-data-fetching skill

native-data-fetching install context

Install the skill from the Expo skills repository:

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

After install, read these first:

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

That reading order gets you the general networking guidance first, then the special-case loader model for Expo Router web apps.

When to invoke native-data-fetching skill

Use the native-data-fetching skill any time the task includes:

• calling an external API
• posting form or JSON data
• adding auth headers or token refresh logic
• debugging timeouts, HTTP errors, or malformed responses
• choosing between plain fetch, React Query, SWR, or loaders
• handling offline/cache behavior
• configuring environment-based API URLs
• implementing Expo Router route-level data loading

If the task touches network state, request lifecycles, or remote data architecture, invoke it early instead of after bugs appear.

What input the skill needs from you

You will get better output if you provide:

• the screen, route, or feature being built
• the runtime target: iOS, Android, web, or all three
• the request type: GET, POST, mutation flow, polling, preload, etc.
• API details: endpoint shape, auth model, expected response, error contract
• whether data must be cached, refreshed, retried, or work offline
• whether you use Expo Router, React Query, SWR, or plain React state
• any environment config or base URL rules already in the app

Without that context, the skill can still generate code, but it may choose the wrong fetching pattern.

Turn a rough goal into a strong prompt

Weak prompt:

Fetch user data for my screen.

Stronger 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.

The stronger version works better because it gives the skill enough information to choose between direct fetch logic, a query library, and route-aware patterns.

Choosing the right fetching pattern

A practical decision path:

• Use plain fetch or expo/fetch for one-off requests and simple flows.
• Use React Query or SWR when cache invalidation, background refresh, and request deduplication matter.
• Use Expo Router loaders when the route should load data before render on Expo web, especially in SDK 55+.

This is one of the highest-value uses of the native-data-fetching guide: asking it to recommend a pattern before implementation.

Expo Router loader usage caveat

The included reference matters if you are using useLoaderData. Loaders in Expo Router web have a dual execution model:

• on initial page load, they can run server-side
• on client-side navigation, the browser fetches loader data over HTTP

That means request context, hosting, and configuration differ between "server" and "static" output modes. If your task mentions loaders, include:

• Expo SDK version
• web output mode
• whether you need headers/cookies/request access
• hosting model

Otherwise the generated solution may assume capabilities your setup does not have.

Repository reading path that saves time

For a fast native-data-fetching usage review, do not browse the repo randomly. Use this path:

1. SKILL.md for scope and preferences
2. references/expo-router-loaders.md if your app uses Expo Router data loading
3. your own app's API client, auth utilities, and environment config files

The upstream skill is short enough that the bottleneck is usually not reading it, but mapping it correctly to your current app architecture.

Practical workflow for implementation

A good workflow is:

1. ask for a pattern recommendation
2. ask for the concrete request layer or hook
3. add error/loading/empty states
4. add auth and environment handling
5. test failure cases
6. only then add cache/offline improvements if needed

This avoids overengineering. Many teams jump straight to advanced caching before confirming the endpoint, auth, and base URL behavior all work.

Preferences that affect generated code

The source explicitly says to avoid axios and prefer expo/fetch. If you ask for axios anyway, you are going against the skill's stated preference. If your codebase already standardizes on axios, mention that clearly so the output can adapt instead of fighting your stack.

Common request details to specify up front

To get a usable first draft, include these implementation details:

• JSON vs multipart/form-data
• required headers
• token source and refresh behavior
• timeout or retry expectations
• whether non-2xx responses return JSON error bodies
• whether the UI should block, stream, or render stale data first

These details often matter more than the endpoint path itself.

native-data-fetching skill FAQ

Is native-data-fetching only for Expo apps?

It is most valuable in Expo and React Native contexts, especially because of the expo/fetch preference and the Expo Router loader reference. Some fetch patterns are general web knowledge, but the skill is clearly tuned for the Expo ecosystem.

Is native-data-fetching beginner friendly?

Yes, if your goal is concrete. Beginners can use the native-data-fetching skill well when they describe the screen, endpoint, and expected behavior. It is less helpful for totally open-ended learning because it assumes you are actively implementing or debugging something.

How is this different from a normal coding prompt?

A generic prompt may return working fetch code but miss ecosystem-specific choices, such as preferring expo/fetch, using the right data-loading model, or accounting for Expo Router loader behavior. The native-data-fetching guide is better when architecture and framework fit matter as much as syntax.

When should I not use native-data-fetching?

Do not reach for it if your task is unrelated to remote data, such as local-only state, UI styling, animations, or navigation that does not fetch anything. Also, if you need a full backend API design or advanced server infrastructure plan, this skill is too narrow.

Should I use it with React Query or SWR already in place?

Yes. In fact, that is a strong use case. Tell the skill which library you already use and whether you want to preserve existing query keys, invalidation strategy, and cache rules. The guidance is more useful when it extends your current data layer instead of replacing it.

Does native-data-fetching cover Expo Router loaders fully?

It covers the important adoption decision points and links to a focused reference, but not every edge case. If loaders are central to your app, inspect references/expo-router-loaders.md directly for configuration and execution details before you implement production behavior.

How to Improve native-data-fetching skill

Give native-data-fetching architectural context, not just endpoints

The biggest quality jump comes from telling the skill where the request lives in your app:

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

That lets it produce code that matches your structure instead of a disconnected snippet.

Ask for decisions before code

A strong pattern is:

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.

This reduces rework because the first output becomes a design decision, not just generated code.

Include failure modes you actually care about

If you do not mention failure handling, you often get optimistic examples only. Improve results by naming real concerns:

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

Those constraints push the skill toward production-grade output.

Common failure mode: vague platform assumptions

A lot of bad networking advice comes from mixing native and web assumptions. Be explicit about:

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

This matters because loader behavior, request context, and hosting constraints change across those setups.

Common failure mode: unclear config and base URL handling

If you omit environment details, generated code may hardcode URLs or place config in the wrong layer. Provide:

• dev/staging/prod base URL rules
• whether env vars already exist
• where config lives now
• whether requests differ by platform

That makes the native-data-fetching install and adoption path much smoother in a real app.

Improve output quality with realistic response contracts

Better than saying “returns user data”:

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

This helps the skill generate safer parsing and error handling, which is especially useful when debugging unstable APIs.

Iterate after the first answer

After the initial output, ask follow-ups like:

• 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

The first answer should establish the pattern; later turns should align it with your app's real constraints.

Read the loader reference when web rendering matters

If your project uses route-level data loading, the fastest improvement is to read references/expo-router-loaders.md and then prompt with its terminology: useLoaderData, "server" vs "static", request access, and hosting model. That produces much sharper native-data-fetching usage output than a generic “load data before render” request.

Keep native-data-fetching focused on networking work

The skill performs best when the prompt stays centered on remote data concerns. If you combine networking, state management, UI redesign, and navigation restructuring in one request, the result usually becomes shallow. Split the work so native-data-fetching handles the API and data layer cleanly first.