TanStack в проде ломается не на API, а на границах ответственности

TanStack в проде ломается не на API, а на границах ответственности

Когда в проекте ставят TanStack Query, Table или Router «по умолчанию», проблема обычно не в библиотеке, а в том, что один слой начинает делать работу другого. Кэш решает сетевые запросы, но не бизнес-логику. Таблица управляет данными, но не правами доступа. Роутер раскладывает навигацию, но не должен превращаться в свалку эффектов.

Есть три правила, которые экономят недели:
— запросы описываются рядом с доменом, а не внутри компонентов-оберток;
— ключи кэша строятся стабильно и одинаково для списка, карточки и мутаций;
— invalidation делается по факту изменения данных, а не «на всякий случай».

Для Table отдельная ловушка — пытаться засунуть в неё все: фильтры, сортировку, пагинацию, серверные ограничения и локальный UI. Лучше сразу решить, где источник истины: если сервер, то Table получает состояние извне и только отображает; если клиент, то не смешивать это с backend-логикой. Иначе отладка превращается в поиск, кто именно перезатёр страницу.

Router тоже любит дисциплину. Держите переходы и загрузку данных рядом с маршрутом, а не размазывайте их по случайным useEffect. Тогда prefetch, переходы и ошибки читаются как схема, а не как набор костылей.

Если TanStack начинает «вести себя странно», первым делом проверьте не библиотеку, а размытые границы: кто владеет данными, кто владеет UI и кто решает, когда инвалидировать кэш.