Data
Data for an Expo app, compared: TanStack Query, Apollo Client, SWR, or none - Expo Go support and what each option installs.
Hey - here's how data works in ReadyNative. This category picks how your app talks to a backend: the client, the cache, retries and refetch-on-foreground, all behind a provider that setup registers for you.
Whichever option you pick, the shape is the same: a provider in src/lib/ at order 20, one hook
per query under src/hooks/ (with --with-examples, the /examples/query route to copy from), and a single
EXPO_PUBLIC_* base URL in .env. The REST options share src/lib/api/client.ts (fetchJson)
byte for byte, so moving between them doesn't churn your API code. Swap with
bun run setup --data <option>.
- react-query - the default. Reach for it when you want mutations, invalidation and real cache control over a REST API.
- swr - the same job with a much smaller surface: a string key is a request. Good when you mostly read.
- apollo - pick it when your backend speaks GraphQL.
- none - no client at all; call
fetchyourself or bring your own.
Options
One option per category - --data <option> picks it:
bun run setup --data react-query| Option | Label | Expo Go | Hint |
|---|---|---|---|
react-query | TanStack Query (default) | yes | server state + cache · Expo Go OK |
apollo | Apollo Client | yes | GraphQL client + normalized cache · Expo Go OK |
swr | SWR | yes | stale-while-revalidate hooks · Expo Go OK |
none | No data layer | yes | plain fetch; add TanStack Query/Apollo/SWR later |