Все круто!) Очень хотелось бы роликов с практикой написания реальных приложений (не обязательно крупных), но на продвинутом уровне, с использованием качественных подходов к разработке фронта, покрытие тестами, оптимизация и т.д. Подобного русскоязычного контента очень мало. Думаю что большинство твоих зрителей меня поддержат!)
серверные компоненты нужны для того, чтобы ты мог уменьшить поставку бандла на клиент, делать кеширование на сервере и логику - ты получаешь полноценное изоморфное приложение например если мне нужно заюзать библиотеку которая весит много - я могу это сделать на сервере и не поставлять огромный бандл на клиент если у меня регулярно делается запрос комментариев - я могу сделать кеширование на сервере и не делать постоянную бомбежку API при том у меня не будет проблем синхронизации кешей у разных клиентов, ибо эта логика лежит только на сервере nextjs многое не мог делать как раз таки потому что внутри react не было понятия сервер/клиент - не просто так nextjs мигрирует на app folder :)
Хотелось бы увидеть контент как готовиться к собесам, как решать алгоритмические задачи и в целом глубже погружаться в нативный js. Спасибо за твой труд
Вот мои 6 вещей, которым я научился с реактом: 1. useState 2. useEffect 3. PropsDrilling 4. Рисовать лоадер или контент тернарным оператором в JSX 5. Использовать функцию высшего порядка map для отрисовки множественных элементов внутри JSX. 6. Навешивать обработчик события клика на элемент. На мидла офер даёшь?
Видео огонь! Спасибо за интересную информацию. Звук, к слову, стал идеальный, прослушал с удовольствием. Подскажи, какую литературу или ресурсы можешь порекомендовать, чтобы строить правильную архитектуру реакт приложения? (имею ввиду, чтобы правильно использовать редакс, сагу, где бизнес логика должна находится и подобное). И вообще, стоит ли разбирать сам редакс, а не ртк? И подскажи, когда стримы у тебя проводятся? По графику или по возможности
3ий пункт про переменные - в целом согласен, но все же тут 2 грани. Лучше баланс по подробности и краткости переменных - выносить самое важное в название и учитывать частоту использования и контекст в котором будет использоваться. Я обычно пишу черезчур подробные названия у переменных только для временных локальных переменных, и то не всегда (тут минимальное переиспользование). Импортируя classes и css модули я называю их cn и cl намеренно, чтобы занимало как можно меньше места, т.к. использоваться они будут очень активно, внутри jsx. Общее правило для меня такое что следует выносить максимально возможное количество ВАЖНЫХ деталей в название, до тех пор пока это не становится проблемой читабельности в тех местах где это название будет использоваться, в этом случае сокращаем детали, убирая менее важные детали или перефразируя.
Тут нету единого правила, но согласен, что бывают и обратные случаи, когда пишут слишком длинные названия. А так согласен, главное, чтобы детали важные не упускались.
Аюб, согласен с тобой по всем моментам. Имею аналогичные взгляды на озвученные тобой пункты. Формат норм, иногда нужно или полезно просто мысли в слух или какие то новости можно обсудить. Раз в неделю например или две, или месяц)))
моя мечта это типа функциональный ангулар, когда все функциональное, но при этом нет смешения логики стиля и разметки, и поменьше сахара, чтоб прям вместо взял поставил либу просто взял кусок кода/функции из либы и просто вставил в свой код. то есть некая смесь чистого js html css строго стандартизированная и с мин сахара чтобы не было магии а было ясное понимание как и что работает. хотя магию можно и оставить опционально
раньше использовал RiotJS, они сошли с ума, с каждой новой версией все хуже и хуже, потом попробовал Vue но размер бандла решает :( в итоге оставил его только в профиле, который не индексируется поисковиками, на всех страницах сайта где нужна была динамика использую сейчас Preact или Petite-Vue.
За что уважаю реакт - так это за то,то там сначала думают, потом делают. Обкатывают идеи сначала у себя, потом уже мягко выпускают их в мир. Правда, обьяснять идеи - не их конек. В общем, повторяю уже за автором видео. Интересно, а если бы вы разбирали любого другого фреймворка, вы бы к тем же выводам пришли, или нет? Считаете ли вы эти концепции применимыми в других языках или даже областях программирования? Ну и вопрос, который вы озвучили по поводу серверных компонентов. Меня он сильно мучает. Да, пока это кажется мутной водой. Мы верим, что с течением времени все утрясется, и реакт снова будет на коне за счет крупной инновации. А вдруг нет? Вдруг их идеи дадут сбой? Ведь есть же знаменитая формула, что 20 процентов усилий дадут 80% результата. Пришли фреймворки - да, это те 80%. Ввели асинхронный рендеринг реконсилиации - еще +10 процентов. Хуки - плюс 5 процентов. А сейчас может уже идет борьба за 2%. Стоит ли овчинка выделки? А если они ошибутся, то обидно будет потратить свои усилия на изучение этого. Спасибо за видео. Озвучены мысли, которые крутятся в голове многих их нас. Однако мало об этом кто вслух говорит.
Все круто!)
Очень хотелось бы роликов с практикой написания реальных приложений (не обязательно крупных), но на продвинутом уровне, с использованием качественных подходов к разработке фронта, покрытие тестами, оптимизация и т.д.
Подобного русскоязычного контента очень мало. Думаю что большинство твоих зрителей меня поддержат!)
Формат довольно таки отличный , прям душевно все )
Спасибо!
Коммент в поддержку брата
Спасибо!
серверные компоненты нужны для того, чтобы ты мог уменьшить поставку бандла на клиент, делать кеширование на сервере и логику - ты получаешь полноценное изоморфное приложение
например если мне нужно заюзать библиотеку которая весит много - я могу это сделать на сервере и не поставлять огромный бандл на клиент
если у меня регулярно делается запрос комментариев - я могу сделать кеширование на сервере и не делать постоянную бомбежку API при том у меня не будет проблем синхронизации кешей у разных клиентов, ибо эта логика лежит только на сервере
nextjs многое не мог делать как раз таки потому что внутри react не было понятия сервер/клиент - не просто так nextjs мигрирует на app folder :)
Хотелось бы увидеть контент как готовиться к собесам, как решать алгоритмические задачи и в целом глубже погружаться в нативный js. Спасибо за твой труд
Разговорные видео - топ!
Спасибо за фидбэк!
комментарий в поддержку канала
Спасибо!
Хорошая подача, продолжай.
приятное видео, спасибо)
не за что!
Сразу лайк
Спасибо!
Большое спасибо за полезный контент 👍
не за что!
Отличное видео, хотелось бы видео по полной настройке нового проекта на react
Вот мои 6 вещей, которым я научился с реактом:
1. useState
2. useEffect
3. PropsDrilling
4. Рисовать лоадер или контент тернарным оператором в JSX
5. Использовать функцию высшего порядка map для отрисовки множественных элементов внутри JSX.
6. Навешивать обработчик события клика на элемент.
На мидла офер даёшь?
Хахаха, пока позиций нету открытых.
А что такое функция высшего порядка? Типо HOF? :D Впервые слышу чтобы метод массива так называли
@@ИгорьКупаев-ж2вэто как раз HOF редко услышишь, а "функция высшего порядка" - это общепринятый термин.
Топчик!
Спасибо!
Спасибо за труд
не за что!
спасибо, формат зашел, интересно
принял, буду еще снимать.
Хороший формат
тогда будем продолжать.
Видео огонь! Спасибо за интересную информацию. Звук, к слову, стал идеальный, прослушал с удовольствием. Подскажи, какую литературу или ресурсы можешь порекомендовать, чтобы строить правильную архитектуру реакт приложения? (имею ввиду, чтобы правильно использовать редакс, сагу, где бизнес логика должна находится и подобное). И вообще, стоит ли разбирать сам редакс, а не ртк? И подскажи, когда стримы у тебя проводятся? По графику или по возможности
Формат скорее для подкастов, чем для видео. Коммент, лайк и так :-)
А что под подкастом понимаешь? Длинное разговорное видео?
несколько раз видел использование преакта в гемблинг индустрии, в первую очередь из-за скорости загрузки приложений
Хахахах, интересное применение.
Молодчик!
Спасибо!
ОТличное видео, подписался, спасибо.
Добро пожаловать в наше комьюнити!
3ий пункт про переменные - в целом согласен, но все же тут 2 грани. Лучше баланс по подробности и краткости переменных - выносить самое важное в название и учитывать частоту использования и контекст в котором будет использоваться. Я обычно пишу черезчур подробные названия у переменных только для временных локальных переменных, и то не всегда (тут минимальное переиспользование). Импортируя classes и css модули я называю их cn и cl намеренно, чтобы занимало как можно меньше места, т.к. использоваться они будут очень активно, внутри jsx.
Общее правило для меня такое что следует выносить максимально возможное количество ВАЖНЫХ деталей в название, до тех пор пока это не становится проблемой читабельности в тех местах где это название будет использоваться, в этом случае сокращаем детали, убирая менее важные детали или перефразируя.
Тут нету единого правила, но согласен, что бывают и обратные случаи, когда пишут слишком длинные названия. А так согласен, главное, чтобы детали важные не упускались.
🎉🎉🎉🎉🎉
🎉🎉🎉
informativno 👍
Спасибо!
👏👍
Jotai или Recoil могут заменить Redux?
Да, вполне могут.
Аюб, согласен с тобой по всем моментам. Имею аналогичные взгляды на озвученные тобой пункты.
Формат норм, иногда нужно или полезно просто мысли в слух или какие то новости можно обсудить. Раз в неделю например или две, или месяц)))
Спасибо за фидбэк! Буду делать.
моя мечта это типа функциональный ангулар, когда все функциональное, но при этом нет смешения логики стиля и разметки, и поменьше сахара, чтоб прям вместо взял поставил либу просто взял кусок кода/функции из либы и просто вставил в свой код.
то есть некая смесь чистого js html css строго стандартизированная и с мин сахара чтобы не было магии а было ясное понимание как и что работает. хотя магию можно и оставить опционально
Frontend React
JS TS
ассаламуалейкум
валейкум ассалям.
раньше использовал RiotJS, они сошли с ума, с каждой новой версией все хуже и хуже, потом попробовал Vue но размер бандла решает :( в итоге оставил его только в профиле, который не индексируется поисковиками, на всех страницах сайта где нужна была динамика использую сейчас Preact или Petite-Vue.
И как опыт работы с preact, заметил какие-то проблемы?
@@ayub_begimkulov нет, все понравилось, проблем не было, в качестве стора использовал valtio
Vue тоже хорош
Главное чтобы задачи решало, а там уже все субъективщина.
чем эта шляпа хорош то?)))
@@masserrackheim5358по каким критериям ты понял что это шляпа, кроме того, что ты на нём не писал?
За что уважаю реакт - так это за то,то там сначала думают, потом делают. Обкатывают идеи сначала у себя, потом уже мягко выпускают их в мир. Правда, обьяснять идеи - не их конек. В общем, повторяю уже за автором видео.
Интересно, а если бы вы разбирали любого другого фреймворка, вы бы к тем же выводам пришли, или нет? Считаете ли вы эти концепции применимыми в других языках или даже областях программирования?
Ну и вопрос, который вы озвучили по поводу серверных компонентов. Меня он сильно мучает. Да, пока это кажется мутной водой. Мы верим, что с течением времени все утрясется, и реакт снова будет на коне за счет крупной инновации. А вдруг нет? Вдруг их идеи дадут сбой? Ведь есть же знаменитая формула, что 20 процентов усилий дадут 80% результата. Пришли фреймворки - да, это те 80%. Ввели асинхронный рендеринг реконсилиации - еще +10 процентов. Хуки - плюс 5 процентов. А сейчас может уже идет борьба за 2%. Стоит ли овчинка выделки? А если они ошибутся, то обидно будет потратить свои усилия на изучение этого.
Спасибо за видео. Озвучены мысли, которые крутятся в голове многих их нас. Однако мало об этом кто вслух говорит.
Коллеги-ангулярщики не понимают почему реакт пошел по пути функционального программирования...
Хахаха, ну в ангуляр кажется совсем другой мир. На самом деле тут плюсы и минусы есть свои.
Я бы хотел бы больше картинок и иллюстраций. На лицо мне смотреть скучно
Спасибо за фидбэк! Это пока начало - будем улучшать.
@@ayub_begimkulov контент хороший. Спасибо
Ты на вью не наговаривай, я тебя по ip найду
хахах, ок)
0:44 "Svelte чем-то лучше, чем React". Svelte всем лучше, чем React, кроме вакансий на него.