Абсолютно новое мышление с Server Components

[@SergiySev]

Ура, React теперь PHP!

[@it-sin9k]

Ага) много таких комментов слышал)

[@enmaboya]

а PHP, в частности Laravel, благодаря Volt, очень пытается стать чем-то вроде Vue

[@SergeyPerestoronin]

Разработка с RSC превратила у меня работу в квест: как написать код так, чтобы не делать компонент пользовательским. Пришлось щепетильно выбирать библиотеки стилизации и прочие, чтобы они имели поддержку RSC. К сожалению таких стабильных библиотек очень мало. Некотороые просто прикидываются, что поддерживают RSC, а на самом деле вынуждают делать компоненты пользовательскими. Открыл для себя недавно, что адресная строка отлично подходит для сохранения состояния и позволяет при этом не делать компонент пользовательским!😂

[@alexs7931]

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

[@joyStackk]

Согласен мне кажется рано еще на проде заниматься таким большинство компонентов клиентские как правило ладно лендос какой но с огромной логикой прям для веб приложения тяжко будет и оч дорого, делать везде сервер рендеринг - чисто мой опыт

[@РежиссёрВова]

Теперь понятно, почему консоль выводит 2 раза лог на 1 событие. Да и вообще, у тебя талант объяснять сложные архитектурные вещи простыми словами! Спасибо большое, ты очень полезен, пожалуйста продолжай делать подобные видео!

[@it-sin9k]

Спасибо большое!) такие комменты очень помогают продолжать создавать новые видео) огромное спасибо!)

[@fadilmamedov2844]

Если вы про браузер, то это скорее всего из-за StrictMode

[@virtual5754]

Использую серверные компоненты в проде уже год, с самого релиза 13 версии. Как таковых проблем с ними нет. Есть баги самого некста, который время от времени что-то ломает, и приходится пропускать несколько минорных версий (и потом оперативно наверстывать прогресс). Из сложностей - да, та самая невозможность напрямую импортировать серверный компонент в клиентский. Иногда нужно один и тот же компонент оставить статическим в одном месте, но сделать интерактивным в другом, тогда проще и быстрее продублировать код - на производительность не влияет, но проект захламляет. И самая скучная сложность - необходимость убирать все лишние данные при переходе из серверного компонента, где теоритически можно оперировать мегабайтами json данных от cms без потерь в производительности, в клиентский, где каждое лишнее свойство в объекте означает лишний трафик и лишнюю задержку. А от меня запрос - большое и основательнео видео про миграцию с redux на zustand. Прошу не для себя (я все проекты сразу делаю на zustand), а скорее для комьюнити - чем раньше популяризуем действительно классный инструмент, тем быстрее на него будут переходить, тем меньше мы будем сталкиваться с необходимостью работать со старыми технологиями.

[@it-sin9k]

Спасибо за фидбек и за запрос! Про Zustand и mobx есть много запросов, обязательно до них доберусь!

[@foo44444]

я настрал со стола прямо в ведро с реактом

[@tomitomion1179]

Привет, отличное видео как всегда! Тема пока сырая, думаю еще не раз придется снимать видео ))) Стоило еще упомянуть стриминг компонентов, по мне это пока самая полезная фишка

[@it-sin9k]

да) думаю про стриминг еще сделать отдельное видео)

[@mourat9833]

Все знал, но не помнил деталей. Спасибо, хорошо рассказал.

[@frontend_course]

Теперь 1) добавь куки 2) получи хедеры 3) сделай так что бы запрос был на сервере, но при подгрузке еще и обратного перехода на страницу он был на клиенте 4) хоть как-то заиспользуй кастомный сервер 5) посчитай на сколько больше ты заплатишь за сервер 6) убеди текущий бек переехать на кучу запросов что бы компоненты по разному делать 7) большинство кода будет всегда в главном бандле, потому что очень много кусков глобальны

[@Владимир-д9и7о]

Спасибо! Больше про next.js, пожалуйста!

[@it-sin9k]

Накидывайте темы про next js) будем записывать)

[@eliassmith7949]

@@it-sin9kresfresh tokens с кастомным бекендом

[@DenInside]

