#server_components — Public Fediverse posts on home.social

Habr @[email protected] · 2026-07-27 · 13:22 UTC

SEO‑поиск в Next.js App Router, индексируемые landing pages из фильтров и URL

Поиск в Next.js App Router связывает несколько механизмов — Server Components, dynamic routes, searchParams , metadata и клиентские фильтры. Если в проекте одна форма и несколько результатов, состояние можно держать в useState . В каталоге или агрегаторе каждый фильтр меняет URL, набор данных и правила индексации. В статье на примере учебного проекта EventMap — агрегатора событий, разберем, как спроектировать систему фильтрации, которая генерирует чистые, индексируемые URL для поисковых роботов и обновляет выдачу при изменении фильтров. Страницы вроде «Концерты в Москве» или «Выставки в Петербурге» могут работать как отдельные landing pages. Для них нужны серверный HTML, постоянный URL, свой title , description , h1 , canonical и отдельная политика index или noindex . Произвольные запросы, сортировки и глубокая пагинация остаются частью поиска и не попадают автоматически в индекс. Поиск построен через App Router, optional catch‑all route, серверный рендер результатов и общий набор функций для URL, metadata, canonical и sitemap. Поиск по каталогу создаёт отдельное состояние для каждой комбинации фильтров. Категория, город, дата, сортировка, поисковая строка и номер страницы попадают в URL. При десяти категориях, пятидесяти городах и пяти вариантах сортировки получается 2500 комбинаций без учёта пагинации и свободного текста. Интерфейс должен обработать все допустимые комбинации. В поисковый индекс обычно попадает только часть из них. Страница категории music , страница города london и сочетание music/london могут содержать устойчивую подборку. Запрос ?q=free+jazz+tonight , сортировка по цене и восьмая страница выдачи относятся к текущему действию пользователя. Фильтры без отдельной политики создают большое пространство URL. Google описывает эту проблему в документации по faceted navigation. Изменение каждого параметра создаёт новый адрес, краулер тратит запросы на многочисленные комбинации и позже обнаруживает, что многие из них не содержат самостоятельного материала. ( Google for Developers )

https://habr.com/ru/articles/1063570/

#nextjs #seo #typescript #react #javascript #app_router #server_components #canonical #sitemap #noindex

#noindex #sitemap #canonical #server_components #app_router #javascript

Habr @[email protected] · 2026-06-01 · 09:42 UTC

Route Handlers как мини-бэкенд внутри Next.js App Router

