Approuter

Поиск на useState и useEffect работает целиком в браузере. После загрузки компонента запускается запрос, ответ записывается в state, затем появляется список результатов.

В Next.js с Server Actions initialState легко недооценить и оставить прямо внутри компонента. Формально это работает. Но архитектурно у такого решения есть побочный эффект. UI начинает сам определять стартовую форму результата, а значит понемногу забирает на себя часть контракта, который логичнее держать рядом с action-слоем.

Один из полезных эффектов Route Handlers проявляется не в проксировании запросов, а в том, что внутри проекта появляется свой контракт ответа.

Одна из истин в Next.js с Server Actions, запись данных живёт только в actions. Клиентский компонент не решает, как именно сохранить сущность, куда отправить fetch, как собрать payload и как распарсить ответ. Его задача уже, показать форму, состояние pending, локальную ошибку и нужный ритм взаимодействия.

Прямой fetch из интерфейса во внешний API обычно живёт ровно до того момента, пока проект не становится чуть сложнее. Потом выясняется, что UI знает лишнее: адрес внешнего сервиса, форму чужого ответа, правила ошибок, а иногда и то, что вообще не должно выходить в браузер.

В App Router эту зависимость можно разрезать через Route Handler. Внут…

Одна из неприятных причин путаницы в Next.js состоит в том, что dev и build легко принять за два одинаковых режима, отличающихся только скоростью. На практике это не так.

Одна из типовых проблем формы в Next.js возникает не в submit и не в схеме валидации, а в формате ошибки. Пока все сообщения сваливаются в одну переменную, интерфейс перестаёт различать две разные вещи, ошибка конкретного поля и ошибка самой операции.

В Next.js есть момент, который хорошо знаком после первых экспериментов с App Router. Страница уже пересчиталась, reload прошёл, а данные на экране выглядят старыми. Часто причина в том, что включён revalidate, а значит у ответа есть окно свежести.

Одна из частых ошибок в проекте на Next.js выглядит просто. Форму собирают как input, кнопку и submit, а всё остальное добавляют потом по мере необходимости. Сначала это кажется быстрым решением, но дальше почти всегда начинается расползание логики. Где-то ошибка поля, где-то общая строка сверху, где-то можно нажать submit несколько раз подряд, где…

В Next.js часто сбивает не само кэширование, а расхождение между рендером страницы и свежестью данных. Страница уже пересчиталась, а ответ от API всё ещё старый. Или наоборот, разработчик отключает кэш везде подряд и теряет сам смысл встроенного механизма.

Когда фильтры в каталоге живут в client state, почти сразу появляется знакомый набор задач: синхронизировать их с URL, не потерять при reload, поддержать back/forward, не запутаться в useEffect и не разнести логику по нескольким уровням интерфейса.

Один из полезных тестов для App Router это не только searchParams сами по себе, но и их грязные варианты. Например: /goods?q=phone&q=tv.