на мой взгляд takeuntil смотрится чище. https://github.com/evoytenkoapps/angular-best-practices/blob/4a12839ce1dc0960344ed2eeee62d8fc34dde6ed/examples/src/app/components/how-to-unsubscribe/unsubscribe.component.ts#L20
сложно мне, совсем зеленый в ангуляре
а что сложно пример под глазами. скопируйте пример с subject и спользуйте везде
но тем не менее, пример выше рабочий же ?
да, вроде рабочий
тоесть, как я понимаю, при работе с компонентом и его подписками, если не отписываться, то они по прежнему висят в памяти приложения, даже при работе уже с другим компонентом ?
как-то так. нюансов не знаю. там в общем ссылка на компонент висит в подписке и ее gc не удаляет из памяти, вроде так.
подписки в web api сохраняются, если не отписываться в условном onDestroy, то при каждом новом начальном рендере компонента, будут новые подписки добавляться поверх предыдущих и фсе
тоесть при новом рендере, даже иного компонента, на апи будут лететь запросы с подписок предыдущего компонента + текущего компонента ? что просто в итоге приведет к падению перформанса и перегрузке бека ?
если компонент в котором ты подписывался уничтожен, но ты не отписался, то подписки останутся и они будут работать дальше, там уже от ситуации зависит, на что ты вообще подписывался. Соответственно если ты опять отрендеришь этот компонент, то добавится столько же подписок поверх предыдущих и будет утечка памяти соответственно
ОнДестрой отрабатывает при ре-рендере компонента ?
onDestroy вызывается, когда компонент уничтожается, т.е. он удален из DOM. Допустим нажал на кнопку, пропал какой-то
к примеру, у меня есть компоненты, которым задан роутинг: 1) localhost/main 2) localhost/contacts компонент 1) имеет подписку при переходе на компонент 2) по роуту localhost/contacts подписка компонента 1) будет очищена?
вы про рендер или про создание компонента?
да я тут не совсем правильно выразился, но думаю дальше мысль передал)
Обсуждают сегодня