Ща пишу прожект на серверных компонентах на прод, мне все нравится Из-за использования серверных компонентов практически отказался от скелетонов, т.к при первой загрузке страницы сразу же есть вся нужная дата, и в целом запросы оч быстро проходят Столкнулся с такой проблемой: У меня навигация на сайте слева, а справа контент. Блок навигации у меня серверный и мне нужно было сделать так, чтобы при нажатии на бургер, в мобильной версии сайта, происходила анимация навигации. Анимация должна была происходить по изменению стейта, все, что я придумал - создать клиентский компонент- обёртку, который принимает в себя чилдренов, обернуть им компонент навигации и в этом клиентском компоненте ей управлять. Кста, зустанд вообще топ тема с некстом и серверными компонентами, тупа стейт менеджер без боли

[@it-sin9k]

Спасибо за подробный комментарий! Еще раз себе помечу, чтобы быстрее к зустанду перейти)

[@MykolaVladymyrskiy]

Больш дзякуй за вашыя відэа Вельмі рады, што сустрэў ваш канал. 😁😁

[@it-sin9k]

Добро пожаловать на канал!) Надеюсь найдете для себя много полезного)

[@go_better]

Спасибо. Я правда фигею, как всё красиво и сразу по делу. Да ещё и понятно.

[@izzy7541]

Глядя на то как теперь некст (и в общем-то RSC) предлагает работать с компонентами, возникает сразу вопрос - а не много ли условий? Чтобы ускорить отрисовку контента, они придумали RSC и прибили гвоздями реакт к ноде? А зачем? В чём разница между пререндером + CSR и серверными компонентами по факту? И там и там весь интерактив содержится в клиенте, хтмл всегда статичный. Не понятно. Просто не вижу смысла раскатывать весь огромный некст чтобы просто получить тот же пререндер статики + CSR компоненты с интерактивом. Так что у меня сомнения. Либо это один маленький этап реализации новой архитектуры, которая решит все проблемы реакт приложений, либо это прикол и чуваки решили переизобрести пререндер и добавить лишний жирный слой с нодой, чтобы продавать больше подписок на vercel 🧐. Будем посмотреть.

[@владимирсенцов-р1ю]

Гыы они придумали шаблонизатор. Гении однако.

[@Serhiisega057]

Спасибо за видео! На первый взгляд не понятно что делать с серверным компонентом, который грузит шоу, если по какой-то причине нужно получить список шоу заново. Есть ли удобные способы повторно вызывать серверный компонент и соответственно заново грузить список шоу?

[@it-sin9k]

хмм, я думаю теперь флоу будет следующим. Серверные компоненты грузят первоначальные данные, а дальше, если тебе на клиенте нужно обновить список Shows, тогда ты в клиентском компоненте отправляешь запрос и обновляешь их, без участия серверного компонента

[@Smerch-wm5oc]

Заснул быстро..проспал крепко. . Выспался хорошо😊

[@shrekpar]

Класс, очень интересно!

[@romanveryovkin6813]

Спасибо за видео! Респект👍

[@ОлегСелин-ш9ы]

Пока всё это выглядит очень сыро. В теории можно конечно сделать компонет инициализации, который на сервере получит пласт нужных данных. Затем прокинуть в клиентский, который создаст store или контекст при необходимости. Получается какой то гибрид продвинутого шаблонизатора и клиентского приложения.

[@it-sin9k]

да) пока эксперементируют в поиске истины) дождемся устоявшихся стандартов)

[@Plintthes]

Спасибо за проделанную работу. Хотелось бы подробнее обзор. Как это под капотом работает, как некоторые компоненты могут доставляться (через JSON или как). Какие best-practise теперь

[@it-sin9k]

спасибо!) буду еще делать видео)

[@ВиталийКучер-о6ю]

Боже, куда катится веб... Это же, полная жесть 😢😢😢 Надеюсь многие просто проигнорируют этот высер команды Абрамова

[@it-sin9k]

Почитал комментарии, кажется многие уже пользуются и более менее нормальный полет) может не так все плохо?)

[@kitN]

Хоть кто тут адекватно смотрит на эти "киллерфитчи"

[@РоманНарожнов]

Спасибо за видео! У меня не большой опыт, я в качестве серверных компонентов использовал только компоненты страницы для ускорения получения данных и отрисовки, которые уже пропсами раздавали эти данные в клиентские компоненты, а те в свою очередь уже динамили (при необходимости) то что нужно.

[@it-sin9k]

