Как думаете, имеет смысл использовать OnDestroy в рутовом сервисе? (хочется

Question

Как думаете, имеет смысл использовать OnDestroy в рутовом сервисе? (хочется

по дефолту прописать там логику для takeUntill, чтобы отписываться, но чет засомневался, что в случае рутового сервиса в этом есть смысл)

#angular #frontend #javascript #programming #russian

0

20.09.2021

25 ответов

22 просмотра

Test Test TEst Автор вопроса

Hey 👋, i'm 𝖙𝖍𝖊𝖐𝖎𝖇𝖆! キバ
Да, смысл есть всегда Сервис могут перепровайдить...

А как относишься к тому, чтобы сделать base компонент с каким-нибудь destroy$ сабджектом (чтобы скормить его в takeUntill) и затем наследовать от него остальные компоненты?

0

20.09.2021

Hey 👋, i'm 𝖙𝖍𝖊𝖐𝖎𝖇𝖆! キバ

Test Test TEst
А как относишься к тому, чтобы сделать base компон...

Наследование реализации — это плохо Реализация должна реализовывать абстракцию, а не наследовать себе ее логику

0

20.09.2021

Maxim Afanasev

Test Test TEst
А как относишься к тому, чтобы сделать base компон...

Вот же есть решение: https://taiga-ui.dev/services/destroy-service

0

20.09.2021

Stepan

Maxim Afanasev
Вот же есть решение: https://taiga-ui.dev/services...

https://github.com/ngneat/until-destroy Тоже сюда

0

20.09.2021

Stanislav

Stepan
https://github.com/ngneat/until-destroy Тоже сюда

два разных подхода же, и подход с декоратором костыльнее

0

20.09.2021

Madi

Hey 👋, i'm 𝖙𝖍𝖊𝖐𝖎𝖇𝖆! キバ
Наследование реализации — это плохо Реализация д...

А что такого, это ж наследование и это возможно а значит допустимо )

0

20.09.2021

Eugene

Hey 👋, i'm 𝖙𝖍𝖊𝖐𝖎𝖇𝖆! キバ
Наследование реализации — это плохо Реализация д...

Плохо в каком плане? Я как раз сейчас задаюсь вопросом, какой подход удобнее, использовать DestroyService и в каждой подписке указывать takeUntil или создать примерно такой класс @Injectable() export class Expample implements OnDestroy { protected subscriptions:{[key:string]:Subscription} = {}; ngOnDestroy():void { Object.values(this.subscriptions).forEach(sub=>sub?.unsubscribe()); } } И наследовать его. Пока склоняюсь ко второму варианту, т.к. у меня этот класс будут наследовать компоненты, которые я в дальнейшем также буду наследовать

0

20.09.2021

Stanislav

Eugene
Плохо в каком плане? Я как раз сейчас задаюсь вопр...

выходит каждый сервис будет реализацией реализации а не интерфейса, это стремно выглядит в итоге

0

20.09.2021

Stanislav

Stanislav
выходит каждый сервис будет реализацией реализации...

тем более делать push в массив подписок, равноценно takeUntil, не вижу преимуществ никаких

0

20.09.2021

Юра 🪐

Stanislav
выходит каждый сервис будет реализацией реализации...

реализацией реализации что-то сложно))

0

20.09.2021

Юра 🪐

Hey 👋, i'm 𝖙𝖍𝖊𝖐𝖎𝖇𝖆! キバ
Наследование реализации — это плохо Реализация д...

к примеру AbstractControl у него есть логика

0

20.09.2021

Madi

Eugene
Плохо в каком плане? Я как раз сейчас задаюсь вопр...

Норм вариант, класс лучше

0

20.09.2021

Eugene

Stanislav
выходит каждый сервис будет реализацией реализации...

Вот я и хочу выяснить, что значит стремно. В проекте я наследую компоненты с целью переиспользования логики, поэтому мне удобнее решить проблему отписок через наследование

0

20.09.2021

Hey 👋, i'm 𝖙𝖍𝖊𝖐𝖎𝖇𝖆! キバ

Юра 🪐
к примеру AbstractControl у него есть логика

FormControl и другие контролы реализуют AbstractControl Компонент, который наследует класс, в котором просто есть ngOnDestroy с отпиской, не реализует этот класс

0

20.09.2021

Юра 🪐

Hey 👋, i'm 𝖙𝖍𝖊𝖐𝖎𝖇𝖆! キバ
FormControl и другие контролы реализуют AbstractCo...

хмм, ну да

0

20.09.2021

Юра 🪐

Eugene
Плохо в каком плане? Я как раз сейчас задаюсь вопр...

У меня была сторя на проекте убрать наследование классов у которых просто NgOnDestroy

0

20.09.2021