<b>TanStack в проде ломается не в UI, а в дисциплине данных и кэша</b>

<b>TanStack в проде ломается не в UI, а в дисциплине данных и кэша</b>

TanStack — это не “одна библиотека”, а набор инструментов, где каждая часть решает свою боль: Query, Table, Router, Form. Ошибка начинается, когда их подключают как замену архитектуре: без границ ответственности, без единых ключей и без правил для серверного состояния.

Для Query проверь три вещи:
— ключи запросов должны быть стабильными и содержать все параметры, влияющие на ответ;
— invalidation лучше строить от домена, а не от конкретного компонента;
— staleTime и cacheTime не ставь “на глаз”: они должны совпадать с частотой изменений данных.

В TanStack Table не тащи бизнес-логику в колонки. Колонка — это представление, а не место для расчётов, фильтров и прав доступа. Если сортировка, агрегация и форматирование размазаны по рендеру, таблица становится дорогой в поддержке и плохо масштабируется по данным. ⚙️

TanStack Router особенно полезен там, где URL — часть модели приложения. Но маршруты надо проектировать как API: с предсказуемыми параметрами, вложенностью и явными загрузочными границами. Иначе получится красивая навигация, которая не помогает ни предзагрузке, ни восстановлению состояния.

Если хотите, чтобы TanStack реально помогал, разделяйте серверное состояние, UI-состояние и состояние URL. Тогда библиотека усиливает продукт, а не прячет хаос под аккуратными хуками.