Какие техники кэширования существуют в React

Что проверяют

Различаете ли вы три разные вещи под словом «кэширование»: мемоизацию при рендере, кэш серверных данных и HTTP-кэш. Следом почти всегда спрашивают, когда useMemo не нужен и чем staleTime отличается от gcTime.

Как отвечать

Разложите по уровням:

• React.memo: пропускает повторный рендер компонента, если пропсы поверхностно равны по Object.is. Работает, только если родитель не создаёт новые объекты и функции на каждом рендере;
• useMemo: запоминает результат тяжёлого вычисления до смены зависимостей. В документации React прямо сказано, что это оптимизация, а не гарантия: кэш может быть сброшен;
• useCallback: запоминает саму функцию, нужен в паре с React.memo у потомка или когда функция стоит в зависимостях эффекта;
• React Compiler: расставляет мемоизацию автоматически на этапе сборки, поэтому в проектах с ним ручные useMemo и useCallback почти не нужны;
• кэш серверного состояния: TanStack Query, SWR, RTK Query, Apollo Client. Запросы кэшируются по ключу, дублирующиеся вызовы схлопываются, данные обновляются в фоне. В TanStack Query staleTime по умолчанию 0, то есть данные сразу считаются устаревшими, а gcTime (5 минут) определяет, сколько неиспользуемый кэш живёт в памяти;
• cache() в Server Components: дедупликация одного запроса в рамках одного серверного рендера, между запросами он не живёт;
• браузер и сеть: заголовки Cache-Control, CDN для статики, Service Worker для офлайна.

Хорошо закончить правилом: сначала измерить в React DevTools Profiler, потом мемоизировать то, что действительно тормозит.

Где спотыкаются

Оборачивают в useMemo каждую строку. Сравнение зависимостей тоже стоит времени, а код становится тяжелее читать.

Передают в компонент под React.memo инлайн-объект или стрелочную функцию и удивляются, что он всё равно перерисовывается.

Складывают ответы сервера в Redux или контекст и пишут свою инвалидацию. Это и есть задача библиотек серверного состояния, самописный вариант обычно теряет фоновую перезагрузку и обработку гонок.