Инвалидация кэша

Инвалидация связывает записи с затронутыми чтениями. Стратегии: инвалидация по префиксу ключа, точное совпадение, граф тегов (RTK Query) или ручной `setQueryData`, когда известна следующая форма.

					// После создания поста — инвалидировать список и положить detail в кэш
queryClient.invalidateQueries({ queryKey: ['posts'] });
queryClient.setQueryData(['posts', newPost.id], newPost);
				

| Стратегия | Когда | |-----------|-------| | Широкая инвалидация | Простые приложения; терпим refetch | | Точечные ключи | Известны только затронутые queries | | setQueryData | Ответ сервера совпадает с формой кэша | | Optimistic + rollback | Чувствительный к latency UX |

Правила продукта задают свежесть: дашборды могут poll; справочники — минуты; пользовательские данные refetch при навигации.

Компромисс: свежие чтения после записей против лишних запросов при слишком широкой инвалидации.

На интервью: «самая сложная проблема» — назовите схему key/tag до кода mutations.

Типовые ошибки: invalidate всего на каждый POST, устаревший detail после update списка, гонка refetch с optimistic UI.

Чеклист:

• Документируйте иерархию ключей и зависимости.
• Инвалидируйте минимально достаточный набор.
• Обновляйте кэш напрямую, если ответ авторитетен.
• Тестируйте параллельные mutations и сбои.