Constructor vs OnInit где писать код? OnDestroy, все варианты отписки в компоненте
ฝัง
- เผยแพร่เมื่อ 4 ก.ค. 2024
- Подписка и отписка от Observable в angular это типичная задача angular разработчика. И методы жизненного цикла ngOnInit и метод ngOnDestroy позволяют подписаться и отписатсья соответственно.
Задача отписки имеет множество решений, и в этом видео мы рассмотрели все важные варинты:
- unsubsctibe
- отписка от массива подписок
- отписка через takeUntil
Более того, в этом видео мы ответили на вопрос, чем отличается contructor от ngOnInit и где писать код инициализации. Ведь на собеседовании я проверю как усвоили урок)
==============================
Код готового урока:
github.com/MaksymGrom/angular...
==============================
Инструкция по установке angular проекта:
Вариант 1:
Пройдите плейлист: • Как работает WEB. Мест...
Вариант 2:
Склонируйте github.com/MaksymGrom/angular...
Загрузите зависимости (npm install)
Можно запускать проект (ng serve)
==============================
Выбор редактора код это дело каждого, но в этом плейлисте я использую webstorm. Как настроить один из популярнейших редакторов ниже:
VS Code: • VS Code extensions для...
WebStorm: • WebStorm работа с angu...
Не забываем что SQL важен независимо чем планируешь заниматься при веб разработке, даже если планируешь быть менеджером проектов.
Курс по SQL можно найти по ссылке: • Что такое SQL? Как раб...
Спасибо что продолжаете смотреть меня и радовать комментариями.
---- Соц сети
Телеграм, где можно узнать о новых видео и получать доп контент
t.me/webDevGromMaxChannel
P.S. В youtube я отвечаю быстрее чем в telegram, буду рад комментам в youtube
----
Чтобы поддержать канал
1) Можно поставить лайк (или дизлайк, если не понравилось видео)
2) Оставить комментарий более 5 слов
3) Досмотреть видео до конца (так удержание будет выше и мне это поможет в продвижении)
4) Оставить отзыв в комментариях, что можно улучшить в видео, чтобы не хотелось его закрывать
#grommax #angular #lifecycle
Материально поддержать канал можно следующим способом
1) Перевод на карту send.monobank.ua/7oqmsFg3Y
2) Пройти опрос, чтобы помочь выбрать подходящие варианты поддержки
forms.gle/ZbFCKJSpDNYp4AMC6
Оглавление
00:00 - Введение
00:23 - constructor vs ngOnInit
03:11 - Для чего нужен ngOnDestroy
04:08 - Почему отписываться нужно
05:12 - Отписка от событий. Вариант 1
06:47 - Отписка от событий в массиве. Вариант 2
08:56 - Отписка от событий takeUntil. Вариант 3
12:02 - Краткий гайд
Привет всем)
RxJS тесно связан с angular. В этом видео мы рассмотрим как отписываться от rxjs observable классов, даже если вы все еще подписываетесь на глобальные объекты через document то в этом видео вы узнаете как не мусорить после себя
А подробнее об RXJS можно посмотреть в моем старом, но актуальном плейлисте
th-cam.com/video/5iIlWkWzsAE/w-d-xo.html
А если попал на это видео случайно, то по возможности начинай с первого плейлиста, а все плейлисты цикла можно найти по этой ссылке
th-cam.com/channels/lDDVLu0Cj_o9Y5D2ilCtdQ.htmlplaylists?view=50&sort=dd&shelf_id=1
Спасибо за урок! Вроде всё и знал, но сейчас увидел действия и подходы с практической точки зрения и словно пелена ушла!!!
Даже не знаю, осилил бы я Angular без твоего канала...
Спасибо!!!
Я всегда инициализирую переменные. Иначе эти вопросики задолбаешься в unit тестах тестировать для покрытия по бранчам. Спасибо за видео.
Spasibo Maxim!
Успехов тебе на ютубе
Очень много полезной инфы
подписка, колокольчик, лайк и коммент)
Хотелось бы еще на декораторе решение увидеть)
Cool
Классно
Можно указать тип void для Subject'а и не передавать true
Еще можно сделать сервис, который будет отвечать за отписку и иметь поле destroyed$, а потом указывать его в providers компонента, чтобы он умирал вместе с ним
Вариантов отписки больше чем один, спасибо за дополнение 👍
Классный урок! На счёт destroyed, чтобы не писать его в каждом компоненте, юзает базовый компонент который содержит его. Так про это мало кто на русском ютубе рассказывает. Просто красавчик 😎
Не люблю наследование, через декоратор было бы лучше, но тогда нужно объяснить ангулар что декоратор добавит дополнительное свойство, которое не будет подсвечивать
С наследованием в ngOnInit придётся писать super.ngOnInit() в каждом наследнике
И также с методом ngOnDestroy если такой понадобится в наследнике
Использование базовых компонентов с целью отписок является плохой практикой. Нам нужно наследоваться от этого компонента, использовать super() в конструкторе, использовать внешний лайфсайкл дестрой. Затем наш компонент в итоге зависит от этого класса. А потом захочется еще что-то пихнуть туда и т.п. Не думаю, что использование этого базового компонента позитивно скажется на сформированных бандлах. Короче, это не такая прям "оптимизация".
Так что, я полностью согласен с Максом.
Как по мне, сабджекты - это идеальная практика для отписок от потоков и ничего лишнего.
Если ну прям хочется вам еще меньше кода сделать, то есть npm пакет ngx-take-until-destroy.
@@yevhen3934 Видел этот пакет, мне понравился, но мы не стали его брать в силу политик безопасности на проекте
@mikamika есть на выбор варианты, по ряду объективных причин наследование самый худший вариант ;)
@mikamika мдааа…, як для мене, абстрактний клас для вирішення питання відписок - це крінж. Таке відчуття, що хочете придумати свій велосипед у даному випадку. Так може ще плагіни ставити для відписок?) Чи можливо ще напишемо свою лібу?
Не потрібно збільшувати залежності в проекті та робити свої декоратори, наслідування і тому подібне.
Там робіть як хочете, ваші проблеми, ваш проект)
полностью не соглсен с подпиской в массиве. За подпиской может стоять сложная логика, как потом прикажешь искать в массиве нужную тебе, по индексу? Да, в массиве оно выглядит чистенько, но для понимания логики компонента, который первый раз видишь в глаза я бы этого не делал. Разве что у тебя какието банальные подписки, автоваладиция какая-то или еще что...
ПС: спасибо за уроки. Я хоть с ангуляром уже 2 года, но многие базовые вещи забываются, когда делаешь на автомате и уже не думаешь: "почему так, а не иначе"
По этому рекомендовал takeUntil, интересно в каких случаях нужно отписываться не во время удаления компонента?) на практике не приходилось с таким сталкиваться, всегда через rxjs операторы удавалось решить необходимую логику
@@grommaks может для каких-то глобальных ui компонентов, которые действует почти по всему преложению, а там где компонент дропается продолжает следить потому, что нужна память этой подписки... Можно таким образом реализовать скрол к месту, где ты закончил читать статью перейдя в настройки.
но takeUntil именно завершает стрим, а не отписывается от него
Верно, практически всегда для разработчика результат будет один и тот же. Цель убить подписку достигнута или через отписку или через завершение стрима…мне стоило указать что это не одно и то же.
Спасибо за дополнение 👍
вопрос: что мешает нам проинитить ансабскрайбовый сабжект и фромивентовую отписку по takeountil-у внутри конструктора?
Ничего не мешает, и часто так и делают. Но в конструкторе нет инпутов, из-за этого если через пару месяцев работы над проектом понадобится в эту подписку передать параметр инпута, то нужно будет переносить код в ngOnInit
привет! а как так получается, что сначала мы кликаем по документу, потом перемнная show становится true, потом запускается ngOnInit, в котором происходит подписка на клики по документу, но эта подписка сразу же стреляет? откуда подписка узнала про последний клик, если подписка произошла уже после клика? 6:38
Привет, наблюдательно! С такими скилами самые сложные баги вылавливать нужно 😺
Получается ангулар синхронно это делает, сработал клик, обработчик сделал дело, т.е. поменял свойство, далее отработал движок перерисовки, можно считать что прямо в обработчике (ангулар его задекорировал и запустил мгновенно перерисовку). Перерисовка окончилась и обработчик события закончил работать на кнопке и событие полетело вверх по DOM (смотри всплытие событий в DOM JavaScript) и наша свежая подписка на document click его словила
Будь бы это асинхронный процесс, такого бы не произошло
где лучше дергать рест урлы : в конструкторе или в ngOninit ?
В ngoninit
В видео об этом говорил, лучше в ngOnInit :) потому что рано или поздно в АПИ нужно будет передать параметры из Input
А если есть такой шанс, что все или хотябы один запрос обязан быть в ngOnInit то лучше сразу действовать на опережение
Ну и существует не нулевая вероятность ошибки (исключения) в конструкторе, в этом случае подписка произойдёт, но ngOnDestroy не вызовется и произойдёт утечка памяти
А я вот люблю в сервисах пихать все возможные подписки в конструктор. Точнее так создаю массив в который пихаю все подписки и потом при нгДестрой , отписываюсь от всего в цикле так как все элементы имеют тип subscription.
Черт в следущий раз надо смотреть все видео прежде чем комментировать 😅
@@rey4eel 😹
Когда новые видео?
почему мои комменты удаляются через несколько секунд(( это такой бан? ссылок в них нет, просто кусочек когда, который долго писал((
Пути Ютуба не исповедимы... :( у ютуба особые алгоритмы по комментам стали последний год
@@grommaks эх... хотел показать самый простой и быстрой способ подписки / одписки. Но если кратко, то можно создавать объект подписок в переменной, т.е. subs равно new Subscription(). И потом просто все подписки добавлять через subs.add(подписка). А отписаться можно за раз от всего объекта через subs.unsubscribe()
@@user-san-chous Поковырял в коде, прикольный вариант! Странно что о нем нигде нет упоминаний) Спасибо
Ага, тот же вариант хотел предложить, коллега подсказал, что так можно. И да ютуб грохает мои комменты тоже :))
Тоже удивился, когда не увидел написанный мной комментарий с кодом)
Или можно установить пакет SubSink и использовать его для подписок и отписок
Есть пакеты получше, я бы не стал тянуть такую зависимость
Например какие?
@@leonidsimakov859 ngx-take-until-destroy на декораторе решение
@@grommaks Снова удалился мой коммент, чем лучше это решение? Разве это не только лишь вкусовщина?
@@leonidsimakov859 не нужно OnDestroy имплементировать, а достигается за счёт декоратора на классе
SubSink добавляет сеттер для удобства и метод для отписки, но все еще заставляет имплементировать OnDestroy
готовишся к Angular GDE? )
А что это?) я просто готовлюсь на эксперта пройти повышение в фирме 😼
@@grommaks погугли ) это тоже самое что у тебя на фирме, только с гуглом )
А вы уверены, что forEach менее производителен чем for? th-cam.com/video/FOYIf5UBD9Q/w-d-xo.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
Не понимаю как на видео, которое я указала в прошлом комментарии у него выходит иначе.
Комент пишется -- статистика мутится)).