Спасибо за комментарий!

[@erxweo]

В связке с FSD очень удобно фичи делаешь клиентскими сущности по большей части серверными, ну а виджеты со страницами в основном серверные. Мне кажется когда они пилили серверные компоненты ориентировались именно на эту архитектуру

[@it-sin9k]

Спасибо за то что поделились мыслями!

[@kawaikaino5277]

FSD и "очень удобно" это разные вещи. Притащил, этот ваш FSD в проект) теперь стреляем себе в ноги, т.к тратим время на споры, что и куда разместить

[@erxweo]

@@kawaikaino5277 fsd это не про миграции и не про проекты в стиле идем в своем темпе и порядке. Fsd это про поэтапную продуманную разработку. Так что дело не в архитектуре, а в вашей неопытности

[@erxweo]

@@kawaikaino5277 ну а если простыми словами, на кой ты его в проект потащил? Обычно проект начиная с аналитики и дизайна делают под fsd, а ты все наоборот сделал. Отсюда и проблемы

[@artemzhuravlenko9955]

Спасибо за видео! Хотелось бы также подробнее услышать, как работают клиентские компоненты. Судя по тому, что ты описал они работают через SSR. Так ли это?

[@it-sin9k]

Клиентские рендерятся сначала на сервере, а потом еще раз рендерятся на клиенте. Т.е. как привычный нам SSR :)

[@dvdrelin]

Время на рендер того запроса, который отдает все серверные компоненты будет увеличен естественным образом, т.к. ему , запросу, теперь ходить в сторадж за всем тем, за чем ходил каждый из компонентов. Это как раз, то из-за чего монолит на ssr бьётся на микромодули на csr ;) Да, можно обслужить подобные запросы в сторадж параллельно, но это некий оверхед который нужен явно, против органичного поведения при грамотной декомпозиции в случае csr

[@it-sin9k]

да, проблема есть такая. Но что приятно, данные можно кэшировать и даже сами html конечные можно кэшировать) и пока грузится, есть варианты показать loading. Поэтому люди работают над решением этой проблемы)

[@dvdrelin]

@@it-sin9k истина, как обычно, где-то посередине, и у каждого своя)

[@InstituteOfIndependence]

Я заметил, что серверные компоненты не отображаются в расширении components в React Dev Tools. Получается они не входят в virtual DOM?!

[@it-sin9k]

Кстати интересное наблюдение, я не проверял. Подозреваю дев тулы строятся во время рендеринга конкретных кусков. А серверные компоненты отрендерились на сервере, поэтому они и не строятся в дев тулс

[@igor_cojocaru]

Спасибо

[@dimitro.cardellini]

ми ще не переїхали на наших nextjs проектах, то ж, швидше я скажу, як це відбувається зараз: при переході між сторінками весь html контент не перезавантажується -- тобто на сервер (при чому так є варіанти) йде запит пропсів, і пейджа рендериться на клаієнті. з сервер-компонентся -- має все працювати так само, лише з тією різнецію, що запит відправляється не за пропсами, а за jsx-ом, і потям вже відбувається рендер того самого jsx. В обох випадках реакт вже знає, яким чином відобразити вірптуальне дерево на реальний DOM -- то, ж якщо правильно все зробити, то і плейер не відвалиться. Але за цим треба дуже уважно слідкувати. Як на мене, то простішим варіантом буде просто завантажити той плейр окремим від головного застосунку бандлом та від рендерити в окремий рут -- тоді переходи поміж сторінок можна здійснювати, не турбуючись про те, що після ре-рендеру плейєр відвалиться.

[@nonamedfreman5537]

Вопрос, а зачем это нужно? Раньше все это делалось и так -> посмотреть какие данные надо отдать с сервера для урла, подготовить их на беке и отдать в html сразу в необходимие сторы молулей?

[@it-sin9k]

тут на самом деле комплексное решение. Серверные компоненты - это лишь одна из фичей. Когда покрою пару ключевых тем, планирую записать отдельное видео о том, почему на мое мнение этот путь был выбран :)

[@nonamedfreman5537]

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

[@jonyonee]

Все трудно с серверными компонентами например мне нужен был скелетон для товаров. Товары у меня были rsc что бы сделать loading пришлось копаться искать как реализовать нашёл в твиттере решение. В нексте его кэш маршрутов бесит невозможно его отключить нормальным способом. Next auth вообще говно.

