Пожалуйста

Спасибо!

Пожалуйста!

👍

Если не требуется SSR, то проще взять React с Tanstack или React Router

@@PurpleSchool Честно говоря не знаю, обычно нужно ли ssr для erp?

@@Jasurbek_Shomaqsudov сомнительно

@@PurpleSchool В любом случае спасибо за быстрый ответ

kzfaq.info/get/bejne/iMeUms6gr9jMpWQ.html

Спасибо! Вот обзор моей клавиатуры, я собирал сам: kzfaq.info/get/bejne/hbeFn8SrqqyniZs.html

Зависит от команды и проекта, нет однозначного ответа

Понял

Java )

Это ZSH плагин. У меня на канале есть про него видео

Мне лично не нравится замес кучи классов и JSX, становится плохо читабельно. Но это мое мнение

@@PurpleSchool Спасибо. Было очень интересно ваше мнение.

@@PurpleSchool 100% это опять этот тупик вроде бутстрапа когда убивается весь смысл разделения разметки и оформления.

​@@un_definedсогласен. Фронтэнд в лапшу превращают

А зачем использовать fetch в server actions? Эти же типы могу быть на фронте и не требовать server actions вообще

Никто вам не мешает на отдельном беке использовать сквозную типизацию в монорепо, например. Никакого тут преимущества у сервер акшенс нет.

​@@golden_smilesмонорепо это тип когда есть парка клиент сервер и рядом общие файлы?

@@awenn2015 Это когда несколько проектов в одном репо, обычно под управлением специализированных инструментов, но можно и просто workspaces от npm использовать. Экспортируете типы dto в серверном проекте, клиент их пользует, вот и сквозная типизация. Разумеется полностью от проблем не избавиться так как если рест, например, то надо как то обходится с параметрами вызовов, да и тайпскрипт далеко не идеален, так что все равно накручивают схемы и валидации. Удобство сервер акшенс в том что весь этот лейер передачи данных по апи они прячут за внешним простым вызовом функции. Это и недостаток, так во множестве сценариев требуется понимания и настроек более точных, чем просто вызвать и получить несложный джейсон, а это как раз становится недоступным.

👍

Почему, вполне можно

У меня есть Layout.js и страницы. Следовательно я это дело питаюсь сделать в layoute но там такая история export default async function RootLayout({ children }) { и здесь нет диспатч. Или для этого я могу тупой компонент рендерить внутры уже Providerа который и сделает этот рекуест и тогда может получиться. return ( {children} ); } Не так не тоже не вариант :)

@@anichkaaleksanyan1124 вы можете внутрь добавить клиентский компонент, который через Props принимает данные и там вызывает dispatch

@@PurpleSchool точно. Спасибо за совет.

Я через nvm сменил на 20

Поддерживаю!

Только плотно взаимодействуя с беком можно получить максимальную скорость

@@erjigit17 что значит плотно? Server actions такой же http запрос, ни какой магии

Как большинство воспринимают ≠ идея продукта

@@denisputnov к счастью или к сожалению, у нас не коммунизм и одной идеи не достаточно) Сейчас важен бизнес. У кого деньги, тот и прав

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

Нужно использовать revalidateURL. Но для GraphQL не нужны server actions

@@PurpleSchool есть такая штука курсор в ВП graphql, передвигая его можно запрашивать след пачку постов или Вы предлагаете запросить сразу всю тысячу постов?

@@dmitryreturn1443 в каком месте моего ответа я это предлагаю? Я говорю про ревалидацию страницы после использования Server Actions и говорю что оне не нужны тут. Курсор можно использовать и обычным React клиентом GraphQL.

@@PurpleSchool понял, спасибо

В теории бекенд не должен использовать Next.js)

Если бэкенд не нужен знать, почему middleware использовать?

Спасибо за ответ !)

Видимо не до конца доделали

Это так себе практика DI

@@PurpleSchool в каком смысле? Есть множество способов реализовать DI, в зависимости от языка и конкретной задачи, они могут быть разными, в js великолепно можно использовать замыкания, например вернуть функцию, которая вернет другую функцию, первая функция примет клиент, который можно менять в зависимости от нужды, вторая функция будет принимать уже нужные вам аргументы- вот вам и DI клиента например, я привел абстрактный пример

@@GAccountMe да, но на этом нельзя строить архитектуру реального приложения

@@PurpleSchool это как сказать, что нельзя строить архитектуру реального приложения используя переменные или оператор сравнения. Если вам нужно сравнить что-то с чем-то- используйте оператор сравнения, если вам нужно внедрить зависимость - можете ее внедрить замыканием, причем тут архитектура приложения - я не понял, я бы еще понял, если бы вы сказали, что фреймворк вам диктует архитектурный подход, который не позволяет использовать замыкания для DI, например nest для этого использует декораторы, но там как бы классы…

Да, но на удивление работает

@@PurpleSchool у меня нет. next-intl не заводится

Алиасы на нем не заводились у меня

Я не его фанат) мне не очень нравится большое число классов в компонентах

в чем кайф когда базовая идея разделения стиля и разметки ломается об колено

