Mobile Server State
Purpose
Plan how the app fetches and caches server data: choose RTK Query or TanStack Query and define queries, mutations, caching/invalidation, retries, and offline/refetch behavior.
When to Use
- When the app reads/writes server data (most apps).
- When server data is being stored manually in Redux/Zustand.
- Not for purely local/client state (
mobile-state-management).
Inputs
- The API surface (
mobile-api-integration) and data needs.
- Approved stack (RTK Query vs TanStack Query).
Discovery Questions
- RTK Query (if using Redux Toolkit) or TanStack Query?
- What are the cache keys, invalidation triggers, and staleness needs?
- What retry/backoff and offline behavior are required?
- Any optimistic updates needed?
Responsibilities
- Choose RTK Query or TanStack Query aligned to the stack.
- Define queries/mutations, cache keys, and invalidation.
- Plan retries/backoff, stale-while-revalidate, and offline behavior.
- Keep server state separate from client state; support optimistic updates where useful.
Required Workflow
- Map the API surface to queries/mutations.
- Choose the cache library.
- Define keys, invalidation, staleness.
- Plan retries/offline/optimistic behavior.
- Record the server-state plan.
Decision Rules
- RTK Query pairs naturally with Redux Toolkit; TanStack Query is store-agnostic — choose by stack fit.
- Server data belongs in the cache library, never hand-rolled in a client store.
- Invalidate by cache key on mutation; avoid manual refetch spaghetti.
Rules
- Separate server and client state.
- Align with the approved data-fetching tool.
- Coordinate the transport with
mobile-api-integration.
Anti-Patterns
- Storing server data manually in Redux/Zustand.
- No invalidation strategy (stale data).
- Ignoring offline/retry for a mobile network.
- Refetching everything on every change.
Validation Checklist
Definition of Done
A recorded server-state plan: chosen cache library, queries/mutations with keys and invalidation, retry/offline/optimistic behavior — with server data kept out of client stores.
Related Skills
mobile-api-integration, mobile-state-management, mobile-error-handling, mobile-environment-config, ../../stack-recommendation
Related Knowledge
../../../knowledge/ (API contracts, data model).
Related References
../../../references/mobile/state/ when populated.
Context Loading Guidance
- Requires: API surface, data needs, approved fetching tool.
- Does not require: the whole app source, unrelated references, every mobile skill.
- May load:
mobile-api-integration for the transport.
- Stop when: the server-state plan is recorded.
Token Efficiency Guidance
Work from the API surface summary; delegate transport to api-integration and client state to state-management.
1---2name: mobile-server-state3description: Use to plan server-state caching for mobile — RTK Query or TanStack Query — for fetching, caching, invalidation, retries, and offline behavior. Keeps server data out of client stores.4---56# Mobile Server State78## Purpose910Plan how the app fetches and caches server data: choose RTK Query or TanStack Query and define queries, mutations, caching/invalidation, retries, and offline/refetch behavior.1112## When to Use1314- When the app reads/writes server data (most apps).15- When server data is being stored manually in Redux/Zustand.16- Not for purely local/client state (`mobile-state-management`).1718## Inputs1920- The API surface (`mobile-api-integration`) and data needs.21- Approved stack (RTK Query vs TanStack Query).2223## Discovery Questions2425- RTK Query (if using Redux Toolkit) or TanStack Query?26- What are the cache keys, invalidation triggers, and staleness needs?27- What retry/backoff and offline behavior are required?28- Any optimistic updates needed?2930## Responsibilities3132- Choose **RTK Query** or **TanStack Query** aligned to the stack.33- Define **queries/mutations**, **cache keys**, and **invalidation**.34- Plan **retries/backoff**, **stale-while-revalidate**, and **offline** behavior.35- Keep **server state separate** from client state; support optimistic updates where useful.3637## Required Workflow38391. Map the API surface to queries/mutations.402. Choose the cache library.413. Define keys, invalidation, staleness.424. Plan retries/offline/optimistic behavior.435. Record the server-state plan.4445## Decision Rules4647- RTK Query pairs naturally with Redux Toolkit; TanStack Query is store-agnostic — choose by stack fit.48- Server data belongs in the cache library, never hand-rolled in a client store.49- Invalidate by cache key on mutation; avoid manual refetch spaghetti.5051## Rules5253- Separate server and client state.54- Align with the approved data-fetching tool.55- Coordinate the transport with `mobile-api-integration`.5657## Anti-Patterns5859- Storing server data manually in Redux/Zustand.60- No invalidation strategy (stale data).61- Ignoring offline/retry for a mobile network.62- Refetching everything on every change.6364## Validation Checklist6566- [ ] Cache library chosen + stack-aligned.67- [ ] Queries/mutations + keys defined.68- [ ] Invalidation strategy defined.69- [ ] Retry/offline/optimistic behavior planned.70- [ ] Server state kept out of client stores.7172## Definition of Done7374A recorded server-state plan: chosen cache library, queries/mutations with keys and invalidation, retry/offline/optimistic behavior — with server data kept out of client stores.7576## Related Skills7778`mobile-api-integration`, `mobile-state-management`, `mobile-error-handling`, `mobile-environment-config`, `../../stack-recommendation`7980## Related Knowledge8182`../../../knowledge/` (API contracts, data model).8384## Related References8586`../../../references/mobile/state/` when populated.8788## Context Loading Guidance8990- **Requires:** API surface, data needs, approved fetching tool.91- **Does not require:** the whole app source, unrelated references, every mobile skill.92- **May load:** `mobile-api-integration` for the transport.93- **Stop when:** the server-state plan is recorded.9495## Token Efficiency Guidance9697Work from the API surface summary; delegate transport to api-integration and client state to state-management.
ahtishamshahzad