Спасибо за видео, Айюб! Круто послушать такое развёрнутое мнение ✨ обычно на твои вопросы отвечаю сам, потом сравниваю с твоим пониманием Действительно, истина где-то посередине 💪 Успехов, пожалуйста, продолжай! 🎉🎉🎉
Мне было интересно увидеть как оно передает данные, какой html приходит, стриминг наверное можно увидеть если запросить через какой-нибудь curl, как вызываются серверные действия, в общем больше подкапотных подробностей.
Да, самому тоже интересно, но еще не успел разобраться. Планирую отдельные видео делать на эту тему. По формату в демках от команды React был формат на jsx похожий. Но в некст может быть есть какие-то особенности.
29:00 по идее если не рендерить динамические компоненты на сервере а передавать в пропсы все тудушки то удаление будет моментальным, просто нужно отправлять отдельный запрос на сервер для удаления тудушки и получения обновлённых данных
Тоже верно. Но тогда и почти все в туду листе будет клиентским компонентом. Не уверен, что в таком случае будет сильный профит. Надо на более большом приложении смотреть.
Айюб а подскажи пожалуйста, все манипуляции с серверными компонентами, происходят по умолчанию, как замена getServerSideProps, теперь только вместо него мы получаем данные 'внутри серверного компонента', а для клиентских пишется строка c указанием, что это клиентский компонент ? А для React, тоже будет же работать ? В расширении файла надо писать *server.jsx или client.jsx ? (на хабре читал) Айюб хотел еще добавить, по поводу качества контента. Речь стала менее беглой, что не может не радовать. Один нюанс если можно попробуй пожалуйста, когда идет твое повествование, не прыгай СИЛЬНО ПО КОДУ (скроллинги, выделение текста, различные перемещения.. ) - это создаёт дополнительный дискомфорт для быстрого понимания. А в целом благодарю отличный контент делаешь!
По поводу серверных компонентов - да, они делают getServerSideProps не нужными. Но помимо этого у тебя появляются более расширенные возможности (меньше бандл, ререндер на сервере и тд). В обычном React работать будет, но, как я и говорил в уроке, нужен отдельный setup сервера + сборки + клиента с роутингом. То есть самому использовать будет не совсем удобно. По поводу расширений, насколько я понял нет. Сборщик сам компилит все компоненты, как серверные. За исключением тех, где есть 'use client'. По поводу качества - рад, что заметен прогресс. Да, с прыганием и выделением есть плохая привычка. Это причем не только во время записи видео у меня, даже когда сам пишу/читаю что-то есть такая проблема) В общем, буду исправлять, спасибо за фидбэк!
Я еще не посмотрел до конца, как только время будет обязательно посмотрю, но данный момент у меня появилось вопрос , React , server components , это типа React постепенно становится бэкэндом ?
Не совсем. Теперь у тебя есть опция рендерить твои компоненты на беке, там же и запросы нужные делать. По сути библиотека расширила свои возможности рендеринга.
Наконец Айюб добрался до next)) Я до сих пор удивлён, почему только 25-30% разрабов юзают next в соотношении с react. К моему сожалению на текущем месте работы next никому не интересен ((
Скорее всего работаешь с командой, где люди постарше) Молодым разработчикам зачастую интереснее писать на новом, сам в команде, где от саг не хотят отказываться, не то что уже и next юзать😄
Мне кажется это связанно с тем, что если ты пишешь настоящее веб приложение - то толку от next.js мало. Скорее наоборот сложности добавляет. Да, можно тут найти пользу в том, что запросы отправляются раньше. Человек сразу видит данные. Но это небольшим сервером на node.js решить можно (опять же, для реальных spa, где всегда один html отдается).
Ну и проекты тоже разные. Next.js относительно недавно стал популярен. Вообще на западе прям много где требуют. Да и проекты новые в основном на нем делают. Просто большинство людей работают над более старыми проектами.
Привет,а у тебя есть ещё проекты на новинки react 18?, мне просто проект в вузе надо сделать о новинках react 18 и сравнить их с react 17, я ушёл в разработчики бд и мне эта тема,к сожалению, не очень близка(Фронт), а отчисляться не хочется, поэтому ищу способы сделать это с помощью ютуба и гита). Или у тебя может даже есть проекты прям по сравнению react 17 и react 18
Здравствуйте. Спасибо за такой качественный разбор стало понятно. У меня вопрос а что если нужно изменить не параметры а сам путь но используя тот же подход рендеринг на сервере. Интересно это возможно?
Получается некое размазывание логики между бэком и фронтом. Стирание четкого разделения границ отвественности., что будет вести к антипаттернам в работе. Начнем в базу напрямую лезть и кричать что это единый источник истины))) Сначала наделаем ошибок, потом героические будем их решать, наполняя хабр все новыми статьями КАК НАДО. А там еще не все хуки то стандратные разобрали КАК НАДО. А реакт уже свеженького подкидывает))))
Тут надо было по-быстрому сделать MVP на пару страниц, но с простейшим беком. Выбрал Next, но запросы делал не через серверные компоненты, а через api возможности некста. Таким образом, бек и фронт развязаны, можно заменять их на другие технологии. Т.е. Next брался, чтобы не поднимать еще и бек отдельно - показалось, что будет проще и при старте и при деплое.
Да, это тоже показалось странным. Реакт по сути дает возможность писать всю бекенд логику в рамках компонентов, что не очень хорошо. Но я думаю у них подход такой - мы даем тебе инструменты, а на архитектуру ты сам смотри. Мне кажется, что если и использовать серверные компоненты, то только как BFF. То есть да, преимущества есть, но надо все равно относится ко всем серверным компонентам, как к фронт-части. Но не думаю, что этого будут все придерживаться...
Честно говоря, выглядит довольно странно. Как будто мы и раньше так могли сделать с применением ssr и при этом получали профит - SEO оптимизацию, а тут нам возвращается обычный jsx, сгенерированный на бэке. Выглядит как какое-то усложнение 🤔
Да, мне тоже так казалось в начале, даже в прошлых видео говорил об этом. Но плюсы тоже есть по сравнению со старым подходом: - Более удобный запрос данных на беке - Тот же ssr до сих пор есть, зато на клиент приходит меньше компонентов, вся статическая часть твоего дерева остается на беке - Можно оставить часть тяжелый библиотек на сервере
Знать бы, что под капотом в бандле, чтобы всё это работало? Чтобы роутеры понимали как и что грузить, обрабатывать формат рендера, как различать методы которые на самом деле вызовы методов на сервере... какой-то прикрытый ужас. А проблема то какая? Всегда можно что-то рассчитать посчитать на сервере и вернуть через апи.
Как на сервере рендерится только конкретный компонент? Когда в поле поиска вводишь текст, уходит запрос на сервер для рендера компонента.. компонент же в дереве приложения находится, серверу нужно снова создать это дерево, найти в нём нужный компонент и рендерить его или рендерится всё приложение но вернется вёрстка одного компонента?
Я посмотрел примеры и появился вопрос. Могу ли я в серверных экшенах не делать API запрос на другой сервер, а выполнять там бизнес логику работы с БД. Т.е вместо того чтобы вызвать еще один запрос на удаление TODO я просто сделал бы что то вроде Todo.deleteById(id) (Это ORM модель, которая работает напрямую с БД через SQL запросы)?
У меня бложик написан на нексте 12. Страницы бложека создаются динамически из md файлов. Если переписать сайт на 13.4, то из-за серверных компонентов сайт должен стать быстрее?
В первую очередь, как уже написали, тебе нужен static site generation (ssg). В 12-м нексте у тебя генерировалась сразу же статика, но все равно все скрипты подгружались и гидрировали html на клиенте. Мне кажется тут основной вопрос в том, будет ли подгружаться меньше скриптов, если ты сделаешь ssg своих серверных компонентов. На первый взгляд кажется, что да. Но на 100% не уверен, надо замерять.
Попробовал - 💩 Теряется декларативный подход, ломается гибкость в переиспользовании компонентов, и ни под одну из ныне пополярных в реакте архитектур это безболезненно не встроить. 10 дизлайков из 10
Отталкиваться надо от юзкейсов, для туду листа серверный рендеринг нафиг не нужен, там где это нужно страницы должны быть ближе к статике и примеры нужны соответствующие, например, как из этого можно было бы собрать интернет магазин, какой-нибудь слайдер с картинками товара, которые одновременно будут отдаваться как статика для поиска и красиво пролистываться для пользователя.
По поводу кейсов согласен, но смысл в том, что тот же ecom не сильно отличаться то будет. Например страница результатов. Экшен добавление товара в корзину будет похож на обновление туду элемента. Слайдер -- это просто клиентский компонент, который на вход получает массив картинок. Поиск тоже похож будет, но туда еще добавятся фильтры. То есть в целом примера то достаточно должно быть для понимания особенностей. Ecom даже более динмический. Там нужно в корзину наверху синкать товары и тд.
@@ayub_begimkulov я имел ввиду как сделать слайдер с картинками, которые проиндексирует поисковик, в старом ssr это была не проблема, отдается статика, а на клиенте гидратация
@@oWeRQ666 Сейчас если использовать next - то это также работает. Твои клиентские компоненты будут на сервере рендериться в статику, а на клиенте уже гидрироваться. То есть в плане SEO тут ничего не теряется. Просто получается, что часть компонентов теперь могут рендериться только на сервере.
По-моему как раз таки наоборот: намного более мощный роутер, серверные компоненты (да-да, это плюс, очень советую всё же разобраться) которые помимо своих "серверных" фичей заменяет getServerSideProps() на супер упрощённую модель. Всегда можно добавть 'use client' в любой компонент и он начнёт себя вести абсолютно идентично тому как было раншье.
Я смотрю на это так, что если ты делаешь полностью клиентские приложения, то ничего не должно меняться. А если делаешь серверные -- то кажется плюсы должны быть значимые. Но 100% станет хотя бы чут-чуть сложнее, нужно будет понимать больше концептов. Интересно конечно, как это все дальше будет развиваться)
Супер интересно про серверные компоненты и полезные примеры! Спасибо за видео! 🙏
Спасибо за видео, Айюб! Круто послушать такое развёрнутое мнение ✨ обычно на твои вопросы отвечаю сам, потом сравниваю с твоим пониманием
Действительно, истина где-то посередине 💪
Успехов, пожалуйста, продолжай! 🎉🎉🎉
Спасибо за фидбэк!
Спасибо за конкретные примеры! Смотрел несколько видео, сейчас стало все максимально понятно.
Рад помочь!
Спасибо за видео и разбор. Насчет возврата в 2000е. Никакого возврата, мы продолжаем писать на Php + Vue/React 😬
То же самое: пишем проекты на Laravel + React/Vue)
ну здесь я под возвратом подразумеваю именно рендеринг темплейтов на сервере, без апи запросов)
Говорят Laravel и сам PHP -- это разные вещи))
Очень ждал подобное видео, спасибо
Не за что!
ура новая видео
Мне было интересно увидеть как оно передает данные, какой html приходит, стриминг наверное можно увидеть если запросить через какой-нибудь curl, как вызываются серверные действия, в общем больше подкапотных подробностей.
Да, самому тоже интересно, но еще не успел разобраться. Планирую отдельные видео делать на эту тему. По формату в демках от команды React был формат на jsx похожий. Но в некст может быть есть какие-то особенности.
29:00 по идее если не рендерить динамические компоненты на сервере а передавать в пропсы все тудушки то удаление будет моментальным, просто нужно отправлять отдельный запрос на сервер для удаления тудушки и получения обновлённых данных
Тоже верно. Но тогда и почти все в туду листе будет клиентским компонентом. Не уверен, что в таком случае будет сильный профит. Надо на более большом приложении смотреть.
Айюб а подскажи пожалуйста, все манипуляции с серверными компонентами, происходят по умолчанию, как замена getServerSideProps, теперь только вместо него мы получаем данные 'внутри серверного компонента', а для клиентских пишется строка c указанием, что это клиентский компонент ?
А для React, тоже будет же работать ? В расширении файла надо писать *server.jsx или client.jsx ? (на хабре читал)
Айюб хотел еще добавить, по поводу качества контента. Речь стала менее беглой, что не может не радовать. Один нюанс если можно попробуй пожалуйста, когда идет твое повествование, не прыгай СИЛЬНО ПО КОДУ (скроллинги, выделение текста, различные перемещения.. ) - это создаёт дополнительный дискомфорт для быстрого понимания.
А в целом благодарю отличный контент делаешь!
По поводу серверных компонентов - да, они делают getServerSideProps не нужными. Но помимо этого у тебя появляются более расширенные возможности (меньше бандл, ререндер на сервере и тд).
В обычном React работать будет, но, как я и говорил в уроке, нужен отдельный setup сервера + сборки + клиента с роутингом. То есть самому использовать будет не совсем удобно. По поводу расширений, насколько я понял нет. Сборщик сам компилит все компоненты, как серверные. За исключением тех, где есть 'use client'.
По поводу качества - рад, что заметен прогресс. Да, с прыганием и выделением есть плохая привычка. Это причем не только во время записи видео у меня, даже когда сам пишу/читаю что-то есть такая проблема) В общем, буду исправлять, спасибо за фидбэк!
@@ayub_begimkulov 🙏 Тебе спасибо!!!
шикарная инфа
Я еще не посмотрел до конца, как только время будет обязательно посмотрю, но данный момент у меня появилось вопрос , React , server components , это типа React постепенно становится бэкэндом ?
Не совсем. Теперь у тебя есть опция рендерить твои компоненты на беке, там же и запросы нужные делать. По сути библиотека расширила свои возможности рендеринга.
🎉🎉🎉🎉🎉
Наконец Айюб добрался до next))
Я до сих пор удивлён, почему только 25-30% разрабов юзают next в соотношении с react. К моему сожалению на текущем месте работы next никому не интересен ((
Скорее всего работаешь с командой, где люди постарше) Молодым разработчикам зачастую интереснее писать на новом, сам в команде, где от саг не хотят отказываться, не то что уже и next юзать😄
Мне кажется это связанно с тем, что если ты пишешь настоящее веб приложение - то толку от next.js мало. Скорее наоборот сложности добавляет. Да, можно тут найти пользу в том, что запросы отправляются раньше. Человек сразу видит данные. Но это небольшим сервером на node.js решить можно (опять же, для реальных spa, где всегда один html отдается).
Ну и проекты тоже разные. Next.js относительно недавно стал популярен. Вообще на западе прям много где требуют. Да и проекты новые в основном на нем делают. Просто большинство людей работают над более старыми проектами.
@@ayub_begimkulov, в плане можно сделать ssr без next-а несложно? Интересно, как это сделать
Привет,а у тебя есть ещё проекты на новинки react 18?, мне просто проект в вузе надо сделать о новинках react 18 и сравнить их с react 17, я ушёл в разработчики бд и мне эта тема,к сожалению, не очень близка(Фронт), а отчисляться не хочется, поэтому ищу способы сделать это с помощью ютуба и гита). Или у тебя может даже есть проекты прям по сравнению react 17 и react 18
Здравствуйте. Спасибо за такой качественный разбор стало понятно. У меня вопрос а что если нужно изменить не параметры а сам путь но используя тот же подход рендеринг на сервере. Интересно это возможно?
Получается некое размазывание логики между бэком и фронтом. Стирание четкого разделения границ отвественности., что будет вести к антипаттернам в работе. Начнем в базу напрямую лезть и кричать что это единый источник истины)))
Сначала наделаем ошибок, потом героические будем их решать, наполняя хабр все новыми статьями КАК НАДО. А там еще не все хуки то стандратные разобрали КАК НАДО. А реакт уже свеженького подкидывает))))
Тут надо было по-быстрому сделать MVP на пару страниц, но с простейшим беком. Выбрал Next, но запросы делал не через серверные компоненты, а через api возможности некста. Таким образом, бек и фронт развязаны, можно заменять их на другие технологии. Т.е. Next брался, чтобы не поднимать еще и бек отдельно - показалось, что будет проще и при старте и при деплое.
Да, это тоже показалось странным. Реакт по сути дает возможность писать всю бекенд логику в рамках компонентов, что не очень хорошо. Но я думаю у них подход такой - мы даем тебе инструменты, а на архитектуру ты сам смотри.
Мне кажется, что если и использовать серверные компоненты, то только как BFF. То есть да, преимущества есть, но надо все равно относится ко всем серверным компонентам, как к фронт-части. Но не думаю, что этого будут все придерживаться...
Да, такой подход кажется самым правильным.
Честно говоря, выглядит довольно странно. Как будто мы и раньше так могли сделать с применением ssr и при этом получали профит - SEO оптимизацию, а тут нам возвращается обычный jsx, сгенерированный на бэке. Выглядит как какое-то усложнение 🤔
Да, мне тоже так казалось в начале, даже в прошлых видео говорил об этом.
Но плюсы тоже есть по сравнению со старым подходом:
- Более удобный запрос данных на беке
- Тот же ssr до сих пор есть, зато на клиент приходит меньше компонентов, вся статическая часть твоего дерева остается на беке
- Можно оставить часть тяжелый библиотек на сервере
🎉🎉❤❤
четкая бицуха на обложке)))
Знать бы, что под капотом в бандле, чтобы всё это работало? Чтобы роутеры понимали как и что грузить, обрабатывать формат рендера, как различать методы которые на самом деле вызовы методов на сервере... какой-то прикрытый ужас. А проблема то какая? Всегда можно что-то рассчитать посчитать на сервере и вернуть через апи.
Разве быстрее ждать рендер компонента на сервере, грузить его вёрстку, чем сделать запрос к АПИ и получить чисто данные?
Как на сервере рендерится только конкретный компонент? Когда в поле поиска вводишь текст, уходит запрос на сервер для рендера компонента.. компонент же в дереве приложения находится, серверу нужно снова создать это дерево, найти в нём нужный компонент и рендерить его или рендерится всё приложение но вернется вёрстка одного компонента?
Я посмотрел примеры и появился вопрос. Могу ли я в серверных экшенах не делать API запрос на другой сервер, а выполнять там бизнес логику работы с БД. Т.е вместо того чтобы вызвать еще один запрос на удаление TODO я просто сделал бы что то вроде Todo.deleteById(id) (Это ORM модель, которая работает напрямую с БД через SQL запросы)?
да, можешь
Да, там можно делать что угодно. Это просто асинк функция, которая запускается на бекенде.
32:30 Ничего странного нет. Это основная концепция компонентно-ориентированной модели React
render functions это code smell
У меня бложик написан на нексте 12. Страницы бложека создаются динамически из md файлов. Если переписать сайт на 13.4, то из-за серверных компонентов сайт должен стать быстрее?
Что за такое MD файлы?
@@combodia123 markdown файлы. В них удобно редактировать текст и конвертировать текст из этого формата в html / jsx на сайте
SSG же есть, а он быстрее всего
В первую очередь, как уже написали, тебе нужен static site generation (ssg). В 12-м нексте у тебя генерировалась сразу же статика, но все равно все скрипты подгружались и гидрировали html на клиенте.
Мне кажется тут основной вопрос в том, будет ли подгружаться меньше скриптов, если ты сделаешь ssg своих серверных компонентов. На первый взгляд кажется, что да. Но на 100% не уверен, надо замерять.
Попробовал - 💩
Теряется декларативный подход, ломается гибкость в переиспользовании компонентов, и ни под одну из ныне пополярных в реакте архитектур это безболезненно не встроить. 10 дизлайков из 10
Отталкиваться надо от юзкейсов, для туду листа серверный рендеринг нафиг не нужен, там где это нужно страницы должны быть ближе к статике и примеры нужны соответствующие, например, как из этого можно было бы собрать интернет магазин, какой-нибудь слайдер с картинками товара, которые одновременно будут отдаваться как статика для поиска и красиво пролистываться для пользователя.
По поводу кейсов согласен, но смысл в том, что тот же ecom не сильно отличаться то будет.
Например страница результатов. Экшен добавление товара в корзину будет похож на обновление туду элемента. Слайдер -- это просто клиентский компонент, который на вход получает массив картинок. Поиск тоже похож будет, но туда еще добавятся фильтры.
То есть в целом примера то достаточно должно быть для понимания особенностей. Ecom даже более динмический. Там нужно в корзину наверху синкать товары и тд.
@@ayub_begimkulov я имел ввиду как сделать слайдер с картинками, которые проиндексирует поисковик, в старом ssr это была не проблема, отдается статика, а на клиенте гидратация
@@oWeRQ666 Сейчас если использовать next - то это также работает. Твои клиентские компоненты будут на сервере рендериться в статику, а на клиенте уже гидрироваться. То есть в плане SEO тут ничего не теряется. Просто получается, что часть компонентов теперь могут рендериться только на сервере.
Как я понимаю это станет стандартом, как в 2020 стали хуки)
Вот даже не знаю, кажется, что push-back от комьюнити в этот раз намного хуже, чем это было с хуками.
Что у тебя за кресло?
Я сам не знаю. Купил на местном рынке техники. Что-то с китая, но мне нравится)
@@ayub_begimkulov 🤣🤣🤣
React Rip 😢
Nuxt server components 💪💪💪
А чем nuxt в этом плане лучше? Это же вообще другой фреймворк) (Vue)
Не знаю, какую проблему это решает, но разработка становится сложнее
По-моему как раз таки наоборот: намного более мощный роутер, серверные компоненты (да-да, это плюс, очень советую всё же разобраться) которые помимо своих "серверных" фичей заменяет getServerSideProps() на супер упрощённую модель. Всегда можно добавть 'use client' в любой компонент и он начнёт себя вести абсолютно идентично тому как было раншье.
@@stashladki2594 что мощного в этом роутере чего так не хватало в нынешней разработке? Что сложного в gssp?
@@stashladki2594 я тоже так думал, пока не начал писать приложение ))
Я смотрю на это так, что если ты делаешь полностью клиентские приложения, то ничего не должно меняться. А если делаешь серверные -- то кажется плюсы должны быть значимые.
Но 100% станет хотя бы чут-чуть сложнее, нужно будет понимать больше концептов. Интересно конечно, как это все дальше будет развиваться)
Сложнее до того момента, пока нет готового кода
С чего у тебя становятся компоненты более связанными? У тебя компоненты теперь по факту не знают о друг друге вообще, ахахахах
Vue гораздо лучше реакта. Как и в читабельности, так и в кодинге.
тут кто к чему привык)