TanStack Query или SWR в 2026 — что выбрать для нового проекта?

[raspberryguru]

Начинаем новый проект — B2B-портал, много таблиц с данными, фильтрация, пагинация, real-time обновления через WebSocket. Стек: Next.js 15, TypeScript. Стою перед выбором между TanStack Query v5 и SWR v2. Раньше использовал SWR — нравится простота, но слышал что TanStack Query сильно вырвался вперёд. Кто с чем работает, какие реальные плюсы-минусы?

[mstrbates]

Работаю с TanStack Query с версии 3, сейчас на v5. Для вашего кейса (таблицы, фильтрация, пагинация) — однозначно TanStack Query. Вот почему конкретно: 1) useInfiniteQuery из коробки с нормальным API для пагинации. 2) Оптимистичные обновления через onMutate — для таблиц это критично, иначе UX деревянный. 3) Девтулзы — это отдельная песня, видишь весь кэш в реальном времени, это сильно ускоряет дебаг. 4) Для WebSocket есть паттерн через queryClient.setQueryData, работает чисто. По бандлу: да, 13.4KB против 4.2KB у SWR, но на фоне остального бандла это копейки.

[gdgdgd]

@raspberryguru, Я бы поспорил — SWR недооценивают. Если проект с Next.js и деплой на Vercel/Netlify, SWR интегрируется просто идеально, они от одной компании. API проще, меньше бойлерплейта. Для стандартных CRUD-операций мне SWR хватает с головой. TanStack Query оправдан когда у вас реально сложные зависимости между запросами, много мутаций с оптимистичными обновлениями. Для простого B2B-портала это может быть overkill.

[rburr]

@gdgdgd, Посмотрел свежую статистику на pkgpulse: TanStack Query — 12.3 млн скачиваний в неделю, SWR — 7.7 млн. TanStack обогнал SWR ещё в конце 2024 и разрыв растёт. Это важный сигнал — большая экосистема значит больше статей, примеров, быстрее находишь решение на Stack Overflow когда что-то идёт не так. Для команды это важнее чем разница в 9KB бандла.

[Sjobs]

Используем TanStack Query v5 в продакшне около года. Реальная боль которую стоит знать заранее: при переходе с v4 на v5 сломался синтаксис — onSuccess/onError/onSettled убрали из useQuery (перенесли только в useMutation). Если будете искать примеры в интернете — половина из них для v4, не работает. Обязательно фильтруйте по версии в документации. Зато v5 с TypeScript работает значительно лучше, типы стали намного строже.

[FpgaDev]

Для вашего конкретного случая с WebSocket — смотрите в сторону TanStack Query + паттерн 'socket as a query invalidator': WebSocket шлёт событие, вы вызываете queryClient.invalidateQueries({ queryKey: ['orders'] }), и все подписанные компоненты автоматически рефетчат данные. Это проще чем пытаться подружить SWR с WS. Реализовали так на логистическом портале, работает стабильно уже 8 месяцев.

[mstrbates]

@FpgaDev, паттерн рабочий, но на B2B с частыми WS-апдейтами одним invalidateQueries легко словить шторм рефетчей — каждое событие дёргает сеть по всем подписанным компонентам. Если в сокете уже прилетает дельта (а не просто 'что-то изменилось'), лучше патчить кэш напрямую через setQueryData и не ходить на бэк вообще. invalidate оставляй на случаи когда дельте не доверяешь или прилетел только id.

[qemuveteran]

@gdgdgd, про overkill не соглашусь именно под этот кейс. Человек прямым текстом просит пагинацию + оптимистичные апдейты в таблицах с первого дня. На SWR оптимистик через mutate с ручным роллбэком становится колхозом ровно тогда, когда таблиц больше трёх. onMutate/onError с откатом в TanStack это не 'про сложные зависимости', это базовый сценарий редактируемой таблицы. Для чтения SWR недооценён, согласен, но тут ТЗ другое.

[Bowden]

По связке WS + таблицы реальная развилка не TanStack vs SWR, а готовы ли вы сделать кэш источником правды. И отдельно подсвечу киллер-фичу под B2B-пагинацию: placeholderData: keepPreviousData в v5. Таблица при смене страницы/фильтра не схлопывается в пустоту и не мигает спиннером — старые строки висят, пока грузятся новые. В SWR это собирается руками, из коробки не так гладко.