Александр, в первую очередь огромное спасибо за Ваши видео. У Вас всегда всё очень подробно, в то же время компактно по времени и очень понятно. Как в первый раз прочитал про сигналы, то тут же возникли ассоциации с Vue2, в котором computed уже был реализован. Как я понимаю сигналами хотят привлечь разработчиков реакта, которых сейчас большинство.
@@Kulibins1 не совсем, но там концепция работы с данными похожа в optional API. Во Vue это все достаточно хорошо оптимизировано и для новичков проще чем RxJS
минус rxJS пайпа async в том, что изначально передаётся null, а не undefined. Сигналы позволяют undefined сразу присваивать. Это вы пропустили) Ну и плюс сигналы как раз позволяют избавится от OnPush. Так же вы задали вопрос "Каким образом angular знает, что computed свойство изменилось и рендерит новое значение?" - всё просто, за счёт сигналов как раз ангуляр и понимает, что в конкретном месте идёт расхождение сигналов и обновляет ту ноду, а не запускает changeDetection
Я как бы в видео и рассказал как система понимает что произошлотизменение. и да async pipe просто делает markforcheck, компонента, и поэтому пока нет принципиальной разницы в производительности, на данный момент это задел на будущее. Про null - легко обходится. Но сигналы удобны тем, что они простые и что сколько смотрю, народ до сих пор не понимпет rxjs, может сигналы поймёт 🤣
Это гениально функцию на функцию вызываю функцию а как, а вот пример подписываем функцию возвращаем функцию! Более сумбурно, запутанно и непонятно я не знаю ни кого кто бы мог еще подобрать слова и объяснить! Надеюсь ваше эго удовлетворенно. Почему раньше читали чужой код по диагонали и все понятно сейчас всматриваешься в строчки и думаешь какого хрена это так сделано?!
Сигналы классные, можно сказать бойлерплейт уменьшает да, плюс так как там всегда есть значение, то типы лучше работают, например async pipe, который всегда возвращает value | null, приходится проверку на null в html разметке делать. Но в синхронных обзерваблах есть плюс. Сейчас computed через setTimeout вызывается, то есть когда мы нажали на кнопку, у нас сначала ангуляр запустит чендж детекшен для оригинальных сигналов, отрисует, а потом для computed. То есть будет двойной рендеринг, в то время как combineLatest всего один цикл прогонит. Но код выглядит лаконичнее для большинства сценариев и типизация более четкая - спору нет. Я сейчас стал в проекте вьюмодель на сигналы менять, а сам store остается в виде обзерваблов. Пока удобно как раз изза типизации. Если очень грубо, то асинк пайп поменялся на toSignal(..., { requireSync: true })
Согласен. В своём видео говорил не то что сигналы не нужны, а то что пока это не революция. А ещё один раздел который придётся знать новичку 🤣 Сам я конечно буду их применять.
По поводу перфоманса: чаще всего тормозит LCP с TBT, но тут врываются deferable views и как сигналы могут апнуть показатели lighthouse - пока что трудно представить.
Спасибо за видео. Как всегда максимально полезно и доходчиво. Но хотел уточнить один момент. Разве не уместнее вместо debounceTime(0) использовать observeOn(asyncSceduler), когда нам нужен именно один тик?
да как-то с debouncetime привычнее. и когда 0 ставишь, сколько тиков пройдёт никто не знает, т.к. ставится в очередь, а сколько времени текущая функция + микротаски + отрисовка ни кто не знает.
Интересно, как в computer реализовано получение списка переменных, от которых он зависит. Если в rx там явно передается массив с зависимостями, то тут передается просто функция, где в шаблоне строки вызываются 2 метода. Неужели это как-то парсится? Или там вообще нет такой зависимости, а просто каждый раз при обращении происходит перерасчет?
Здравствуйте, Александр. Можно ли немного подробнее про Observable рассказать? В частности о чем вы говорили в одном из роликов, про то что нужно возвращать new Observable из методов сервиса, который работает с httpClient? В интернете куча статей но я не смог найти на волнующий меня вопрос конкретного ответа. Спасибо.
Не прмню что бы я говорил возвращать new Observable. У меня был ролик где я показывал как работает rxjs, вот там делал new Observable. Тут нужно смотреть что мы возвращаем и не получить утечку памяти. Например где нужно использовать pipe first или take(1). Нужен пример или более подробное описание что не понятно. Для httpclient не нужно ничего делать, т.к. каждый запрос возвращает новый observable.
@@Kulibins1 Спасибо. По поводу утечки памяти, мы используем в команде @ngneat/untilDestroy декоратор и пайп. Но на мой взгляд использование моими коллегами until destroy даже при http запросах уже черезчур с учетом, что (если я не ошибаюсь) он делает complete в любом случае. Или все же лучше использовать?
@@BorderInVaisесли я правильно понимаю, такая отписка для http запроса делается на случай, если юзер уходит со страницы, а запрос ещё не был завершён, т.е. выполняется отмена запроса.
Спасибо за объяснения. Как мне кажется вокруг сигнала подняли большую шумиху. Сугубо мое мнение, (не претендующее на истину) использование RxJs более явно показывает что происходит в коде.
А есть ли смысл использовать сигналы, если нет необходиости использовать эффекты или compute? Видел где-то в примерах на просторах интернета, что сделали сингал isLoading() для обработки загрузки, пока асинхронный запрос куда-то ходит. А в чем смысл такого подхода, если я могу просто не сигналом сделать переменную isLoading? В другом месте прочтал, что сигналы позволят отказаться от zone.js. Но никак не пойму, как это должно работать? Мы же не можем какой-то настройкой отключить использование ангуляром zone.js? Там же было написано, что не нужно будет использовать стратегию onPush. Если у нас будет стоять CheckAlways, как сигналы защитят от постоянной проверки компонента?
Если у вас простая ситуация, то может и не нужно. Про отказ от zone.js говорят давно, но много кода прекратит работать и главное производительность в первую очередь зависит от кода программиста, много раз оптимизировал код, который, например в цикле для каждой итерации пересчитывал большую функцию, хотя можно было лишь в конце это сделать (пересчёт был не явным и вызывался через подписку rxjs). У меня сейчас есть проект на 14 angular, и я каждый раз страдаю, когда хочу сигналы 🤣
Произношение конечно нужно улучшать, но тут больше транслит, как пишется, так и читаю, т.к. это не совсем разговорный, многим не насителем языка так проще.
Мне так удобнее, т.к. пишу код ещё и на c#. Я даже не понимаю откуда изначально взяли оставлять скобку на той же строке, т.к. глазами удобнее вертикально смотреть начало и конец на одно и том же уровне. Даже возьмём форматирование json - там же скобка с новой строки. Да и в большинствр С подобных языках с новой строки.
Спасибо большое за видео по Angular. В то время как большенство пилят видосы по React, мало хорошего контента по Angular.
Мне React меньше нравится.
Спасибо за ваше ценное время и опыт, которые вкладываете в контент на своем канале!
всегда пожалуйста 😊
Спасибо за видео. Это просто топ. Ждем еще на подобные темы!!!
Рад видеть и слышать автора, жду каждое видео, так как всегда полезная информация. Только жаль, что редко)
Буду стараться больше роликов делать, а то план растёт быстрее чем снимаю.
Спасибо за разъяснения, очень интересно
Всегда пожалуйста 🤗
Очень интересное видео. Жду продолжения!
хорошо
Спасибо за полезную информацию. Ждем новых видосов по этой теме.)
👌
Александр, в первую очередь огромное спасибо за Ваши видео. У Вас всегда всё очень подробно, в то же время компактно по времени и очень понятно. Как в первый раз прочитал про сигналы, то тут же возникли ассоциации с Vue2, в котором computed уже был реализован. Как я понимаю сигналами хотят привлечь разработчиков реакта, которых сейчас большинство.
Да, думаю они перенимают полезные технологии которые реализованы на других платформах. И это хорошо.
Перешел со vue на angular, глядя на то как можно работать с signal, ощущаю вьетнамские флэшбэки)
Во vue тоже есть сигналы?
@@Kulibins1 не совсем, но там концепция работы с данными похожа в optional API. Во Vue это все достаточно хорошо оптимизировано и для новичков проще чем RxJS
Спасибо СЭР!
Всегда пожалуйста 😊
минус rxJS пайпа async в том, что изначально передаётся null, а не undefined. Сигналы позволяют undefined сразу присваивать. Это вы пропустили) Ну и плюс сигналы как раз позволяют избавится от OnPush. Так же вы задали вопрос "Каким образом angular знает, что computed свойство изменилось и рендерит новое значение?" - всё просто, за счёт сигналов как раз ангуляр и понимает, что в конкретном месте идёт расхождение сигналов и обновляет ту ноду, а не запускает changeDetection
Я как бы в видео и рассказал как система понимает что произошлотизменение. и да async pipe просто делает markforcheck, компонента, и поэтому пока нет принципиальной разницы в производительности, на данный момент это задел на будущее. Про null - легко обходится. Но сигналы удобны тем, что они простые и что сколько смотрю, народ до сих пор не понимпет rxjs, может сигналы поймёт 🤣
Интересная магия 👍
Сам удивился как всё просто.
Это гениально функцию на функцию вызываю функцию а как, а вот пример подписываем функцию возвращаем функцию! Более сумбурно, запутанно и непонятно я не знаю ни кого кто бы мог еще подобрать слова и объяснить! Надеюсь ваше эго удовлетворенно. Почему раньше читали чужой код по диагонали и все понятно сейчас всматриваешься в строчки и думаешь какого хрена это так сделано?!
мы про чьё эго говорим? 🤣
Сигналы классные, можно сказать бойлерплейт уменьшает да, плюс так как там всегда есть значение, то типы лучше работают, например async pipe, который всегда возвращает value | null, приходится проверку на null в html разметке делать. Но в синхронных обзерваблах есть плюс. Сейчас computed через setTimeout вызывается, то есть когда мы нажали на кнопку, у нас сначала ангуляр запустит чендж детекшен для оригинальных сигналов, отрисует, а потом для computed. То есть будет двойной рендеринг, в то время как combineLatest всего один цикл прогонит. Но код выглядит лаконичнее для большинства сценариев и типизация более четкая - спору нет. Я сейчас стал в проекте вьюмодель на сигналы менять, а сам store остается в виде обзерваблов. Пока удобно как раз изза типизации. Если очень грубо, то асинк пайп поменялся на toSignal(..., { requireSync: true })
Согласен. В своём видео говорил не то что сигналы не нужны, а то что пока это не революция. А ещё один раздел который придётся знать новичку 🤣 Сам я конечно буду их применять.
@@Kulibins1 не, сигналы удобнее. Я как раз рад, что так упростилось все
По поводу перфоманса: чаще всего тормозит LCP с TBT, но тут врываются deferable views и как сигналы могут апнуть показатели lighthouse - пока что трудно представить.
пака да, производительность обещают потом
Спасибо за видео. Как всегда максимально полезно и доходчиво. Но хотел уточнить один момент. Разве не уместнее вместо debounceTime(0) использовать observeOn(asyncSceduler), когда нам нужен именно один тик?
да как-то с debouncetime привычнее. и когда 0 ставишь, сколько тиков пройдёт никто не знает, т.к. ставится в очередь, а сколько времени текущая функция + микротаски + отрисовка ни кто не знает.
Из документации: Unlike Observables, signals never provide a synchronous notification of changes.
Интересно, как в computer реализовано получение списка переменных, от которых он зависит. Если в rx там явно передается массив с зависимостями, то тут передается просто функция, где в шаблоне строки вызываются 2 метода. Неужели это как-то парсится? Или там вообще нет такой зависимости, а просто каждый раз при обращении происходит перерасчет?
Про какие переменные мы говорим? Если про сигналы, то в этом видео и есть объяснение, а если про обычные, то это замыкание
Здравствуйте, Александр. Можно ли немного подробнее про Observable рассказать? В частности о чем вы говорили в одном из роликов, про то что нужно возвращать new Observable из методов сервиса, который работает с httpClient?
В интернете куча статей но я не смог найти на волнующий меня вопрос конкретного ответа. Спасибо.
Не прмню что бы я говорил возвращать new Observable. У меня был ролик где я показывал как работает rxjs, вот там делал new Observable. Тут нужно смотреть что мы возвращаем и не получить утечку памяти. Например где нужно использовать pipe first или take(1). Нужен пример или более подробное описание что не понятно. Для httpclient не нужно ничего делать, т.к. каждый запрос возвращает новый observable.
@@Kulibins1 Спасибо.
По поводу утечки памяти, мы используем в команде @ngneat/untilDestroy декоратор и пайп. Но на мой взгляд использование моими коллегами until destroy даже при http запросах уже черезчур с учетом, что (если я не ошибаюсь) он делает complete в любом случае. Или все же лучше использовать?
@@BorderInVaisесли я правильно понимаю, такая отписка для http запроса делается на случай, если юзер уходит со страницы, а запрос ещё не был завершён, т.е. выполняется отмена запроса.
Спасибо за объяснения. Как мне кажется вокруг сигнала подняли большую шумиху. Сугубо мое мнение, (не претендующее на истину) использование RxJs более явно показывает что происходит в коде.
Вот именно шумиха большая. Вещь безусловно полезная, но прям не однозначная.
А есть ли смысл использовать сигналы, если нет необходиости использовать эффекты или compute?
Видел где-то в примерах на просторах интернета, что сделали сингал isLoading() для обработки загрузки, пока асинхронный запрос куда-то ходит.
А в чем смысл такого подхода, если я могу просто не сигналом сделать переменную isLoading?
В другом месте прочтал, что сигналы позволят отказаться от zone.js.
Но никак не пойму, как это должно работать? Мы же не можем какой-то настройкой отключить использование ангуляром zone.js?
Там же было написано, что не нужно будет использовать стратегию onPush.
Если у нас будет стоять CheckAlways, как сигналы защитят от постоянной проверки компонента?
Если у вас простая ситуация, то может и не нужно. Про отказ от zone.js говорят давно, но много кода прекратит работать и главное производительность в первую очередь зависит от кода программиста, много раз оптимизировал код, который, например в цикле для каждой итерации пересчитывал большую функцию, хотя можно было лишь в конце это сделать (пересчёт был не явным и вызывался через подписку rxjs). У меня сейчас есть проект на 14 angular, и я каждый раз страдаю, когда хочу сигналы 🤣
видео норм. Но не все понятно.
Единственное что сбивает иногда - произношение. "Кампутит", "титл" :)
Произношение конечно нужно улучшать, но тут больше транслит, как пишется, так и читаю, т.к. это не совсем разговорный, многим не насителем языка так проще.
А в каких кейсах по итогу эти сигналы надо использовать?
Как лёгкая замена rxjs. как минимум где бихейверсабжект.
слегка бесит формат js'a в котором первую фигурную скобку переносят на новую строку
Мне так удобнее, т.к. пишу код ещё и на c#. Я даже не понимаю откуда изначально взяли оставлять скобку на той же строке, т.к. глазами удобнее вертикально смотреть начало и конец на одно и том же уровне. Даже возьмём форматирование json - там же скобка с новой строки. Да и в большинствр С подобных языках с новой строки.
На фоне шума с сигналами, где-то закурил автор Mobx...
mobx вещь 👍 мне redux не нравится.
ну так сигналы типа хотят внедрить в нативный js, пытаются стандартизировать это логику для всех
8:04 C# developer detected :D