Кэширование в 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 #вебразработка

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 #вебразработка

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 #вебразработка

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

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 #фронтенд #веб_разработка #реакт