Клиентский кэш: TanStack Query, SWR и stale-while-revalidate

Пользователь открывает страницу товара, уходит и возвращается через 10 секунд. С обычным useEffect он снова ждёт полный fetch. С TanStack Query страница мгновенно показывает кэшированный результат, пока фоновое обновление тихо проверяет наличие изменений. Те же данные, радикально разный опыт.

Паттерн stale-while-revalidate

Stale-while-revalidate — стратегия свежести кэша из RFC 5861: отдавать кэшированные данные мгновенно даже если они могут быть устаревшими, затем делать refetch в фоне. Пользователь видит контент без ожидания; UI обновляется когда приходят свежие данные.

Оба TanStack Query и SWR реализуют это:

// TanStack Query
const { data, isLoading } = useQuery({
  queryKey: ['product', id],
  queryFn: () => fetchProduct(id),
  staleTime: 30_000,   // данные "свежие" 30s — фоновый refetch не делается
  gcTime: 300_000,     // неиспользуемые записи кэша живут 5 мин до GC
});

Первый визит: isLoading=true, fetch запускается, данные приходят, isLoading=false.
Второй визит (в пределах gcTime): data возвращается мгновенно из кэша. Фоновый fetch обновляет если staleTime истёк.

queryKey — это ключ кэша. ['product', id] — отдельная запись кэша от ['product', otherId].

Single-flight дедупликация

Когда несколько компонентов монтируются одновременно и все вызывают useQuery(['products']), TanStack Query делает только один сетевой запрос. Все компоненты разделяют результат. Это называется single-flight дедупликация — она сворачивает N одинаковых in-flight запросов в один, избегая как лишнего bandwidth, так и race conditions кэша.

// 10 компонентов <ProductCard> на странице, каждый вызывает:
useQuery({ queryKey: ['products'], queryFn: fetchProducts });
// → только ОДИН сетевой запрос

SWR делает то же самое. Это делает library-based кэширование радикально безопаснее, чем собственный useState + useEffect в каждом компоненте.

Optimistic updates

Для действий которые должны ощущаться мгновенными — Like, Bookmark, Отметить как прочитанное — применить изменение локально до подтверждения сервером, затем откатить при ошибке.

const mutation = useMutation({
  mutationFn: (postId: string) => likePost(postId),
  onMutate: async (postId) => {
    // 1. Отменить любые исходящие refetch'и
    await queryClient.cancelQueries({ queryKey: ['post', postId] });
    // 2. Snapshot текущего значения
    const previous = queryClient.getQueryData(['post', postId]);
    // 3. Optimistically обновить
    queryClient.setQueryData(['post', postId], (old) => ({ ...old, liked: true, likeCount: old.likeCount + 1 }));
    return { previous };
  },
  onError: (err, postId, context) => {
    // Откатить к snapshot'у при ошибке
    queryClient.setQueryData(['post', postId], context.previous);
  },
  onSettled: (postId) => {
    // Инвалидировать для получения канонического состояния сервера
    queryClient.invalidateQueries({ queryKey: ['post', postId] });
  },
});

Паттерн: применить ожидаемый ответ сервера локально, позволить реальному ответу заменить его. Если формы совпадают — замена no-op, пользователь не видит мерцания.

Стратегии инвалидации кэша

Когда мутация завершается успешно, устаревшие запросы должны обновиться. Три подхода:

invalidateQueries — пометить запросы устаревшими, запустить refetch при следующем observer’е. Самый безопасный; гарантирует канонические данные сервера.

queryClient.invalidateQueries({ queryKey: ['posts', userId] });

setQueryData — записать ответ мутации прямо в кэш. Самый дешёвый; лишних сетевых вызовов нет. Верно только когда ответ мутации включает полное новое состояние.

queryClient.setQueryData(['post', id], serverResponse);

refetchQueries — принудительный немедленный fetch. Используется когда нужны свежие данные прямо сейчас и нельзя доверять ответу мутации.

Большинство production кода использует оба: setQueryData для непосредственно изменённой сущности (если API её возвращает), invalidateQueries для listing запросов которые на неё ссылаются.