@un_defined Ахаха точно замечено "об колено". Пикантно, то что этот коммент в ветке про React и NextJs, где сначала поломали разделение между разметкой и кодом, а потом между фронтом и беком. Наверное есть смысл, если народ этим пользуется. Я сильно был огорчен, когда впервые узнал про Tailwind, а теперь, после пары проектов на нем, не представляю как жил до него. Это безумно удобно по многим причинам, я бы сказал гениально, на уровне изобретения швейцарского ножа. Что не отменяет конечно того что css надо знать. А вот NextJs -- не гениально, к сожалению. Если очень хочется фуллстек, сделали лучше бы что нибудь с NestJs, красиво и понятно, чем все эти костыли и метания между роутерами.

Они пытаются быть всем, но для бека им не хватает очень многих компонент. Я бы не взялся на нём писать бек ни для какого проекта

Да, прям не хватает DI, чтобы все эти коннекшены к БД, редис, очереди, нормальный контекст реквеста и прочее ижектить, а не изобретать костыли. Какого-нибудь слоя сервисов где будет бизнес логика. Не понял есть ли слой middleware, очень часто нужно предварительно работать с реквестом (логировать то что нужно, проверять авторизацию и тп.). Ну и еще много чего не хватает по мелочи. Короче для полноценного бекенда пока слабовато, но вот для небольших сайтов типа блога или сайта ресторана для заказа пиццы-шаурмы без лишних сервисов и интеграций, либо там какой-нибудь внутренний сервис типа админки быстро накидать, я думаю здесь будет топ. Ну и само собой для предварительного рендера реакта для сеошников самый раз.

Мое личное мнение. Мне нравится его концепция, но не нравится ужасные замес кучи классов и JSX

Зависит от того, с чем человек больше работает

периодически провожу либо присутствую на собесах. Как правило фулстаки либо сильно сдвинуты в какую либо сторону, либо плавают и там, и там

согласен слишком много меняется и один чел может не тянуть и скорее всего е будет

​@@PurpleSchoolи с тем и с тем, на что то одно тратить время как то не хочется, везде есть свои плюсы

kzfaq.info/get/bejne/hbxoobOkvN_bhJc.htmlsi=B4dtdXhFbKQ5dyQo

😄

Если вы попробуете вызвать из onClick функцию, в отдельном файле, который даже отмечен как use server и передать туда аргументы, то получите ошибку, так как он будет считать runtime браузерным

@@PurpleSchool У меня целый проект в продакшене уже так работает месяца 4 начиная с экспериментальной версии 13.5. И нет никаких проблем, более того эти server action успешно используются внутри стейт менеджера Zustand

Хм, интересно, поэкспериментирую

Скорее выберут фронты, чтобы быстро сделать бек на коленке

⁠@@PurpleSchoolдаже для фронтов эта штука выглядит как баловство для приложений уровня туду листа Даже небольшое реальное приложение написать будет геморно и криво с такой архитектурой

@@daveyjonesx пока так и есть

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

@@golden_smiles если показать это нововведение бэкенд лиду он скажет вы что сбрендили

Action*

Согласно документации nextjs.org/docs/app/api-reference/functions/server-actions

как только вижу магию, сразу болеть в спине начинает..

😀

Какие альтернативы с лучшей работой сео?

@@atmalive Зачем вам реакт, если нужно сео? Что сео там грабить будет, на динамической страничке?

Next хорош для: - Индексации и SEO - Скорости загрузки - Работы на слабых устройствах или при плохой связи

@@PurpleSchool 1. - если очень хочется индексировать и писать при этом на Реакт. Только нафига козе баян? Кто-то пишет блоги на Реакте? Что вообще надо написать такое, что без Реакта не обойтись, и что при этом потребует индексирования? 2. - про скорость загрузки уже много раз писалось, выигрыш - секунда, макс две для очень тяжелых проектов, которые на Нексте, кстати, геморно будет поднять. Если у вас тяжелый JS бандл, который долго грузиться, значит у вас много логики. Много логики == высокая сложность, Некст не вытянет по тем же причинам, о чем видео. Бандл может быть тяжелым от картинок и прочего - ну так он и на Нексте будет тяжело грузиться тогда. Это же не серебрянная пилюля от всего, там никакого волшебства. 3. Телефоны сейчас мощнее компьютеров пятилетней давности. Связь - да, только толку от предварительной загрузки, если интерактивное приложение загрузило и показало мертвый HTML, который еще надо подождать, чтобы заработал, мы так пользователей удержим? Кому надо, дождется полной загрузки бандла и будет спокойно работать, а не спотыкаться между страницами. И опять же какой вероятности этот юзкейс, и стоит ли это всего вышеописаного гемора с кашей в коде и в головах. Полярникам и нефтянникам формы налогов в портале услуг заполнять?

@@golden_smilesдада, не забудьте что бандл также еще и загружается один раз и хранится в кэше. А для сео есть пререндер

Подумаю над этим)

​​@@PurpleSchoolв нем хотя бы настоящие серверные компоненты (в бете)

@@user-sj7tf2yv3m так в Next же они же