Next.js, фильтры без client state
Один из заметных сдвигов в App Router происходит в тот момент, когда фильтры перестают жить в наборе локальных состояний и начинают описываться через URL.
Для каталога это даёт понятную схему. Пользователь меняет фильтр, URL обновляется, сервер читает searchParams, выполняет fetch и рендерит уже готовый результат. Без отдельного client state для самих данных, без лишнего useEffect, без ручной синхронизации между адресной строкой и интерфейсом.
Такой подход полезен не только тем, что кода становится меньше. Фильтры начинают переживать обновление страницы, нормально работают с back/forward, дают прямую ссылку на результат и проще отлаживаются. Адрес страницы начинает содержать реальное состояние, а не его тень.
Client state при этом не исчезает совсем. Он остаётся там, где ему и место: во временных UI-деталях, черновом вводе, локальных переключателях до подтверждения. Но сами фильтры страницы вполне могут жить без него.
Статья на Хабр Проект: Goods Finder Stepik: Next.js I: JavaScript 2026
#nextjs #AppRouter #searchParams #filters #urlstate #servercomponents #react #javascript #frontend #webdev
· 06.05
GET-параметры в URL, которые читает сервер и рендерит страницу — это буквально то, что делал каждый PHP-разработчик в 2005 году через $_GET['filter']. Никакого состояния, никакой синхронизации, просто строка запроса и шаблон.
ответить
коммент удалён
· 06.05
База прежняя, технически это ровно то же самое, что и $_GET в 2005. Хорошо, что до неё наконец добрались и в React-мире. Разница в том, что сейчас это встроено в согласованную модель - Server Components, searchParams, автоматическая работа с историей, отсутствие лишних рендеров и useEffect. В 2005 данные шли в шаблон, но каждый чих требовал полной перезагрузки страницы. Сегодня то же самое даёт SPA-навигацию, оптимистичные обновления и нормальный back/forward без ручных костылей
ответить
ответ удалён