Привет всем) RxJS тесно связан с angular. В этом видео мы рассмотрим как отписываться от rxjs observable классов, даже если вы все еще подписываетесь на глобальные объекты через document то в этом видео вы узнаете как не мусорить после себя А подробнее об RXJS можно посмотреть в моем старом, но актуальном плейлисте ua-cam.com/video/5iIlWkWzsAE/v-deo.html А если попал на это видео случайно, то по возможности начинай с первого плейлиста, а все плейлисты цикла можно найти по этой ссылке ua-cam.com/channels/lDDVLu0Cj_o9Y5D2ilCtdQ.htmlplaylists?view=50&sort=dd&shelf_id=1
Классный урок! На счёт destroyed, чтобы не писать его в каждом компоненте, юзает базовый компонент который содержит его. Так про это мало кто на русском ютубе рассказывает. Просто красавчик 😎
Не люблю наследование, через декоратор было бы лучше, но тогда нужно объяснить ангулар что декоратор добавит дополнительное свойство, которое не будет подсвечивать С наследованием в ngOnInit придётся писать super.ngOnInit() в каждом наследнике И также с методом ngOnDestroy если такой понадобится в наследнике
Использование базовых компонентов с целью отписок является плохой практикой. Нам нужно наследоваться от этого компонента, использовать super() в конструкторе, использовать внешний лайфсайкл дестрой. Затем наш компонент в итоге зависит от этого класса. А потом захочется еще что-то пихнуть туда и т.п. Не думаю, что использование этого базового компонента позитивно скажется на сформированных бандлах. Короче, это не такая прям "оптимизация". Так что, я полностью согласен с Максом. Как по мне, сабджекты - это идеальная практика для отписок от потоков и ничего лишнего. Если ну прям хочется вам еще меньше кода сделать, то есть npm пакет ngx-take-until-destroy.
@mikamika мдааа…, як для мене, абстрактний клас для вирішення питання відписок - це крінж. Таке відчуття, що хочете придумати свій велосипед у даному випадку. Так може ще плагіни ставити для відписок?) Чи можливо ще напишемо свою лібу? Не потрібно збільшувати залежності в проекті та робити свої декоратори, наслідування і тому подібне. Там робіть як хочете, ваші проблеми, ваш проект)
привет! а как так получается, что сначала мы кликаем по документу, потом перемнная show становится true, потом запускается ngOnInit, в котором происходит подписка на клики по документу, но эта подписка сразу же стреляет? откуда подписка узнала про последний клик, если подписка произошла уже после клика? 6:38
Привет, наблюдательно! С такими скилами самые сложные баги вылавливать нужно 😺 Получается ангулар синхронно это делает, сработал клик, обработчик сделал дело, т.е. поменял свойство, далее отработал движок перерисовки, можно считать что прямо в обработчике (ангулар его задекорировал и запустил мгновенно перерисовку). Перерисовка окончилась и обработчик события закончил работать на кнопке и событие полетело вверх по DOM (смотри всплытие событий в DOM JavaScript) и наша свежая подписка на document click его словила Будь бы это асинхронный процесс, такого бы не произошло
В видео об этом говорил, лучше в ngOnInit :) потому что рано или поздно в АПИ нужно будет передать параметры из Input А если есть такой шанс, что все или хотябы один запрос обязан быть в ngOnInit то лучше сразу действовать на опережение Ну и существует не нулевая вероятность ошибки (исключения) в конструкторе, в этом случае подписка произойдёт, но ngOnDestroy не вызовется и произойдёт утечка памяти
@@grommaks эх... хотел показать самый простой и быстрой способ подписки / одписки. Но если кратко, то можно создавать объект подписок в переменной, т.е. subs равно new Subscription(). И потом просто все подписки добавлять через subs.add(подписка). А отписаться можно за раз от всего объекта через subs.unsubscribe()
Ничего не мешает, и часто так и делают. Но в конструкторе нет инпутов, из-за этого если через пару месяцев работы над проектом понадобится в эту подписку передать параметр инпута, то нужно будет переносить код в ngOnInit
@@leonidsimakov859 не нужно OnDestroy имплементировать, а достигается за счёт декоратора на классе SubSink добавляет сеттер для удобства и метод для отписки, но все еще заставляет имплементировать OnDestroy
Верно, практически всегда для разработчика результат будет один и тот же. Цель убить подписку достигнута или через отписку или через завершение стрима…мне стоило указать что это не одно и то же. Спасибо за дополнение 👍
полностью не соглсен с подпиской в массиве. За подпиской может стоять сложная логика, как потом прикажешь искать в массиве нужную тебе, по индексу? Да, в массиве оно выглядит чистенько, но для понимания логики компонента, который первый раз видишь в глаза я бы этого не делал. Разве что у тебя какието банальные подписки, автоваладиция какая-то или еще что... ПС: спасибо за уроки. Я хоть с ангуляром уже 2 года, но многие базовые вещи забываются, когда делаешь на автомате и уже не думаешь: "почему так, а не иначе"
По этому рекомендовал takeUntil, интересно в каких случаях нужно отписываться не во время удаления компонента?) на практике не приходилось с таким сталкиваться, всегда через rxjs операторы удавалось решить необходимую логику
@@grommaks может для каких-то глобальных ui компонентов, которые действует почти по всему преложению, а там где компонент дропается продолжает следить потому, что нужна память этой подписки... Можно таким образом реализовать скрол к месту, где ты закончил читать статью перейдя в настройки.
Можно указать тип void для Subject'а и не передавать true Еще можно сделать сервис, который будет отвечать за отписку и иметь поле destroyed$, а потом указывать его в providers компонента, чтобы он умирал вместе с ним
А я вот люблю в сервисах пихать все возможные подписки в конструктор. Точнее так создаю массив в который пихаю все подписки и потом при нгДестрой , отписываюсь от всего в цикле так как все элементы имеют тип subscription.
for each вызывает функцию на каждую итерацию Можно легко протестировать, сделать 1000 элементов в массиве и внутри цикла запустить еще один цикл что приведет к 1кк циклов и сравнить время For быстрее stackoverflow.com/questions/43031988/javascript-efficiency-for-vs-foreach javascript.plainenglish.io/javascript-for-loops-vs-for-each-the-difference-explained-39a1378f14d7
@@grommaks // Testing with forEach const array1 = Array.from({ length: 1000000 }, (_, index) => index); console.time('forEach'); array1.forEach(item => { // Your logic here (optional) }); console.timeEnd('forEach'); // Testing with for loop const array2 = Array.from({ length: 1000000 }, (_, index) => index); console.time('forLoop'); for (let i = 0; i < array2.length; i++) { const item = array2[i]; // Your logic here (optional) } console.timeEnd('forLoop'); да, вышло, что forEach 4ms, а for 1ms Не понимаю как на видео, которое я указала в прошлом комментарии у него выходит иначе.
Привет всем)
RxJS тесно связан с angular. В этом видео мы рассмотрим как отписываться от rxjs observable классов, даже если вы все еще подписываетесь на глобальные объекты через document то в этом видео вы узнаете как не мусорить после себя
А подробнее об RXJS можно посмотреть в моем старом, но актуальном плейлисте
ua-cam.com/video/5iIlWkWzsAE/v-deo.html
А если попал на это видео случайно, то по возможности начинай с первого плейлиста, а все плейлисты цикла можно найти по этой ссылке
ua-cam.com/channels/lDDVLu0Cj_o9Y5D2ilCtdQ.htmlplaylists?view=50&sort=dd&shelf_id=1
Спасибо за урок! Вроде всё и знал, но сейчас увидел действия и подходы с практической точки зрения и словно пелена ушла!!!
Даже не знаю, осилил бы я Angular без твоего канала...
Спасибо!!!
Spasibo Maxim!
Я всегда инициализирую переменные. Иначе эти вопросики задолбаешься в unit тестах тестировать для покрытия по бранчам. Спасибо за видео.
Успехов тебе на ютубе
Очень много полезной инфы
подписка, колокольчик, лайк и коммент)
Хотелось бы еще на декораторе решение увидеть)
Классный урок! На счёт destroyed, чтобы не писать его в каждом компоненте, юзает базовый компонент который содержит его. Так про это мало кто на русском ютубе рассказывает. Просто красавчик 😎
Не люблю наследование, через декоратор было бы лучше, но тогда нужно объяснить ангулар что декоратор добавит дополнительное свойство, которое не будет подсвечивать
С наследованием в ngOnInit придётся писать super.ngOnInit() в каждом наследнике
И также с методом ngOnDestroy если такой понадобится в наследнике
Использование базовых компонентов с целью отписок является плохой практикой. Нам нужно наследоваться от этого компонента, использовать super() в конструкторе, использовать внешний лайфсайкл дестрой. Затем наш компонент в итоге зависит от этого класса. А потом захочется еще что-то пихнуть туда и т.п. Не думаю, что использование этого базового компонента позитивно скажется на сформированных бандлах. Короче, это не такая прям "оптимизация".
Так что, я полностью согласен с Максом.
Как по мне, сабджекты - это идеальная практика для отписок от потоков и ничего лишнего.
Если ну прям хочется вам еще меньше кода сделать, то есть npm пакет ngx-take-until-destroy.
@@yevhen3934 Видел этот пакет, мне понравился, но мы не стали его брать в силу политик безопасности на проекте
@mikamika есть на выбор варианты, по ряду объективных причин наследование самый худший вариант ;)
@mikamika мдааа…, як для мене, абстрактний клас для вирішення питання відписок - це крінж. Таке відчуття, що хочете придумати свій велосипед у даному випадку. Так може ще плагіни ставити для відписок?) Чи можливо ще напишемо свою лібу?
Не потрібно збільшувати залежності в проекті та робити свої декоратори, наслідування і тому подібне.
Там робіть як хочете, ваші проблеми, ваш проект)
привет! а как так получается, что сначала мы кликаем по документу, потом перемнная show становится true, потом запускается ngOnInit, в котором происходит подписка на клики по документу, но эта подписка сразу же стреляет? откуда подписка узнала про последний клик, если подписка произошла уже после клика? 6:38
Привет, наблюдательно! С такими скилами самые сложные баги вылавливать нужно 😺
Получается ангулар синхронно это делает, сработал клик, обработчик сделал дело, т.е. поменял свойство, далее отработал движок перерисовки, можно считать что прямо в обработчике (ангулар его задекорировал и запустил мгновенно перерисовку). Перерисовка окончилась и обработчик события закончил работать на кнопке и событие полетело вверх по DOM (смотри всплытие событий в DOM JavaScript) и наша свежая подписка на document click его словила
Будь бы это асинхронный процесс, такого бы не произошло
Cool
Классно
где лучше дергать рест урлы : в конструкторе или в ngOninit ?
В ngoninit
В видео об этом говорил, лучше в ngOnInit :) потому что рано или поздно в АПИ нужно будет передать параметры из Input
А если есть такой шанс, что все или хотябы один запрос обязан быть в ngOnInit то лучше сразу действовать на опережение
Ну и существует не нулевая вероятность ошибки (исключения) в конструкторе, в этом случае подписка произойдёт, но ngOnDestroy не вызовется и произойдёт утечка памяти
почему мои комменты удаляются через несколько секунд(( это такой бан? ссылок в них нет, просто кусочек когда, который долго писал((
Пути Ютуба не исповедимы... :( у ютуба особые алгоритмы по комментам стали последний год
@@grommaks эх... хотел показать самый простой и быстрой способ подписки / одписки. Но если кратко, то можно создавать объект подписок в переменной, т.е. subs равно new Subscription(). И потом просто все подписки добавлять через subs.add(подписка). А отписаться можно за раз от всего объекта через subs.unsubscribe()
@@user-san-chous Поковырял в коде, прикольный вариант! Странно что о нем нигде нет упоминаний) Спасибо
Ага, тот же вариант хотел предложить, коллега подсказал, что так можно. И да ютуб грохает мои комменты тоже :))
Тоже удивился, когда не увидел написанный мной комментарий с кодом)
вопрос: что мешает нам проинитить ансабскрайбовый сабжект и фромивентовую отписку по takeountil-у внутри конструктора?
Ничего не мешает, и часто так и делают. Но в конструкторе нет инпутов, из-за этого если через пару месяцев работы над проектом понадобится в эту подписку передать параметр инпута, то нужно будет переносить код в ngOnInit
Когда новые видео?
Или можно установить пакет SubSink и использовать его для подписок и отписок
Есть пакеты получше, я бы не стал тянуть такую зависимость
Например какие?
@@leonidsimakov859 ngx-take-until-destroy на декораторе решение
@@grommaks Снова удалился мой коммент, чем лучше это решение? Разве это не только лишь вкусовщина?
@@leonidsimakov859 не нужно OnDestroy имплементировать, а достигается за счёт декоратора на классе
SubSink добавляет сеттер для удобства и метод для отписки, но все еще заставляет имплементировать OnDestroy
но takeUntil именно завершает стрим, а не отписывается от него
Верно, практически всегда для разработчика результат будет один и тот же. Цель убить подписку достигнута или через отписку или через завершение стрима…мне стоило указать что это не одно и то же.
Спасибо за дополнение 👍
полностью не соглсен с подпиской в массиве. За подпиской может стоять сложная логика, как потом прикажешь искать в массиве нужную тебе, по индексу? Да, в массиве оно выглядит чистенько, но для понимания логики компонента, который первый раз видишь в глаза я бы этого не делал. Разве что у тебя какието банальные подписки, автоваладиция какая-то или еще что...
ПС: спасибо за уроки. Я хоть с ангуляром уже 2 года, но многие базовые вещи забываются, когда делаешь на автомате и уже не думаешь: "почему так, а не иначе"
По этому рекомендовал takeUntil, интересно в каких случаях нужно отписываться не во время удаления компонента?) на практике не приходилось с таким сталкиваться, всегда через rxjs операторы удавалось решить необходимую логику
@@grommaks может для каких-то глобальных ui компонентов, которые действует почти по всему преложению, а там где компонент дропается продолжает следить потому, что нужна память этой подписки... Можно таким образом реализовать скрол к месту, где ты закончил читать статью перейдя в настройки.
Можно указать тип void для Subject'а и не передавать true
Еще можно сделать сервис, который будет отвечать за отписку и иметь поле destroyed$, а потом указывать его в providers компонента, чтобы он умирал вместе с ним
Вариантов отписки больше чем один, спасибо за дополнение 👍
готовишся к Angular GDE? )
А что это?) я просто готовлюсь на эксперта пройти повышение в фирме 😼
@@grommaks погугли ) это тоже самое что у тебя на фирме, только с гуглом )
А я вот люблю в сервисах пихать все возможные подписки в конструктор. Точнее так создаю массив в который пихаю все подписки и потом при нгДестрой , отписываюсь от всего в цикле так как все элементы имеют тип subscription.
Черт в следущий раз надо смотреть все видео прежде чем комментировать 😅
@@rey4eel 😹
А вы уверены, что forEach менее производителен чем for? ua-cam.com/video/FOYIf5UBD9Q/v-deo.html тут на 20 минуте обратное излагают
for each вызывает функцию на каждую итерацию
Можно легко протестировать, сделать 1000 элементов в массиве и внутри цикла запустить еще один цикл что приведет к 1кк циклов и сравнить время
For быстрее
stackoverflow.com/questions/43031988/javascript-efficiency-for-vs-foreach
javascript.plainenglish.io/javascript-for-loops-vs-for-each-the-difference-explained-39a1378f14d7
@@grommaks
// Testing with forEach
const array1 = Array.from({ length: 1000000 }, (_, index) => index);
console.time('forEach');
array1.forEach(item => {
// Your logic here (optional)
});
console.timeEnd('forEach');
// Testing with for loop
const array2 = Array.from({ length: 1000000 }, (_, index) => index);
console.time('forLoop');
for (let i = 0; i < array2.length; i++) {
const item = array2[i];
// Your logic here (optional)
}
console.timeEnd('forLoop');
да, вышло, что forEach 4ms, а for 1ms
Не понимаю как на видео, которое я указала в прошлом комментарии у него выходит иначе.
Комент пишется -- статистика мутится)).