[@kulakofft4]

на мой взгляд легче не стало)))

[@it-sin9k]

это точно) пока кажется усложняется) или просто мы сопротивляемся новому)

[@YellowManPsypeople]

Спасибо. Как всегда интересно и актуально. Легко и просто разложил работу нового подхода серверных компонентов. А нет ли в некст инструмента перерендрить компонент и сбросить его кэш? Теже пропсы в серверном компоненте будут его обновлять? А если обновиться на сервере компонент он перерисуется на клиенте?

[@it-sin9k]

Спасибо) > А если обновиться на сервере компонент он перерисуется на клиенте? По идее у него нет возможности обновиться, там отключили всю динамику > А нет ли в некст инструмента перерендрить компонент и сбросить его кэш? В самом реакте добавили любопытный кэш, если тема зайдет, буду рассказывать дальше)

[@yokotoka]

Жил-был реакт как классная функционально-реактивная библиотека рендеринга. И сделали из него псевдо-PHP для лапшеобразного говнокода. Прощай, реакт, сейчас тебя похоронят последователи

[@drawerhack1717]

1) реакт никогда не был реактивным. как бы это странно не звучало, но реакт не делается реактивным, если в его название есть корень "реакт" 2) реакт живее всех живых

[@p_levin]

Изобрели функциональные компоненты из vue 2 :)

[@NoName-oh9fh]

Я все надеюсь, когда можно будет клиентский код смешивать с серверным и при билде это разделется и сгенерится апишка.

[@it-sin9k]

Это уже существует) расскажу в следующем видео!)

[@NoName-oh9fh]

@@it-sin9k Серьезно? Например функция, где меняется стейт, выводится уведомление и там же делается запрос к БД напрямую? async function createOrder(data) { try { setState(...) // Client xode await Order.create(data): // Server code toast.success("Success"); // Client code } catch (e) { toast.error(e.message); //Client code } }

[@it-sin9k]

@@NoName-oh9fh Да! Именно про это и будет следующее видео) уже материал весь набросал, осталось смонтировать)

[@NoName-oh9fh]

@@it-sin9k Наконец-то)) Буду с нетерпением ждать твое видео 👍

[@mzpizote]

Расскажи потом как тебе мустанг если возьмешь 😁

[@it-sin9k]

Я теслу купил в итоге)

[@alexs7931]

1:56 а¿

[@Bugagych]

Столько блогеров айтишников, но чот про mobx нет толкового курса! Все о очевидном пишут видео. О микрофронтах тоже только зарубежные пишут. Наши только идут по доке.

[@it-sin9k]

обе эти темы в загашнике лежат) у меня с mobx года 3 опыта) поэтому есть что сказать) постараюсь добраться)

[@Bugagych]

Так скажи уже быстрее) Готов купить курс, в котором обе темы будут раскрыты)@@it-sin9k

[@djubei2265]

@@it-sin9k было бы здорово разобрать mobx на примере проекта , но я так понимаю это не формат канала.

[@it-sin9k]

@@djubei2265 да, обычно мы разбираем технологию по частям небольшим :)

[@slavapol-v1553]

Вот шикарный полный курс по Mobx kzbin.info/www/bejne/r4uTkqqVgbiEmc0

[@ПавелСвенин-ъ4в]

Клиентский компонент не рендерится на сервере. Увидив клиентский компонент next просто вставляет ссылку в код на этот клиентский компонент и всё

[@it-sin9k]

хмм, верится с трудом. В этом же вся суть SSR отдать готовую верстку. Ди и как же он тогда сравнивает результат страницы на клиенте и на сервере. И если есть разница кидает ошибку

[@ПавелСвенин-ъ4в]

@@it-sin9k это фишка сборщика. При рендере на сервере страница вставляет ссылку в поле filename на модуль клиентского компонента. И сериализуемые данные которые приходят с сервера содержат в своей структуре просто ссылки на эти модули, и если клиентский компонент содержит вложенный клиентский компонент, то уже о вложенном компоненте в JSONе (RSC Payload) который приходит с сервера не будет ни каких упоминаний. Сборщик понимает какие клиентские компоненты собирать в один модуль и отдавать на клиент. Только после того как мы получим js клиентского компонента в браузере мы начнем рендер и уже формирование dom.

