По видео пока вообще непонятно, как это технически будет работать (а по коду пока только мимопроходил)
Я сделал такой вывод исходя из написанного тут (раздел How does Partial Prerendering work?). Забавно, что они вставили экспериментальную фичу о которой почти нигде не писали в обучающий курс.
Ух, next v15 вас удивит, но практически все кеширования будут отключены по умолчанию.
Если не секрет, откуда такая информация?) я не нашёл источников о следующем релизе.
PPR решит все ваши проблемы.
Почитал я про этот PPR (Partial Prerendering). Если я правильно понял, неужели они теперь по нормальному объединят SSG и SSR? Потому что сейчас если у тебя раут SSG и хочется на нём, скажем прочитать query параметры (хук useSearchParams), то ты либо переключаешься на SSR, либо код с query параметрами оборачиваешь в Suspense и этот кусок рендерится только на клиенте (клиент не получит этот кусок HTML от сервера).
А теперь можно будет часть раута пререндерить в HTML во время сборки, а оставшуюся часть на сервере во время запроса? Если так, то прям здорово. А то обидно было терять довольно сильную оптимизацию в виде SSG из-за какого-то динамического куска кода. Интересно, а ревалидацию статической части HTML сохранят?
Привет! Работаю с 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 говорит сама за себя. Да и примеров в сообществе я не находил, так что тащить на прод боязно.
Это конечно не все плюсы и минусы, но пожалуй наболевшие)
Немного поясню про админку и бэкенд. У нас бэкенд был написан на python, а админка писалась бэкендерами на джанго. Поэтому я админку в статье называл бэкендом) Если быть точнее, то Next.js при выполнении команд build & start запускает свой сервер. Так вот запрос слался из админки (после того, как админ изменял информацию) на сервер Next.js и обрабатывался как написано в статье. Извините, если кого-то ввёл в заблуждение)
Я сделал такой вывод исходя из написанного тут (раздел How does Partial Prerendering work?). Забавно, что они вставили экспериментальную фичу о которой почти нигде не писали в обучающий курс.
Если не секрет, откуда такая информация?) я не нашёл источников о следующем релизе.
Почитал я про этот PPR (Partial Prerendering). Если я правильно понял, неужели они теперь по нормальному объединят SSG и SSR? Потому что сейчас если у тебя раут SSG и хочется на нём, скажем прочитать query параметры (хук useSearchParams), то ты либо переключаешься на SSR, либо код с query параметрами оборачиваешь в Suspense и этот кусок рендерится только на клиенте (клиент не получит этот кусок HTML от сервера).
А теперь можно будет часть раута пререндерить в HTML во время сборки, а оставшуюся часть на сервере во время запроса? Если так, то прям здорово. А то обидно было терять довольно сильную оптимизацию в виде SSG из-за какого-то динамического куска кода. Интересно, а ревалидацию статической части HTML сохранят?
Привет! Работаю с 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 говорит сама за себя. Да и примеров в сообществе я не находил, так что тащить на прод боязно.
Это конечно не все плюсы и минусы, но пожалуй наболевшие)
Немного поясню про админку и бэкенд. У нас бэкенд был написан на python, а админка писалась бэкендерами на джанго. Поэтому я админку в статье называл бэкендом) Если быть точнее, то Next.js при выполнении команд build & start запускает свой сервер. Так вот запрос слался из админки (после того, как админ изменял информацию) на сервер Next.js и обрабатывался как написано в статье.
Извините, если кого-то ввёл в заблуждение)