26:29 - Не совсем понял претензию про контексты: почему их нет в app router? По-моему любой стейт менеджер можно подружить с этой архитектурой. Важно только вынести компонент инициализации контекста в отдельный файл и прописать 'use client'; В дальнейшем все серверные компоненты можно передавать как children. Единственное ограничение - вы не можете пользоваться этим контекстом в серверных компонентах. Вообще серверные компоненты - это про другой подход к построению приложения. Я их воспринимаю просто как способ что-то сделать на сервере и отдать полученное на клиент без возможности изменения. Любое изменение в серверном компоненте должно подразумевать очередной запрос на сервер.
7:38 такое легко делается через кастомный сервер 12:04 аналогично, некстовые либы возвращают хендлер, который работает с дефолтными нодовскими req и res, делай с ним что хочешь, хоть на express повесь, хоть на fastify кастомный логер для логирования некстовых сообщений, правда не добавишь (глобально костылить только типа console.log = () => ... или патчить файлы) рекомендация использовать page router жесть, может классовые компоненты тогда ещё? никто не будет в будущем сильно поддерживать page router, а новые функции будут в app router, тем более когда уже столько времени потратили на него. пока оставили page, чтобы люди успели мигрировать на app
@@endlesslysorrow ну если идейно устаревший ssr нужен ради того, чтобы ответы были пререндерены именно на сервере, а не для того, чтобы решать современные проблемы и совмещать разные подходы и при всем этом решать все те же проблемы, что и чистый ssr, то ок)
Сдерживает то, что придется все приложение переписать. У нас толстый клиент и много логики перенесено на клиент. Из-за этого активно используется редакс и для перехода на AppRouter придется почти все рефакторить, на это к сожалению ресурсов нет. Что бы использовали, ниже ответил, что все зависит от задач. Так как нам нужно SEO (SSR), то использовали NextJS, скорее всего на PageRouter-е, но писали бы код так, что бы потом было просто мигрировать на AppRouter
Насчёт серверных компонентов не понял претензию. Наооборот это лучше, чем тащить килобайты JavaScript и ждать пока этот JavaScript отрисует интерфейс. А так можно получить готовую HTML и вуаля.
Все зависит от задач же. Если нужно SEO (= SSR), то NextJS (можно посмотреть на альтернативы конечно, но NextJS по развитию вырывается вперед). А какую архитектуру, хороший вопрос. Я придерживаюсь мнения, если проект не критичный для бизнеса, то можно без проблем пробовать новую архитектуру на AppRouter. В ином же случае PageRouter, но писать код так, что бы в дальнейшем было просто перейти на новую архитектуру (например, разделять серверный стейт (кеши запросов), и клиентский для логики на клиенте).
Спасибо за выступление, интересные мысли.
16:33 статически можно собрать, получить куки и хэдеры можно, это ж базовые вещи, странно что такое просочилось в доклад
26:29 - Не совсем понял претензию про контексты: почему их нет в app router?
По-моему любой стейт менеджер можно подружить с этой архитектурой. Важно только вынести компонент инициализации контекста в отдельный файл и прописать 'use client'; В дальнейшем все серверные компоненты можно передавать как children.
Единственное ограничение - вы не можете пользоваться этим контекстом в серверных компонентах. Вообще серверные компоненты - это про другой подход к построению приложения. Я их воспринимаю просто как способ что-то сделать на сервере и отдать полученное на клиент без возможности изменения. Любое изменение в серверном компоненте должно подразумевать очередной запрос на сервер.
7:38 такое легко делается через кастомный сервер
12:04 аналогично, некстовые либы возвращают хендлер, который работает с дефолтными нодовскими req и res, делай с ним что хочешь, хоть на express повесь, хоть на fastify
кастомный логер для логирования некстовых сообщений, правда не добавишь (глобально костылить только типа console.log = () => ... или патчить файлы)
рекомендация использовать page router жесть, может классовые компоненты тогда ещё? никто не будет в будущем сильно поддерживать page router, а новые функции будут в app router, тем более когда уже столько времени потратили на него. пока оставили page, чтобы люди успели мигрировать на app
там же написано: для SSR, app router это по дефолту RSC, это не совсем SSR
@@endlesslysorrow ну если идейно устаревший ssr нужен ради того, чтобы ответы были пререндерены именно на сервере, а не для того, чтобы решать современные проблемы и совмещать разные подходы и при всем этом решать все те же проблемы, что и чистый ssr, то ок)
все же непонятно их сдерживает сложность перехода на новую архитектуру, а если бы сейчас начинали, то какую использовали бы или вообще не нэкст,
Сдерживает то, что придется все приложение переписать. У нас толстый клиент и много логики перенесено на клиент. Из-за этого активно используется редакс и для перехода на AppRouter придется почти все рефакторить, на это к сожалению ресурсов нет. Что бы использовали, ниже ответил, что все зависит от задач. Так как нам нужно SEO (SSR), то использовали NextJS, скорее всего на PageRouter-е, но писали бы код так, что бы потом было просто мигрировать на AppRouter
@@typingaway спасибо за пояснения
Он точно техлид?))0))
Насчёт серверных компонентов не понял претензию. Наооборот это лучше, чем тащить килобайты JavaScript и ждать пока этот JavaScript отрисует интерфейс. А так можно получить готовую HTML и вуаля.
А зачем нам в таком случае некст? Берём генератор статики, получаем готовый хтмл и вуаля
@@izzy7541 SSR
@@izzy7541 , генератор статики это кто, если не секрет?
@@izzy7541 с такими развернутыми комментариями можно предложить просто в html файлик все писать
В таком случае нужна серверная инфра, которая будет заниматься генерацией хтмлок, в отличие от SPA
18:10 * ещё Remix и Gatsby
27:57 а на какой архитектуре писать с нуля?
Все зависит от задач же. Если нужно SEO (= SSR), то NextJS (можно посмотреть на альтернативы конечно, но NextJS по развитию вырывается вперед). А какую архитектуру, хороший вопрос. Я придерживаюсь мнения, если проект не критичный для бизнеса, то можно без проблем пробовать новую архитектуру на AppRouter. В ином же случае PageRouter, но писать код так, что бы в дальнейшем было просто перейти на новую архитектуру (например, разделять серверный стейт (кеши запросов), и клиентский для логики на клиенте).
Чет я вообще не понял про куки в next rsc. Да и как-то уже не хочется использовать page router.
Из-за стриминга есть проблемы с куками, ишьюсы можете найти
Что такого в page router? Он стабилен, в нем работает вся экосистема реакта, подход к созданию приложений типичный и понятный для всех разработчиков