Client-side data fetching

Core Idea

Decida entre use() com uma Promise única (sem revalidação client-side), ou uma lib de cache client (SWR/TanStack Query/Apollo) quando Client Components precisam de cache compartilhado no browser com revalidação por foco, polling, dedupe ou updates otimistas.

Key Concepts

• use() + Promise: para dado lido uma vez, sem necessidade de revalidação no client; evita adicionar lib.
• Inline loading state: useSWR/useQuery, cada componente renderiza seu próprio loading/error.
• Suspense loading state: useSWR({suspense:true})/useSuspenseQuery, loading definido num boundary compartilhado.
• Server-provided fallback: <SWRConfig fallback>/<HydrationBoundary>, dado disponível no render inicial ou via streaming.
• Next.js server cache: cache de dados/RSC output no servidor, controlado por cacheLife (revalidate, expire).
• Next.js client cache: cache de payloads RSC de rotas visitadas/prefetched, controlado por cacheLife stale.
• updateTag(tag): invalida e força o próximo read a esperar dado fresco, use quando Server Action precisa refletir a mudança imediatamente.
• revalidateTag(tag, 'max'): serve stale enquanto revalida em background, para updates passivos.
• revalidateTag(tag, {expire:0}): expira imediatamente, para webhook/sistema externo.

Reference Tables

Pattern	SWR	TanStack Query	Quando o dado fica disponível
Inline loading	useSWR	useQuery	Requisição no browser após hidratação
Suspense loading	useSWR({suspense:true})	useSuspenseQuery	Requisição no browser após hidratação
Fornecido pelo servidor	<SWRConfig fallback>	<HydrationBoundary>	Render inicial ou streamed do servidor

Layer	O que guarda	Controle de freshness
Next.js server cache	Dados cacheados e output de Server Component	cacheLife revalidate/expire
Next.js client cache	Payloads RSC de rotas visitadas/prefetched	cacheLife stale
Lib client de fetch	Dado do browser sob key SWR/TanStack	Opções de revalidação/mutation da própria lib

Key Takeaways

1. Sem necessidade de cache compartilhado no browser, prefira use() a adicionar uma lib.
2. Suspense coordena o render; a lib e a estrutura de componentes decidem quando a requisição começa.
3. Cada camada de cache (server, client Next.js, lib) tem política de freshness independente; identidades de cache e invalidação de mutation precisam ficar coordenadas manualmente entre elas.
4. Após mutation, invalide o server read cacheado que forneceu o dado inicial; se o read não é cacheado, não há tag para invalidar.
5. Update otimista deve reverter o valor anterior se o write falhar.

Connects To

• ch032 SWR / ch033 TanStack Query: implementações concretas dos padrões descritos aqui.
• use cache / cacheTag / cacheLife: mecanismo de cache server usado para coordenar com o cache client.