Спасибо за твой труд) Было бы интересно посмотреть на твой темплейт (надеюсь, он у тебя есть), с готовыми фичами и приколюхами (сортинг импортов и элиасы, стайлЛинт, преКоммит хуки, ЕСЛинт, локальный конфиг проекта (.vscode/settings.json), папочка с кучей реюзабл хуков и тааак далее) с уже готовым фундаментом под какую-то архитектуру, например фича-слайсед
Го реакт с нуля, пожалуйста) Там интересные вещи начинаются с useState, а еще интереснее с useState в нескольких компонентах и условным рендерингом. Если надумаешь делать - пиши, я кейс скину)
Я на самом деле об этом даже и не думал. Я вообще не вижу смысл использовать приватные свойства из JS, если вся база написана на TS. Ну и с поддержкой, как ты и сказал, проблем меньше будет.
Не совсем понимаю идею с переменной runningEffect. Если создать несколько сигналов в разных частях приложения, то все они будут использовать и перезаписывать одну и ту же переменную. Это же может привести к неожиданным результатам работы всех этих сигналов.
Да, на первый взгляд это может показаться очень странным. Но тут нужно учитывать особенность работы JS. В один момент времени у нас может быть только 1 эффект. Соответсвенно, все сигналы ссылаются на эту переменную, чтобы получить эффект, в котором они сейчас используются. А касательно перезаписи runningEffect - то она происходит только в функции effect. То есть тут тоже случайных перезаписей не должно быть.
Вот были классовые компоненты с 3 lifecycle методами и 1 рендером, нет надо было "упростить" всем жизнь и наплодить с десяток хуков чтобы сцепка и сложность кода выросла в геометральной прогрессии, да никогда с классовыми столько багов не было сколько теперь с хуками плодят гоняясь за каждым лишним ререндером оборачивая коллбеки в коллбеки и сохраняя ссылки на объедки)))) А на деле выйгрыш в производительности по сравнению с классовыми компонентами настолько мизерный, и никто уже не посчитает сколько миллионов в год бизнес теряет на исправлении багов которые сами же разработчики плодят создавая сотни недокументированных хуков и из-за непрозрачности их поведения, забытых deps, итд.
У классовых компонент был ряд недостатков связанных с неподдерживаемостью новой технологии асинхронного рендера. Ден Абрамов про это говорил уже давно)
@@Evgeny.. нет там очевидных недостатков кроме большого boilerplate даже для простых вещей, для асинхронного рендера нужна просто другая организация классовых компонентов. Дэн давно говорил для сложной state логики использовать классовые, для простых функциональные, и это было правильно пока он не радикализировались и не решили вообще убрать классовые. Сейчас все те проблемы за которые ругали классы как огромный нестинг, утечка async/await, и неочевидная логика, 1 в 1 вернулись с функциональными, только то что классовые оптимизировали из коробки теперь енфорсится делать вручную. Говорят нет хуже зла чем преждевременная оптимизация, но самый страшный грех в айти это всё-таки усложнять инструмент, вместо того чтобы делать его использование удобнее и проще.
Очень интересное видео)) Спасибо )) Мы с нулЬя разработали сигнал))
Спасибо за фидбэк!
Спасибо за видео 🎉 Красавчик, что все подробно расписал 👍
Спасибо за фидбэк!
Отличный контент, рад, что на тебя наткнулся)
Рад, что понравилось!
Классную нетривиальную тему разобрал, спасибо, красавчик 👆
Спасибо!
Супер полезно, погрузился в механизм этой фичи
Очень крутое видео, спасибо за тесты
Рад, что понравилось!
ух, давно не встречал код, который трудно понять, значит завтра попробую сам их реализовать)
Отличная работа, брат!
Спасибо!
Спасибо!
Спасибо за видео
тема интересная
Не за что!
Спасибо за твой труд) Было бы интересно посмотреть на твой темплейт (надеюсь, он у тебя есть), с готовыми фичами и приколюхами (сортинг импортов и элиасы, стайлЛинт, преКоммит хуки, ЕСЛинт, локальный конфиг проекта (.vscode/settings.json), папочка с кучей реюзабл хуков и тааак далее) с уже готовым фундаментом под какую-то архитектуру, например фича-слайсед
дофига хочешь😀
Сигналю реактивно лайк и коммент в поддержку каналу 👍хорошее, подробное разъяснение, спасиб
Спасибо большое!
Круто 🎉
Спасибо!
Го реакт с нуля, пожалуйста)
Там интересные вещи начинаются с useState, а еще интереснее с useState в нескольких компонентах и условным рендерингом. Если надумаешь делать - пиши, я кейс скину)
Да, давно в планах есть. Думаю засяду как-то основательно и доделаю. Пока только прототип небольшой)
👏👍
Спасибо большое. Молодец.
Спасибо!
комментарий в поддержку канала
Спасибо!
Классное видео, хоть с ходу не все понятно, но разберусь.
А почему приватные методы/поля через TS, а не ванильный JS? Для большей совместимости
Я на самом деле об этом даже и не думал. Я вообще не вижу смысл использовать приватные свойства из JS, если вся база написана на TS. Ну и с поддержкой, как ты и сказал, проблем меньше будет.
лайк ❤
Спасибо!
Коммент для продвижения
Спасибо!
🎉🎉🎉
Не совсем понимаю идею с переменной runningEffect. Если создать несколько сигналов в разных частях приложения, то все они будут использовать и перезаписывать одну и ту же переменную. Это же может привести к неожиданным результатам работы всех этих сигналов.
Да, на первый взгляд это может показаться очень странным. Но тут нужно учитывать особенность работы JS. В один момент времени у нас может быть только 1 эффект.
Соответсвенно, все сигналы ссылаются на эту переменную, чтобы получить эффект, в котором они сейчас используются.
А касательно перезаписи runningEffect - то она происходит только в функции effect. То есть тут тоже случайных перезаписей не должно быть.
Вот были классовые компоненты с 3 lifecycle методами и 1 рендером, нет надо было "упростить" всем жизнь и наплодить с десяток хуков чтобы сцепка и сложность кода выросла в геометральной прогрессии, да никогда с классовыми столько багов не было сколько теперь с хуками плодят гоняясь за каждым лишним ререндером оборачивая коллбеки в коллбеки и сохраняя ссылки на объедки))))
А на деле выйгрыш в производительности по сравнению с классовыми компонентами настолько мизерный, и никто уже не посчитает сколько миллионов в год бизнес теряет на исправлении багов которые сами же разработчики плодят создавая сотни недокументированных хуков и из-за непрозрачности их поведения, забытых deps, итд.
У классовых компонент был ряд недостатков связанных с неподдерживаемостью новой технологии асинхронного рендера. Ден Абрамов про это говорил уже давно)
@@Evgeny.. нет там очевидных недостатков кроме большого boilerplate даже для простых вещей, для асинхронного рендера нужна просто другая организация классовых компонентов. Дэн давно говорил для сложной state логики использовать классовые, для простых функциональные, и это было правильно пока он не радикализировались и не решили вообще убрать классовые. Сейчас все те проблемы за которые ругали классы как огромный нестинг, утечка async/await, и неочевидная логика, 1 в 1 вернулись с функциональными, только то что классовые оптимизировали из коробки теперь енфорсится делать вручную. Говорят нет хуже зла чем преждевременная оптимизация, но самый страшный грех в айти это всё-таки усложнять инструмент, вместо того чтобы делать его использование удобнее и проще.
💯
👍👍👍, Ayub, transition компонент для анимации и lite версия reactQuery , думаю многим будет интересна. 🚀🚀🚀🤯
Спасибо за фидбэк! Запишу себе.
🎉
это получается система реактивности в реакте пришла к тому виду к это было во Vue
Нет, в примере был preact
Да, в реакт нету сигналов. Только в ангуляр, солид и преакте.
С нулья? Полагаю, превью содержит ошибку
Хахаха, не заметил. Спасибо что описал. Надо будет поправить.
@@ayub_begimkulov, тебе спасибо за видео
Сложно
Я бы посоветовал с кодом поиграться - так легче понять.
мдаа, так что такое сигналы?)) чёт бородка вахабитская....
лайк ❤
Спасибо!