🔗 Ссылки: Server Actions: th-cam.com/video/w8QQKEPDY_k/w-d-xo.html Prisma: th-cam.com/video/YoSl5sx-uUU/w-d-xo.html NvChad: th-cam.com/video/Q1gIbPEStL0/w-d-xo.html NVM: th-cam.com/video/Ssbvs2XtzuY/w-d-xo.html 🎓 Курс по Next.js purpleschool.ru/course/nextjs 💬 Telegram канал с полезными советами: t.me/purple_code_channel
Ну в целом я согласен насчет server actions, не особо понимаю почему Next движется в сторону fullstack фреймворка, если большинство его все равно воспринимают, как frontend фреймворк. Очень жду когда partials rendering будет, это намного интереснее
16:54 Что за бред, нет никаких ограничений, не обязательно использовать в action и form, работают они как любая обычная функция с любыми входящими данными не только FormData. Вызывать можно хоть в onClick хоть в useEffect, только тело функции будет не на фронте а на сервере выполняться .. Как и валидация, прям в action добавляется валидация типа через Zod, который великолепно преобразуется в тип typeScripta. Таким образом у вас одна единая модель данных как на фронте так и на бэке 💁🏻♂️
Если вы попробуете вызвать из onClick функцию, в отдельном файле, который даже отмечен как use server и передать туда аргументы, то получите ошибку, так как он будет считать runtime браузерным
@@PurpleSchool У меня целый проект в продакшене уже так работает месяца 4 начиная с экспериментальной версии 13.5. И нет никаких проблем, более того эти server action успешно используются внутри стейт менеджера Zustand
Если нужен отдельный back - пожалуйста - делайте NestJs, и дергайте его из server actions с помощью fetch'а, который расширен next-ом. Преимуществом fullstack является сквозная типизация
@@awenn2015 Это когда несколько проектов в одном репо, обычно под управлением специализированных инструментов, но можно и просто workspaces от npm использовать. Экспортируете типы dto в серверном проекте, клиент их пользует, вот и сквозная типизация. Разумеется полностью от проблем не избавиться так как если рест, например, то надо как то обходится с параметрами вызовов, да и тайпскрипт далеко не идеален, так что все равно накручивают схемы и валидации. Удобство сервер акшенс в том что весь этот лейер передачи данных по апи они прячут за внешним простым вызовом функции. Это и недостаток, так во множестве сценариев требуется понимания и настроек более точных, чем просто вызвать и получить несложный джейсон, а это как раз становится недоступным.
Спасибо за видео! И хотел спросить для создания большого ERP систему что более подходящий react или next? И ещё важный момент, разработчик один, фуллстек разработчик(наверное этот момент тоже влияет..).
Просто Next'у нужно определиться. Они фронтэнд или бекэнд или все вместе но качественно. А то всего по чуть-чуть нахватали и вроде бы работает но через %опу
Да, прям не хватает DI, чтобы все эти коннекшены к БД, редис, очереди, нормальный контекст реквеста и прочее ижектить, а не изобретать костыли. Какого-нибудь слоя сервисов где будет бизнес логика. Не понял есть ли слой middleware, очень часто нужно предварительно работать с реквестом (логировать то что нужно, проверять авторизацию и тп.). Ну и еще много чего не хватает по мелочи. Короче для полноценного бекенда пока слабовато, но вот для небольших сайтов типа блога или сайта ресторана для заказа пиццы-шаурмы без лишних сервисов и интеграций, либо там какой-нибудь внутренний сервис типа админки быстро накидать, я думаю здесь будет топ. Ну и само собой для предварительного рендера реакта для сеошников самый раз.
@un_defined Ахаха точно замечено "об колено". Пикантно, то что этот коммент в ветке про React и NextJs, где сначала поломали разделение между разметкой и кодом, а потом между фронтом и беком. Наверное есть смысл, если народ этим пользуется. Я сильно был огорчен, когда впервые узнал про Tailwind, а теперь, после пары проектов на нем, не представляю как жил до него. Это безумно удобно по многим причинам, я бы сказал гениально, на уровне изобретения швейцарского ножа. Что не отменяет конечно того что css надо знать. А вот NextJs -- не гениально, к сожалению. Если очень хочется фуллстек, сделали лучше бы что нибудь с NestJs, красиво и понятно, чем все эти костыли и метания между роутерами.
Интересно, а как например выполнить client code с функцией server action? Например после нажатия кнопки поставить ей состояние disabled, изменить какие нибудь стейты, а если в server actionбудет ошибка, то как нибудь обработать ее и вывести уведомление с ошибкой 🤔
Я правильно понимаю что мне в nexte не светит получить один раз, то что используеться в каждой странице и диспачить редакс и дальше не бегать за ним к серверу?
У меня есть Layout.js и страницы. Следовательно я это дело питаюсь сделать в layoute но там такая история export default async function RootLayout({ children }) { и здесь нет диспатч. Или для этого я могу тупой компонент рендерить внутры уже Providerа который и сделает этот рекуест и тогда может получиться. return (
подскажите кто может! я тяну посты из вордпресса через graphql, рендерю в серверной странице блога пачку, мне нужно по кнопке загрузить след пачку постов а тут проблема - никак не могу заставить перерендерить серверную страницу если сервер экшен в отдельном файле т.е. я вижу след пачку в консоли но как отобразить понятия не имею (ревалидэйт пробовал) а если сервер экшен прямо на этой же странице блога то получается все норм, как это работает хз
при загрузке страницы блога идет фетч первой пачки posts и его рендер, в отдельном файле сервер экшен я также делаю фетч с новыми параметрами приходит новая пачка постов я их записываю также в posts потом ревалидейт но перерендера не происходит..если сервер экшен в самой странице блога то я posts перезаписываю получается и происходит обновление..
@@PurpleSchool есть такая штука курсор в ВП graphql, передвигая его можно запрашивать след пачку постов или Вы предлагаете запросить сразу всю тысячу постов?
@@jemand-i5m в каком месте моего ответа я это предлагаю? Я говорю про ревалидацию страницы после использования Server Actions и говорю что оне не нужны тут. Курсор можно использовать и обычным React клиентом GraphQL.
@@PurpleSchoolдаже для фронтов эта штука выглядит как баловство для приложений уровня туду листа Даже небольшое реальное приложение написать будет геморно и криво с такой архитектурой
@@PurpleSchool в каком смысле? Есть множество способов реализовать DI, в зависимости от языка и конкретной задачи, они могут быть разными, в js великолепно можно использовать замыкания, например вернуть функцию, которая вернет другую функцию, первая функция примет клиент, который можно менять в зависимости от нужды, вторая функция будет принимать уже нужные вам аргументы- вот вам и DI клиента например, я привел абстрактный пример
@@PurpleSchool это как сказать, что нельзя строить архитектуру реального приложения используя переменные или оператор сравнения. Если вам нужно сравнить что-то с чем-то- используйте оператор сравнения, если вам нужно внедрить зависимость - можете ее внедрить замыканием, причем тут архитектура приложения - я не понял, я бы еще понял, если бы вы сказали, что фреймворк вам диктует архитектурный подход, который не позволяет использовать замыкания для DI, например nest для этого использует декораторы, но там как бы классы…
Еще раз получил подтверждение, что Nextjs это тупик, в который настойчиво завели вобщем-то неплохую экосистему React. Зачем завели -- понятно -- чтобы продавать свои сервисы. Зачем мы ведемся -- непонятно. На текущем проекте пользуемся 13 версией, все озвученые проблемы там в полной мере уже присутствуют. Зачем делать из React убогое подобие MVC -- тоже непонятно, могли бы их продавать как нибудь по-другому. За видео спасибо, как всегда все круто!
@@PurpleSchool 1. - если очень хочется индексировать и писать при этом на Реакт. Только нафига козе баян? Кто-то пишет блоги на Реакте? Что вообще надо написать такое, что без Реакта не обойтись, и что при этом потребует индексирования? 2. - про скорость загрузки уже много раз писалось, выигрыш - секунда, макс две для очень тяжелых проектов, которые на Нексте, кстати, геморно будет поднять. Если у вас тяжелый JS бандл, который долго грузиться, значит у вас много логики. Много логики == высокая сложность, Некст не вытянет по тем же причинам, о чем видео. Бандл может быть тяжелым от картинок и прочего - ну так он и на Нексте будет тяжело грузиться тогда. Это же не серебрянная пилюля от всего, там никакого волшебства. 3. Телефоны сейчас мощнее компьютеров пятилетней давности. Связь - да, только толку от предварительной загрузки, если интерактивное приложение загрузило и показало мертвый HTML, который еще надо подождать, чтобы заработал, мы так пользователей удержим? Кому надо, дождется полной загрузки бандла и будет спокойно работать, а не спотыкаться между страницами. И опять же какой вероятности этот юзкейс, и стоит ли это всего вышеописаного гемора с кашей в коде и в головах. Полярникам и нефтянникам формы налогов в портале услуг заполнять?
🔗 Ссылки:
Server Actions: th-cam.com/video/w8QQKEPDY_k/w-d-xo.html
Prisma: th-cam.com/video/YoSl5sx-uUU/w-d-xo.html
NvChad: th-cam.com/video/Q1gIbPEStL0/w-d-xo.html
NVM: th-cam.com/video/Ssbvs2XtzuY/w-d-xo.html
🎓 Курс по Next.js purpleschool.ru/course/nextjs
💬 Telegram канал с полезными советами:
t.me/purple_code_channel
тема огонь)
👍
Антон, как же у тебя приятно звучит клавиатура, не подскажешь где брал и как она называется ?
Спасибо за видос, очень полезный!
Спасибо! Вот обзор моей клавиатуры, я собирал сам: th-cam.com/video/OQUlazEFCYg/w-d-xo.html
Я столкнулся с такой же проблемой архитектуры, когда начал пилить пет-проект на solid-start.
👍
Ну в целом я согласен насчет server actions, не особо понимаю почему Next движется в сторону fullstack фреймворка, если большинство его все равно воспринимают, как frontend фреймворк. Очень жду когда partials rendering будет, это намного интереснее
Поддерживаю!
Только плотно взаимодействуя с беком можно получить максимальную скорость
@@erjigit17 что значит плотно? Server actions такой же http запрос, ни какой магии
Как большинство воспринимают ≠ идея продукта
@@denisputnov к счастью или к сожалению, у нас не коммунизм и одной идеи не достаточно) Сейчас важен бизнес. У кого деньги, тот и прав
какие пет проекты посоветуешь делать именно для фронтенда next? без бека
Меня всегда напрягали фул стаки, сам полтооа года был на этой позиции, но в перспективе это посредственный код получается, либо ты бек либо фронт
Зависит от того, с чем человек больше работает
периодически провожу либо присутствую на собесах. Как правило фулстаки либо сильно сдвинуты в какую либо сторону, либо плавают и там, и там
согласен слишком много меняется и один чел может не тянуть и скорее всего е будет
@@PurpleSchoolи с тем и с тем, на что то одно тратить время как то не хочется, везде есть свои плюсы
16:54 Что за бред, нет никаких ограничений, не обязательно использовать в action и form, работают они как любая обычная функция с любыми входящими данными не только FormData. Вызывать можно хоть в onClick хоть в useEffect, только тело функции будет не на фронте а на сервере выполняться .. Как и валидация, прям в action добавляется валидация типа через Zod, который великолепно преобразуется в тип typeScripta. Таким образом у вас одна единая модель данных как на фронте так и на бэке 💁🏻♂️
Если вы попробуете вызвать из onClick функцию, в отдельном файле, который даже отмечен как use server и передать туда аргументы, то получите ошибку, так как он будет считать runtime браузерным
@@PurpleSchool У меня целый проект в продакшене уже так работает месяца 4 начиная с экспериментальной версии 13.5. И нет никаких проблем, более того эти server action успешно используются внутри стейт менеджера Zustand
Хм, интересно, поэкспериментирую
Если нужен отдельный back - пожалуйста - делайте NestJs, и дергайте его из server actions с помощью fetch'а, который расширен next-ом. Преимуществом fullstack является сквозная типизация
А зачем использовать fetch в server actions? Эти же типы могу быть на фронте и не требовать server actions вообще
Никто вам не мешает на отдельном беке использовать сквозную типизацию в монорепо, например. Никакого тут преимущества у сервер акшенс нет.
@@golden_smilesмонорепо это тип когда есть парка клиент сервер и рядом общие файлы?
@@awenn2015 Это когда несколько проектов в одном репо, обычно под управлением специализированных инструментов, но можно и просто workspaces от npm использовать. Экспортируете типы dto в серверном проекте, клиент их пользует, вот и сквозная типизация. Разумеется полностью от проблем не избавиться так как если рест, например, то надо как то обходится с параметрами вызовов, да и тайпскрипт далеко не идеален, так что все равно накручивают схемы и валидации. Удобство сервер акшенс в том что весь этот лейер передачи данных по апи они прячут за внешним простым вызовом функции. Это и недостаток, так во множестве сценариев требуется понимания и настроек более точных, чем просто вызвать и получить несложный джейсон, а это как раз становится недоступным.
Здравствуйте. Вы сказали, конечо без Tailwind. Скажите пожалуйста, а что с ним не так ?
Мне лично не нравится замес кучи классов и JSX, становится плохо читабельно. Но это мое мнение
@@PurpleSchool Спасибо. Было очень интересно ваше мнение.
@@PurpleSchool 100% это опять этот тупик вроде бутстрапа когда убивается весь смысл разделения разметки и оформления.
@@un_definedсогласен. Фронтэнд в лапшу превращают
Судя по документации - Turbopack всё еще находится в стадии Beta.
Да, но на удивление работает
@@PurpleSchool у меня нет. next-intl не заводится
Алиасы на нем не заводились у меня
Спасибо за видео! И хотел спросить для создания большого ERP систему что более подходящий react или next? И ещё важный момент, разработчик один, фуллстек разработчик(наверное этот момент тоже влияет..).
Если не требуется SSR, то проще взять React с Tanstack или React Router
@@PurpleSchool Честно говоря не знаю, обычно нужно ли ssr для erp?
@@Jasurbek_Shomaqsudov сомнительно
@@PurpleSchool В любом случае спасибо за быстрый ответ
Просто Next'у нужно определиться. Они фронтэнд или бекэнд или все вместе но качественно. А то всего по чуть-чуть нахватали и вроде бы работает но через %опу
Они пытаются быть всем, но для бека им не хватает очень многих компонент. Я бы не взялся на нём писать бек ни для какого проекта
Да, прям не хватает DI, чтобы все эти коннекшены к БД, редис, очереди, нормальный контекст реквеста и прочее ижектить, а не изобретать костыли. Какого-нибудь слоя сервисов где будет бизнес логика. Не понял есть ли слой middleware, очень часто нужно предварительно работать с реквестом (логировать то что нужно, проверять авторизацию и тп.). Ну и еще много чего не хватает по мелочи.
Короче для полноценного бекенда пока слабовато, но вот для небольших сайтов типа блога или сайта ресторана для заказа пиццы-шаурмы без лишних сервисов и интеграций, либо там какой-нибудь внутренний сервис типа админки быстро накидать, я думаю здесь будет топ. Ну и само собой для предварительного рендера реакта для сеошников самый раз.
Немножко удалим все, что здесь находится) Так мило
😄
А почему: только не tailwind?😢
Я не его фанат) мне не очень нравится большое число классов в компонентах
в чем кайф когда базовая идея разделения стиля и разметки ломается об колено
@un_defined Ахаха точно замечено "об колено". Пикантно, то что этот коммент в ветке про React и NextJs, где сначала поломали разделение между разметкой и кодом, а потом между фронтом и беком. Наверное есть смысл, если народ этим пользуется. Я сильно был огорчен, когда впервые узнал про Tailwind, а теперь, после пары проектов на нем, не представляю как жил до него. Это безумно удобно по многим причинам, я бы сказал гениально, на уровне изобретения швейцарского ножа. Что не отменяет конечно того что css надо знать. А вот NextJs -- не гениально, к сожалению. Если очень хочется фуллстек, сделали лучше бы что нибудь с NestJs, красиво и понятно, чем все эти костыли и метания между роутерами.
Привет
Подскажите, пожалуйста, как сделать такие снипеты в командной строке? Или это возможно только на Маке?
Это ZSH плагин. У меня на канале есть про него видео
Спасибо тебе за разбор. Красавчик, продолжай.
Комент для продвижения видоса.
Спасибо!
Антон, Благодарю
Пожалуйста!
Видео лайк, а сервер екшени реально стремно виглядит...
как только вижу магию, сразу болеть в спине начинает..
😀
Интересно, а как например выполнить client code с функцией server action? Например после нажатия кнопки поставить ей состояние disabled, изменить какие нибудь стейты, а если в server actionбудет ошибка, то как нибудь обработать ее и вывести уведомление с ошибкой 🤔
th-cam.com/video/RadgkoJrhu0/w-d-xo.html
Спасибо за видео ❤️
Пожалуйста
"tailwind - ни в коем случае" - почему так категорично?
Мое личное мнение. Мне нравится его концепция, но не нравится ужасные замес кучи классов и JSX
у меня турбопак не пляшет с next-intl.
Видимо не до конца доделали
Как у вас некст запустился, он же требует версию ноды 18.17 ?
Я через nvm сменил на 20
а что за терминал такой?
th-cam.com/video/OV8nPsWywTc/w-d-xo.htmlsi=B4dtdXhFbKQ5dyQo
Я правильно понимаю что мне в nexte не светит получить один раз, то что используеться в каждой странице и диспачить редакс и дальше не бегать за ним к серверу?
Почему, вполне можно
У меня есть Layout.js и страницы. Следовательно я это дело питаюсь сделать в layoute но там такая история
export default async function RootLayout({ children }) {
и здесь нет диспатч. Или для этого я могу тупой компонент рендерить внутры уже Providerа который и сделает этот рекуест и тогда может получиться.
return (
{children}
);
}
Не так не тоже не вариант :)
@@anichkaaleksanyan1124 вы можете внутрь добавить клиентский компонент, который через Props принимает данные и там вызывает dispatch
@@PurpleSchool точно. Спасибо за совет.
Вопрос есть, а что в next js должен знать бэкенд?
В теории бекенд не должен использовать Next.js)
Если бэкенд не нужен знать, почему middleware использовать?
Спасибо за ответ !)
Привет Антон, вопрос не по теме, но что лучше для бэкенда, Nest js или c# ?
Зависит от команды и проекта, нет однозначного ответа
Понял
Java )
подскажите кто может! я тяну посты из вордпресса через graphql, рендерю в серверной странице блога пачку, мне нужно по кнопке загрузить след пачку постов а тут проблема - никак не могу заставить перерендерить серверную страницу если сервер экшен в отдельном файле т.е. я вижу след пачку в консоли но как отобразить понятия не имею (ревалидэйт пробовал) а если сервер экшен прямо на этой же странице блога то получается все норм, как это работает хз
при загрузке страницы блога идет фетч первой пачки posts и его рендер, в отдельном файле сервер экшен я также делаю фетч с новыми параметрами приходит новая пачка постов я их записываю также в posts потом ревалидейт но перерендера не происходит..если сервер экшен в самой странице блога то я posts перезаписываю получается и происходит обновление..
Нужно использовать revalidateURL. Но для GraphQL не нужны server actions
@@PurpleSchool есть такая штука курсор в ВП graphql, передвигая его можно запрашивать след пачку постов или Вы предлагаете запросить сразу всю тысячу постов?
@@jemand-i5m в каком месте моего ответа я это предлагаю? Я говорю про ревалидацию страницы после использования Server Actions и говорю что оне не нужны тут. Курсор можно использовать и обычным React клиентом GraphQL.
@@PurpleSchool понял, спасибо
Идея с сервер экшенами это попытка переизобрести бэкенд? Не ну правда что это
Где вообще в реальном мире бэки выберут это?)
Скорее выберут фронты, чтобы быстро сделать бек на коленке
@@PurpleSchoolдаже для фронтов эта штука выглядит как баловство для приложений уровня туду листа
Даже небольшое реальное приложение написать будет геморно и криво с такой архитектурой
@@daveyjonesx пока так и есть
Выбирают к сожалению лиды, которым кажется что все новое это круто. При этом сами забыли когда последний раз код писали.
@@golden_smiles если показать это нововведение бэкенд лиду он скажет вы что сбрендили
Чем замыкание не dependency injection?
Это так себе практика DI
@@PurpleSchool в каком смысле? Есть множество способов реализовать DI, в зависимости от языка и конкретной задачи, они могут быть разными, в js великолепно можно использовать замыкания, например вернуть функцию, которая вернет другую функцию, первая функция примет клиент, который можно менять в зависимости от нужды, вторая функция будет принимать уже нужные вам аргументы- вот вам и DI клиента например, я привел абстрактный пример
@@GAccountMe да, но на этом нельзя строить архитектуру реального приложения
@@PurpleSchool это как сказать, что нельзя строить архитектуру реального приложения используя переменные или оператор сравнения. Если вам нужно сравнить что-то с чем-то- используйте оператор сравнения, если вам нужно внедрить зависимость - можете ее внедрить замыканием, причем тут архитектура приложения - я не понял, я бы еще понял, если бы вы сказали, что фреймворк вам диктует архитектурный подход, который не позволяет использовать замыкания для DI, например nest для этого использует декораторы, но там как бы классы…
Еще раз получил подтверждение, что Nextjs это тупик, в который настойчиво завели вобщем-то неплохую экосистему React. Зачем завели -- понятно -- чтобы продавать свои сервисы. Зачем мы ведемся -- непонятно. На текущем проекте пользуемся 13 версией, все озвученые проблемы там в полной мере уже присутствуют. Зачем делать из React убогое подобие MVC -- тоже непонятно, могли бы их продавать как нибудь по-другому. За видео спасибо, как всегда все круто!
Какие альтернативы с лучшей работой сео?
@@atmalive Зачем вам реакт, если нужно сео? Что сео там грабить будет, на динамической страничке?
Next хорош для:
- Индексации и SEO
- Скорости загрузки
- Работы на слабых устройствах или при плохой связи
@@PurpleSchool 1. - если очень хочется индексировать и писать при этом на Реакт. Только нафига козе баян? Кто-то пишет блоги на Реакте? Что вообще надо написать такое, что без Реакта не обойтись, и что при этом потребует индексирования? 2. - про скорость загрузки уже много раз писалось, выигрыш - секунда, макс две для очень тяжелых проектов, которые на Нексте, кстати, геморно будет поднять. Если у вас тяжелый JS бандл, который долго грузиться, значит у вас много логики. Много логики == высокая сложность, Некст не вытянет по тем же причинам, о чем видео. Бандл может быть тяжелым от картинок и прочего - ну так он и на Нексте будет тяжело грузиться тогда. Это же не серебрянная пилюля от всего, там никакого волшебства. 3. Телефоны сейчас мощнее компьютеров пятилетней давности. Связь - да, только толку от предварительной загрузки, если интерактивное приложение загрузило и показало мертвый HTML, который еще надо подождать, чтобы заработал, мы так пользователей удержим? Кому надо, дождется полной загрузки бандла и будет спокойно работать, а не спотыкаться между страницами. И опять же какой вероятности этот юзкейс, и стоит ли это всего вышеописаного гемора с кашей в коде и в головах. Полярникам и нефтянникам формы налогов в портале услуг заполнять?
@@golden_smilesдада, не забудьте что бандл также еще и загружается один раз и хранится в кэше. А для сео есть пререндер
Зачем нам помечать серверные компоненты 'use server', они разве по умолчанию не серверные?
Action*
Согласно документации nextjs.org/docs/app/api-reference/functions/server-actions
Ты бы ещё рассказывал про Nuxt 3. Вот это дело было бы.
Подумаю над этим)
@@PurpleSchoolв нем хотя бы настоящие серверные компоненты (в бете)
@@undertale-15075O так в Next же они же