MoscowJS 58 - Темная сторона NextJS - Александр Моргунов

Cейчас почти на каждой фронтенд конференции есть доклад про самый популярный фреймворк, за которым будущее фронтенд разработки - NextJS. Рассказывают про новые фичи: серверные компоненты, серверные экшены, частичный пререндеринг с быстрой отдачей статического ответа и стримингом динамического контента. Кажется наконец-то появилось решение во фронтенде, которым все довольны. Но так ли все хорошо на самом деле? В том ли направлении развивается NextJS? О проблемах говорят не так много, поэтому может создаться впечатление, что их просто нет. Давайте сегодня об этом и поговорим. Спойлер: говорить будем про серверную составляющую и вендерлок.
moscowjs.org/events/moscowjs-58/
Все новости и анонсы MoscowJS в нашем телеграм-канале: t.me/moscowjs

[@wardxela]

Спасибо за выступление, интересные мысли.

[@wardxela]

26:29 - Не совсем понял претензию про контексты: почему их нет в app router? По-моему любой стейт менеджер можно подружить с этой архитектурой. Важно только вынести компонент инициализации контекста в отдельный файл и прописать 'use client'; В дальнейшем все серверные компоненты можно передавать как children. Единственное ограничение - вы не можете пользоваться этим контекстом в серверных компонентах. Вообще серверные компоненты - это про другой подход к построению приложения. Я их воспринимаю просто как способ что-то сделать на сервере и отдать полученное на клиент без возможности изменения. Любое изменение в серверном компоненте должно подразумевать очередной запрос на сервер.

[@snatvb]

16:33 статически можно собрать, получить куки и хэдеры можно, это ж базовые вещи, странно что такое просочилось в доклад

[@reactnext13]

Понравилось выступление, стало более понятно в отличие от всяких блогеров

[@vladimircreator]

18:10 * ещё Remix и Gatsby

[@yohimik]

7:38 такое легко делается через кастомный сервер 12:04 аналогично, некстовые либы возвращают хендлер, который работает с дефолтными нодовскими req и res, делай с ним что хочешь, хоть на express повесь, хоть на fastify кастомный логер для логирования некстовых сообщений, правда не добавишь (глобально костылить только типа console.log = () => ... или патчить файлы) рекомендация использовать page router жесть, может классовые компоненты тогда ещё? никто не будет в будущем сильно поддерживать page router, а новые функции будут в app router, тем более когда уже столько времени потратили на него. пока оставили page, чтобы люди успели мигрировать на app

[@endlesslysorrow]

там же написано: для SSR, app router это по дефолту RSC, это не совсем SSR

[@yohimik]

​@@endlesslysorrow ну если идейно устаревший ssr нужен ради того, чтобы ответы были пререндерены именно на сервере, а не для того, чтобы решать современные проблемы и совмещать разные подходы и при всем этом решать все те же проблемы, что и чистый ssr, то ок)

[@romanmed9035]

все же непонятно их сдерживает сложность перехода на новую архитектуру, а если бы сейчас начинали, то какую использовали бы или вообще не нэкст,

[@typingaway]

Сдерживает то, что придется все приложение переписать. У нас толстый клиент и много логики перенесено на клиент. Из-за этого активно используется редакс и для перехода на AppRouter придется почти все рефакторить, на это к сожалению ресурсов нет. Что бы использовали, ниже ответил, что все зависит от задач. Так как нам нужно SEO (SSR), то использовали NextJS, скорее всего на PageRouter-е, но писали бы код так, что бы потом было просто мигрировать на AppRouter

[@romanmed9035]

@@typingaway спасибо за пояснения

[@vladimircreator]

Насчёт серверных компонентов не понял претензию. Наооборот это лучше, чем тащить килобайты JavaScript и ждать пока этот JavaScript отрисует интерфейс. А так можно получить готовую HTML и вуаля.

[@izzy7541]

А зачем нам в таком случае некст? Берём генератор статики, получаем готовый хтмл и вуаля

[@vladimircreator]

@@izzy7541 SSR

[@user-sw4ed4gh9n]

@@izzy7541 , генератор статики это кто, если не секрет?

[@endlesslysorrow]

@@izzy7541 с такими развернутыми комментариями можно предложить просто в html файлик все писать

[@zapilniy]

В таком случае нужна серверная инфра, которая будет заниматься генерацией хтмлок, в отличие от SPA

[@_ivanoleksiuk]

27:57 а на какой архитектуре писать с нуля?

[@typingaway]

Все зависит от задач же. Если нужно SEO (= SSR), то NextJS (можно посмотреть на альтернативы конечно, но NextJS по развитию вырывается вперед). А какую архитектуру, хороший вопрос. Я придерживаюсь мнения, если проект не критичный для бизнеса, то можно без проблем пробовать новую архитектуру на AppRouter. В ином же случае PageRouter, но писать код так, что бы в дальнейшем было просто перейти на новую архитектуру (например, разделять серверный стейт (кеши запросов), и клиентский для логики на клиенте).

[@user-mi1hq1dz2b]

Чет я вообще не понял про куки в next rsc. Да и как-то уже не хочется использовать page router.

[@developerdiary3136]

Из-за стриминга есть проблемы с куками, ишьюсы можете найти

[@izzei-1614]

Что такого в page router? Он стабилен, в нем работает вся экосистема реакта, подход к созданию приложений типичный и понятный для всех разработчиков