con un clic
frontend-api-layer
Provides patterns for structuring the API layer in React applications. This skill should be used when setting up API clients, defining API request declarations, or integrating with TanStack Query for data fetching.
Menú
Provides patterns for structuring the API layer in React applications. This skill should be used when setting up API clients, defining API request declarations, or integrating with TanStack Query for data fetching.
| name | frontend-api-layer |
| description | Provides patterns for structuring the API layer in React applications. This skill should be used when setting up API clients, defining API request declarations, or integrating with TanStack Query for data fetching. |
Patterns for the API layer in React applications using TanStack Query and type-safe API clients.
See references/api-layer-examples.md for full code examples.
Component → TanStack Query Hook → API Declaration → API Client → Backend
{feature}/api/*.api.ts files@eridu/api-typeslistPrefix + listtarget_type/target_id filters, not deeply nested paths mirroring component placement.{ signal } from queryFn context and forward to API fetchers.export const taskTemplateKeys = {
all: ['task-templates'] as const,
lists: () => [...taskTemplateKeys.all, 'list'] as const,
listPrefix: (studioId: string) => [...taskTemplateKeys.lists(), studioId] as const,
list: (studioId: string, filters?: unknown) => [...taskTemplateKeys.listPrefix(studioId), filters] as const,
detail: (id: string) => [...taskTemplateKeys.all, 'detail', id] as const,
};
listPrefix for mutation invalidation (clears ALL filter combos for a scope)list(...) in queryKey for useQuery/useInfiniteQueryuseMemo when used outside queryKey optionlistPrefix, not exact list keysetQueriesData for immediate UI, then invalidateQueriessilent?: boolean to variables, guard invalidation with if (!variables.silent), set meta: { suppressErrorToast: true }studioId ?? 'admin') for dual-scope helpersuseSearchQuery helper when 2+ lookup hooks exist in same fileonSearch wiring = broken implementation, not acceptable placeholderloader: ({ context: { queryClient }, params: { studioId } }) => {
void queryClient.prefetchQuery({ queryKey, queryFn });
},
void prefetchQuery (non-blocking), not await ensureQueryDatauseQuery calls| Tier | Stale time | Example |
|---|---|---|
| Interactive (default) | ~20s | List/detail navigation |
| Operational | ~5s | /me/* task/shift views |
| Lookup/reference | ~1h | Static reference data |
{feature}/api/*.api.tslistPrefix@eridu/api-typessignal forwarded to API fetcherslistPrefix, not exact keyPatterns for auditing and improving erify_api query performance and response efficiency. Use when detecting N+1 queries, reducing over-fetching, designing lean select/include strategies, replacing in-memory joins with DB aggregations, adding pagination guards, or defining API performance baselines before scaling. Complements database-patterns which covers the basic N+1 and Promise.all rules.
Frontend data compatibility and fallback patterns for API contract migrations. Use when building UI that must handle both old and new API response shapes during a cutover, or when centralizing field-access helpers for dual-field responses.
Enforces repo-aligned engineering best practices for review and refactoring. This skill should be used when auditing or refactoring code across eridu-services with priority on local architecture/context, then official framework docs, then principles such as SOLID.
Enforces the Zod-based environment configuration pattern. Use this skill when reading, adding, or modifying environment variables (e.g., process.env or import.meta.env). Outlines how to define a central Zod schema, infer strict types, enforce defaults, and gracefully crash on missing required keys.
Provides comprehensive testing strategies and patterns for React applications. This skill should be used when writing tests, setting up testing infrastructure, or deciding what to test.
Find deepening opportunities in a codebase, informed by the domain language in CONTEXT.md and the decisions in docs/adr/. Use when the user wants to improve architecture, find refactoring opportunities, consolidate tightly-coupled modules, or make a codebase more testable and AI-navigable.