TanStack полезен не там, где «есть таблица», а где надо держать состояние под контролем

TanStack полезен не там, где «есть таблица», а где надо держать состояние под контролем

В экосистеме TanStack чаще всего берут не одну библиотеку, а набор: Query для данных, Table для рендера, Router для маршрутов. И ошибка здесь одна — пытаться тащить их как замену всему фреймворку. Это инструменты для конкретных зон, а не новый React.

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

Если у тебя CRUD, фильтры и список с переходами между экранами — TanStack Query часто закрывает 80% боли. Если таблица превращается в маленький BI-интерфейс, TanStack Table экономит недели на ручной логике. Но если проект простой, перегрузка абстракциями только ухудшит сопровождение.

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

Итого: сначала опиши жизненный цикл данных и экрана, потом выбирай инструменты. TanStack выигрывает не по моде, а когда тебе нужно меньше магии и больше контроля.