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

Рет қаралды 4,786

2 ай бұрын

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

Пікірлер: 25

@wardxela Ай бұрын

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

@snatvb 2 ай бұрын

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

@wardxela Ай бұрын

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

@reactnext13 Ай бұрын

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

@vladimircreator 2 ай бұрын

18:10 * ещё Remix и Gatsby

@romanmed9035 2 ай бұрын

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

@typingaway 17 күн бұрын

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

@romanmed9035 17 күн бұрын

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

@yohimik Ай бұрын

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

@endlesslysorrow 23 күн бұрын

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

@yohimik 22 күн бұрын

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

@vladimircreator 2 ай бұрын

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

@izzy7541 2 ай бұрын

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

@vladimircreator 2 ай бұрын

@@izzy7541 SSR

@user-sw4ed4gh9n 2 ай бұрын

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

@endlesslysorrow 23 күн бұрын

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

@zapilniy 17 күн бұрын

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

@_ivanoleksiuk Ай бұрын

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

@typingaway 17 күн бұрын

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