Data Fetching Patterns

// the useEffect fetch, done as right as it can be, and why it is still wrong
function Post({ id }) {
  const [post, setPost] = useState(null); const [error, setError] = useState(null)
  useEffect(() => {
    const ac = new AbortController()                              // cancel on id change or unmount: prevents the late-response race
    setPost(null)                                                 // reset for the new id (or the old post shows under the new id)
    fetch(`/api/posts/${id}`, { signal: ac.signal }).then(r => r.ok ? r.json() : Promise.reject(r)).then(setPost).catch(e => { if (e.name !== 'AbortError') setError(e) })
    return () => ac.abort()
  }, [id])
  if (error) return <Err />; if (!post) return <Spinner />; return <Article post={post} />
}
// correct, and: no cache (remount refetches), no dedupe (two Posts fetch twice), no background refresh, no retry, a waterfall if nested,
// Strict Mode double-mount fetches twice in dev (the abort handles it, which is the point of Strict Mode), and 12 lines per resource.
// the query-cache version: const { data: post, error, isPending } = useQuery({ queryKey: ['post', id], queryFn: ({ signal }) => api.post(id, { signal }) })
// the server-component version: const post = await db.posts.find(id)   (no effect, no state, no loading flag: the boundary is the loading UI)

// the patterns, in the order they should be reached for
// 1. route-level loading (render-as-you-fetch): the router starts every request for the route at navigation; components read results
const router = createBrowserRouter([{ path: '/posts/:id', loader: ({ params }) => Promise.all([api.post(params.id), api.comments(params.id)]), element: <Post /> }])
// 2. deferred data: critical data awaited in the loader; secondary data returned as a promise and read with <Await> / use() under a Suspense boundary
loader: ({ params }) => ({ post: await api.post(params.id), comments: api.comments(params.id) })   // comments streams in after the post renders
// 3. prefetch: on link hover or in-viewport, start the next route's loader (or queryClient.prefetchQuery) so navigation finds the cache warm
<Link to={`/posts/${id}`} prefetch="intent" />
// 4. pagination and infinite: useInfiniteQuery with getNextPageParam; keepPreviousData / placeholderData for a stable list during page changes
// 5. polling and realtime: refetchInterval for cheap freshness; a websocket that writes into the cache (setQueryData) for push; invalidate on reconnect
// 6. dependent queries: enabled: !!userId, so the second starts when the first's result exists; still a waterfall unless the API embeds
// 7. mutations with optimistic updates (the figure) and invalidation (above)
// what to avoid: fetching in components that are deep in the tree with no boundary above them; fetching the same resource under different keys;
// storing server data in a reducer after fetching it (two caches); useEffect fetches for anything the route could have loaded

// invalidation: the three questions after a mutation
const qc = useQueryClient()
const createComment = useMutation({
  mutationFn: api.comments.create,
  onSuccess: (newComment, vars) => {
    qc.invalidateQueries({ queryKey: ['comments', vars.postId] })           // 1. what lists contain it? refetch them (or setQueryData to append)
    qc.setQueryData(['post', vars.postId], old => ({ ...old, commentCount: old.commentCount + 1 }))   // 2. what aggregates changed? patch them
    qc.invalidateQueries({ queryKey: ['user', 'me', 'activity'] })           // 3. what else observes it? invalidate broadly; it refetches lazily on use
  },
})
// keys are hierarchical: ['comments'] invalidates every comments query; ['comments', 42] only that post's. design keys as paths.
// staleTime decides whether a refetch is needed at all on the next read; gcTime decides how long unused data stays for an instant remount.
// with RSC: revalidateTag('comments') on the server after the action; the route's server components re-render; the client gets the new payload.
// the rule: a mutation's onSuccess lists every key whose data could have changed. missing one is a stale screen; listing too many is a few extra requests.