Комментарии 18
Спасибо! Благодаря nextjs и react 19 (server components, server actions, form) становится проще писать приложения.
А что в изменениях next.js нравится и упростило написание кода (именно next.js, т.е. навигация в app router, новые роуты и абстракции, кеширование и т.п.)?
Всё ещё испытываю очень спорные эмоции и хочу понять в чём улучшило жизнь другим (или ухудшило, тоже очень интересно, особенно если решу писать по нему ещё статьи).
(О своих итогах писал в первую очередь в статье про App Router и статье про кеширование в next.js)
Привет! Работаю с Next.js два года, есть актуальный опыт переноса из Pages в App полноценного приложения, который давно в продакшене. Для себя из плюсов могу выделить:
- Более удобная структура раутов. Нравится строгое разделение файлов на page, layout и возможность использовать любые свои файлы/папки не влияя на сами рауты. Иногда это удобно.
- Серверные компоненты намного удобнее прошлого API с getServerSideProps и другими методами. И очень нравится идея уменьшения клиентского JS. Более того, и на практике это действительно улучшает производительность сайта (не мудрено). Проблема серверных компонентов на мой взгляд только в том, что у них сильно отличается ментальная модель от того, к чему привыкло большинство разработчиков. Поэтому надо приложить усилия, что бы перестроиться и начать думать по-другому. По аналогии с переходом от классовых компонентов на функциональные.
- Мне по большей части нравится новое кэширование и фокус на нём. Да, оно не лишено недостатков, но так как это одна из ключевых фичей нового App Router, думаю в будущем нас ждут только улучшения.
Из минусов и с какими трудностями мы столкнулись во время переноса
- В App Router долгое время была сломана вставка CSS стилей при переходе между страницами (ломался порядок стилей они начинали неправильно переопределять друг друга). Они починили это только в 14.2. Удивительно конечно, как настолько базовая вещь могла так долго оставаться без фикса.
- Отсутствие старых событий раутера, на которые можно было подписаться (routeChangeStart и др.). В итоге перенос такой простой вещи как nprogress (полоса загрузки вверху страницы) превратился в создание обёрток над компонентом Link и хуком useRouter, читайте костыль.
- спорный loading UI (файл loading.js), у которого куча проблем. Во первых он не работает в SSG, так как построен на Suspense, а Suspense требует асинронных действий. В SSG асинхронность происходит во время билда (или в фоне) и поэтому loading UI просто не срабатывает, у пользователя не появляется условный скелетон во время перехода на страницу. Во вторых даже если у нас SSR, а не SSG - loading UI не мгновенный, а есть небольшая задержка между кликом по ссылке и показом условного скелетона. Что если честно очень раздражает. В итоге показ скелетонов между страницами пришлось опять реализовывать через костыли.
- Ну и конечно невозможность использования того же axios (или чего другого), если вам нужно кэширование. Да, есть cache из Реакт, но это работает только как аналог Memoization из Next.js. Есть аналог для Data Cache в виде функции unstable_cache, но приставка unstable говорит сама за себя. Да и примеров в сообществе я не находил, так что тащить на прод боязно.
Это конечно не все плюсы и минусы, но пожалуй наболевшие)
Спасибо за подробный ответ!
Мне по большей части нравится новое кэширование и фокус на нём. Да, оно не лишено недостатков, но так как это одна из ключевых фичей нового App Router, думаю в будущем нас ждут только улучшения.
Ух, next v15 вас удивит, но практически все кеширования будут отключены по умолчанию. Лично я этому рад, потому что мы кешировали достаточно много информации, а реализации next-а оказалась хуже нашей, но при этом мешала и просто работала поверх (ещё и сборка в несколько процессов портила идеальное кеширование нашей реализацией, посмотрим как они это обойдут в новой версии). Кеширование ломает гибкость и специфики, поэтому это должно быть решением команд (хотя бы обычный флаг).
Они как я понимаю откажутся от сильного кеширования и скажут, что PPR решит все ваши проблемы.
Проблема серверных компонентов на мой взгляд только в том, что у них сильно отличается ментальная модель от того, к чему привыкло большинство разработчиков
Я бы главным назвал необходимость использовать prop drilling. Когда у тебя десятки уровней вложенности - это ужас (а то как извращаются библиотеки переводов чтоб найти решения - ух... [но я и сам в обходе немного так наделал]).
сломана вставка CSS стилей ... Они починили это только в 14.2.
Я в 14.3.1 поймал... Когда компонент рендерится только на клиенте. Ну а в первых версиях вообще часто ломалось, да.
Да, есть cache из Реакт, но это работает только как аналог Memoization из Next.js. Есть аналог для Data Cache в виде функции unstable_cache
cache реакта отлично себя показывает. unstable_cache лучше тем, что он кеширует поверх процессов, ещё и сохраняет инфу между пересборками (как и fetch, это в целом под капотом одна функция, которую можно реализовать по-своему - cacheHandler)
Ух, next v15 вас удивит, но практически все кеширования будут отключены по умолчанию.
Если не секрет, откуда такая информация?) я не нашёл источников о следующем релизе.
PPR решит все ваши проблемы.
Почитал я про этот PPR (Partial Prerendering). Если я правильно понял, неужели они теперь по нормальному объединят SSG и SSR? Потому что сейчас если у тебя раут SSG и хочется на нём, скажем прочитать query параметры (хук useSearchParams), то ты либо переключаешься на SSR, либо код с query параметрами оборачиваешь в Suspense и этот кусок рендерится только на клиенте (клиент не получит этот кусок HTML от сервера).
А теперь можно будет часть раута пререндерить в HTML во время сборки, а оставшуюся часть на сервере во время запроса? Если так, то прям здорово. А то обидно было терять довольно сильную оптимизацию в виде SSG из-за какого-то динамического куска кода. Интересно, а ревалидацию статической части HTML сохранят?
Если не секрет, откуда такая информация?) я не нашёл источников о следующем релизе.
Твиты разразоботчиков, PR-ы, подогревают тему скорых крупных изменений, ну и в целом время уже к релизу (4-ю минорку они делать не любят).
по нормальному объединят SSG и SSR
Честно признаюсь - не знаю. По видео пока вообще непонятно, как это технически будет работать (а по коду пока только мимопроходил)
Надеюсь завтра на Vercel conf коснутся и некста, и PPR в целом как то, что сделает веб ещё быстрее и прочий маркетинг
По видео пока вообще непонятно, как это технически будет работать (а по коду пока только мимопроходил)
Я сделал такой вывод исходя из написанного тут (раздел How does Partial Prerendering work?). Забавно, что они вставили экспериментальную фичу о которой почти нигде не писали в обучающий курс.
Да, но как. Они рендерят статическую часть при сборке и оставляют слоты/ссылки на динамические компоненты. Или всё же пересобирают и статическую часть по запросу, но каким-то супер оптимизированным способом и то, что динамическое собирают полноценно. А общение между этими частями как, допустим если со статической части передать пропсом объект с ценами.
Поэтому ждём. Из-за этого например и авторы библиотек переводов аккуратно подходят к реализациям получения локали (переписывался в дискуссиях с автором next-intl в меру общей проблемы).
Новость не заставила себя долго ждать 😁
Пакет для конфигурации config настроенный под все окружения next.js
Можете поподробнее рассказать об этом?
Можно сказать, что nextjs исполняется в четырёх средах: сервер, клиент, edge и сборка. Сам он для конфигурации предлагает использовать env файлы и два вида переменок - серверные и публичные (начинаются с NEXT_PUBLIC_ и будут встроены в код во время сборки).
Для edge рантайма и клиента приходится использовать публичные переменные. А это в свою очередь означает, что приложение будет полностью зафиксировано под окружение в момент сборки.
Пакет же даёт возможность настроить файлы конфигураций в стиле, схожем с пакетом config, под каждую среду и использовать их в нужных местах в нужном окружении.
В общем интересный эксперимент как можно иначе конфигурировать fullstack приложение.
(Думаю [когда-нибудь, [надеюсь [и мне хочется верить]]], что я допишу по нему статью)
а как к ним обращаться в коде для рантайма, так же как и раньше process.env.NEXT_PUBLIC_ ?
После настройки: const config = useRuntimeConfig();
Есть вполне достаточный пример - https://github.com/vordgi/nimpl-config/blob/main/example. Ну и дока, конечно, тоже есть - https://nimpl.tech/config/usage)
По второму дню статьи уже не будет, поэтому просто оставлю это здесь (для тебя, мой дорогой редкий читатель! 😁)
Часть Windows построена на React Native!
В серверных же действиях отправка произойдёт сразу, т.к. не требует клиентского js.
Интересно, в каких таких серверных действиях может понадобиться отправлять форму во время серверного рендеринга? И что вообще такое "серверные действия". Просто когда сервер рендерит страницу, никаких событий не может произойти по определению, потому что на сервере нет ни юзера, ни браузера, ни чего-либо ещё, что может взывать какие-то события в процессе рендеринга. В этом кстати главная проблема производительности SSR в Next: virtual DOM, слушатели событий, реактивность - всё это на сервере вообще не нужно. Но это тянут ради изоморфности кода, каждый раз изобретая велосипед, пытаясь решить эти проблемы.
Server action (решал здесь, кстати, стоит переводить или нет). Честно говоря под катом этого не разбирался, но в целом это про:const publishAction = (data) => {
"use server"
// ...
}
// ...
<form action={publishAction}>
// ...
И вот здесь publishAction станет API роутом, а в form передастся url этого API. Соответственно при отправке формы не нужно будет ждать пока загрузится её логика
React Conf 2024. React v19