[@ПавелСвенин-ъ4в]

А чего мой комментарий удалили?

[@it-sin9k]

да, вроде есть ваши комменты :) Вы возможно ссылки вставляли, это youTube может не пропускать) А как в вашей истории рисуется на сервере начальный html файл? он же приходит с отрендереными клиентскими компонентами кроме css стилей, если я правильно понимаю

[@ПавелСвенин-ъ4в]

@@it-sin9k все ок я забыл про первый рендер) спасибо)

[@popuguytheparrot_]

1. Для серверных компонентов не нужен сервер 2. Повторный рендеринг это не основное отличие SSR. Это будет правильно назвать гидратацией. SSR с серверными компонентами другой 3. Композиция компонентов и есть решение. Это еще идет давно и вообще является основополагающей Реакта. Композиция объектов и компонентная модель

[@it-sin9k]

спасибо за комментарий! 1. Подскажите плз как это сделать без сервера? 2. Что для вас является основным отличием?

[@popuguytheparrot_]

@@it-sin9k сейчас не так достаточно документации по react-server-dom-webpack, но тот же Некст жс в статическом режиме заранее рендерит в билдтайме.

[@popuguytheparrot_]

@@it-sin9k основное отличие, что не нужно дожидаться всех данных как с обычным SSR. SSR с RSCs есть возможность доотправить компоненты с данными в уже отправленную оболочку

[@it-sin9k]

@@popuguytheparrot_ т.е. речь идет о чистой статике? можно будет сделать динамику? условно по id пользователя загрузить инфу о нем

[@it-sin9k]

@@popuguytheparrot_ доотправить RSC имеется ввиду стриминг функциональность? или есть еще какие то варианты?

[@HEX_CAT]

❤❤❤🎉🎉🎉

[@nikolaydumchev1483]

Грустно смотреть на то, как уходят от идеи писать и использовать одинаковый код как для клиентской части, так и для серверной. Как по мне effector и его forkApi намного лучшее решения для SSR, чем RSC, который выглядит как шаг назад, в прошлое. Да и еще жесткая привязка к next.js. Запросы из компонент - никогда не нравился этот подход. Что изменилось? Да ничего, только теперь это серверные компоненты. Зачем переносить столько логики на сервер, как это было раньше? Разве от SSR нам не нужен только первый быстрый рендер с данными. Кажется что следовало бы развивать инструментарий для изоморфных приложений, а не перетягивать столько на сторону сервера. Куда vercel нас тащит?

[@it-sin9k]

Честно говоря не знаком с forkApi, поэтому сравнить не могу. Идея же RSC перетянуть как можно больше на сервер и как можно меньше выполнять на клиенте. Это помогает облегчить жизнь пользовательским девайсам и переиспользовать куски на сервере. Но конечно не бесплатно :) Каждый в итоге сам решает нужно ли это его проекту) Но подозреваю фейсбуку нужно) раз они так старательно это тащат))

[@adaltezze]

Вроде как клиентские компоненты тоже можно делать асинхронными

[@it-sin9k]

разве?

[@adaltezze]

@@it-sin9k да, только Suspense'ом обернуть нужно

[@kulakofft4]

@@adaltezze но это будет не то же самое, что серверный компонент.

[@adaltezze]

@@kulakofft4 Я про функционал ничего не писал) Уточнил что клиентские компоненты тоже умеют в асинхрон

[@it-sin9k]

@@adaltezze я честно говоря не пробовал) надо будет потыкать) только чанки грузил через суспенз

[@portusdelphini]

Смешали всё в кучу. Только зачем? Было же нормальное разделение фронт и бек. Короче, это ужасно

[@it-sin9k]

так всегда так и было) мы просто вернулись к этому)

[@vana__f7570]

как сделать лоадер для serverComponents?

[@it-sin9k]

там можно создать файл loader.js. В него кладется компонент, который показывается пользователю до отработки самой страницы :)

[@vana__f7570]

@@it-sin9k я читал про это в документации. Но у меня это не сработало

[@it-sin9k]

@@vana__f7570 Думал про это видео сделать) теперь более уверен, что стоит)

[@convulsion1928]

React suspense?

[@vana__f7570]

Обезательно надо, когда сделаешь? Мне будет приятно если ты сделаешь такое видео@@it-sin9k