state/server-state-cache

Dlaczego

Each hand-written fetch + useState + isLoading block re-implements caching, deduplication, race handling, retries and refetching, usually only partly. Two components that need the same data request it twice, the page renders a spinner where server rendering could have sent the content, and requests run one after another (waterfalls).

Poprawka

Use what the stack provides: Server Components or route loaders (Next.js, React Router), load (SvelteKit), useFetch/useAsyncData (Nuxt), httpResource or resolvers (Angular); in a client-only app, TanStack Query, SWR or RTK Query. Start independent requests together. Keep a raw fetch for event handlers (submitting a form) and for code outside components.

Przykłady

// bad: every page repeats this
const [user, setUser] = useState(null)
const [loading, setLoading] = useState(true)
useEffect(() => { getUser(id).then(setUser).finally(() => setLoading(false)) }, [id])
// good
const { data: user, error, isPending } = useQuery({ queryKey: ['user', id], queryFn: () => getUser(id) })

Źródła

• React docs, You Might Not Need an Effect (fetching data)
• Next.js docs, Fetching Data
• Nuxt docs, Data Fetching
• SvelteKit docs, Loading data
• Angular docs, Reactive data fetching with httpResource

Przeczytaj w terminalu

npx github:dawidolko/frontend-skills explain state/server-state-cache