Когда проект на Next.js только начинается, прямой fetch во внешний API кажется самым коротким путём. Есть страница списка, есть поиск, есть внешний источник данных, значит можно сходить туда напрямую и сразу показать результат. На маленьком экране это работает. Но дальше почти всегда начинаются одинаковые проблемы. Интерфейс начинает зависеть от чужой структуры ответа. Ошибки приходят в форме, которую неудобно показывать пользователю. Параметры запроса приходится валидировать в UI. Потом появляется базовый URL, который не хочется держать строкой в коде. Затем появляется ключ или другой секрет, который уже нельзя светить в браузере. В этот момент становится видно, что между UI и внешним API не хватает серверной границы. В App Router такую роль часто закрывает Route Handlers. В официальной документации Next.js они описаны как пользовательские обработчики запросов внутри app directory на основе стандартных Web Request и Response API. Они доступны только в app , по смыслу заменяют старые API Routes из pages и поддерживают GET , POST , PUT , PATCH , DELETE , HEAD и OPTIONS . (

https://habr.com/ru/articles/1042048/

#nextjs #app_router #route_handlers #proxy_api #environment_variables #next_public #server_components #react #javascript #вебразработка

#вебразработка #javascript #react #server_components #next_public #environment_variables

Habr @[email protected] · 2026-04-30 · 12:32 UTC

Кэширование в Next.js App Router, как увидеть, почему данные не обновились

С кэшированием в Next.js обычно случается одна и та же история. API уже отдаёт новые данные, страница открывается заново, а на экране всё ещё старая версия. После этого в код быстро добавляют cache: "no-store" , данные начинают запрашиваться на каждый заход, и через пару минут появляется уже другой вопрос - зачем тогда вообще нужен встроенный механизм кэширования. Проблема в том, что кэширование обычно звучит как одно явление, а на практике в App Router похожие ощущения могут давать разные уровни поведения. Навигация назад и вперёд может переиспользовать клиентский кэш маршрута, сам маршрут может рендериться по-разному, а серверный fetch в Next.js имеет собственные стратегии кэширования и перевалидации. В актуальной документации это уже разделено на новый режим с Cache Components и на прежнюю модель без них. В этой статье речь именно о привычной модели App Router без Cache Components, где поведение обычно задаётся через fetch , cache , next.revalidate и route segment config. ( Next.js ) Полезнее всего разбирать такую тему не с теории, а с наблюдения. Не с вопроса как устроены все слои кэша в Next.js, а с вопроса почему на одном и том же маршруте иногда обновляется рендер страницы, а иногда обновляются данные, и это не всегда одно и то же. Для примеров ниже используется проект Goods Finder и внешний API DummyJSON. Идея - сначала добавить на страницу штамп серверного рендера, потом отдельно показать момент получения данных, а уже после этого сравнить force-cache , no-store и revalidate .

https://habr.com/ru/articles/1030134/

#nextjs #app_router #caching #revalidate #nostore #forcecache #server_components #react #javascript #вебразработка

#вебразработка #javascript #react #server_components #forcecache #nostore

Habr @[email protected] · 2026-04-02 · 09:22 UTC

TypeScript в Next.js как система контрактов, а не типизация ради типизации

Когда разработчик начинает писать на Next.js с TypeScript, первая реакция часто довольно холодная. Вместо того чтобы двигаться быстрее, он начинает чаще видеть ошибки. Где-то не совпал shape объекта, где-то строка не подходит в более узкий тип, где-то TypeScript напоминает, что значение может быть undefined. На этом месте легко сделать неправильный вывод. Кажется, что TS просто добавляет трение и требует больше служебного кода. Обычно проблема не в TypeScript, а в способе мышления. Если использовать его как набор аннотаций поверх уже написанного кода, пользы действительно немного. Но если смотреть на типы как на систему контрактов между слоями приложения, картина меняется. Особенно в Next.js App Router, где у нас постоянно есть границы server и client, внешний ввод из URL, формы, мутации и разные состояния интерфейса. В этот момент TypeScript перестаёт быть типизацией ради типизации. Он начинает отвечать на более важный вопрос: какие состояния в проекте вообще допустимы, а какие не должны пройти дальше границы. По такой модели я выстроил один из своих проектов Workbench. Не начинать с мысли давайте везде поставим типы, а начинать с мысли где у нас проходит граница, что в неё входит и что из неё может выйти. После этого многие решения в коде становятся почти очевидными.

https://habr.com/ru/articles/1018382/

#nextjs #typescript #app_router #server_components #type_safety #zod #react #вебразработка

#вебразработка #react #zod #type_safety #server_components #app_router

Habr @[email protected] · 2026-03-27 · 16:42 UTC

URL как источник правды в Next.js App Router

Когда разработчик приходит в Next.js из обычного React SPA, он часто тащит с собой старую схему мышления. Есть поле ввода, значит будет useState . Есть поиск, значит будет useEffect . Есть список данных, значит будем следить за изменением состояния и вручную запускать новый запрос. На маленьком экране это вроде работает. Но очень быстро выясняется, что в приложении уже не одно состояние, а три. Есть значение в поле, значение в URL, данные, загруженные по одному из этих значений. Потом появляется четвёртая проблема. Кнопки Back и Forward начинают вести себя странно. Ссылкой на результат поиска неудобно делиться. А отладка превращается в угадайку, потому что не до конца понятно, что именно сейчас считается главным источником правды. В App Router это решается проще. Если фильтр является частью состояния страницы, его логично держать в URL. Тогда схема становится прямой: URL изменился -> сервер прочитал searchParams -> выполнил fetch -> отрендерил новый список. В этот момент Next.js начинает восприниматься как понятный инженерный инструмент.

https://habr.com/ru/articles/1016068/

#nextjs #nextjs_app_router #app_router #searchparams #url_state #server_components #react #javascript #вебразработка

#вебразработка #javascript #react #server_components #url_state #searchparams

Habr @[email protected] · 2024-10-22 · 10:22 UTC

Next.js v15 — Работа над Ошибками

Привет! Это ставшая уже регулярной рубрика о релизах next.js ( читайте релизы по v11 , v12 , v13 , v14 ). Каждый релиз - набор нового, интересного и спорного. Новая версия не станет исключением. Но всё же новая версия интересна не столько новым функционалом, сколько изменением приоритетов и организации в next.js. И да, как вы уже догадались из названия, в значительной части релиз ценен проработкой ошибок и доработками. В данной статье я не буду останавливаться на том что такое App Router или серверные компоненты - про это подробно расписано в предыдущих статьях. Только про новую версию и только про новые изменения. Примечание: в статье отражены самые интересные изменения с призмы автора. Презентация новой версии состоится 25 ноября. О ней будет выпущена дополнительная статья.

https://habr.com/ru/articles/852352/

#next #nextjs #frontend #frontend #webразработка #сайт #вебсайт #ускорение_сайта #remix #server_components

#next #nextjs #frontend #webразработка #сайт #вебсайт

Habr @[email protected] · 2024-05-16 · 04:32 UTC

React Conf 2024. React v19

Только что завершилась Конференция React.js. Долгожданная конференция спустя почти 3 года после предыдущей. Не менее долгожданны и обновления реакта. И именно с них была начата конференция, им и будет посвящена статья. И да, как вы увидели из превью - 19 версия перешла в статус release candidate. Полноценный же релиз нам обещают в течении двух недель. В целом, мне как next.js разработчику большая часть была знакома. Десятки статей на хабре уже рассказали о практически каждой части этого обновления, частично их касался и я рассказывая об обновлениях внесённых в next.js. Можно сказать, что главным направлениям этого обновления было достижение “Высокого UX при высоком DX”. Максимальная производительность при максимально простом коде. И так, а теперь к самой конференции.

https://habr.com/ru/articles/814671/

#react #frontend #react_19 #server_components #фронтенд #веб_разработка #реакт