диспатч очистки стейта ?
Да это и не хорошо, и не плохо, если нужно так делать — делай )
Мне кажется диспатч в ондестрое не очень хорошо...?
А зачем он там? Если логика в очистке данных связаных с жизненным циклом компонента - где ж им еще быть?
для отписки а очисту стейта делать при реквесте например в онИните
Для отписки удобной мож попробовать UntilDestroy декоратор и untilDestroyed оператор в пайп P.s. из либы ng-neat/чё-то там
или слделать базовый компонент с ондестроем и ансабскрайбом и наследоваться от него в компоннентах чтобы не делать ансабскрайб в каждом компоненте ..
А вот это уже похоже на очень плохое решение Наследовать компоненты точно не стоит
Пробей в чате по поиску
раньше я любил наследование, потом как то ушел в отпуск и когда вышел из отпуска сел за свой же проект и понял что я не понимаю что где вообще, и пришлось весь проект пересмотреть чтобы понять как вообще что работает у меня же в коде)) так что лучше не юзать наследование, вот этот проект https://github.com/rucken/core/blob/develop/libs/rucken/web/src/lib/entities/groups/groups-grid/groups-grid.component.ts
https://www.npmjs.com/package/@ngneat/until-destroy Вот, держи, сэкономишь на всем, и на лишних телодвижениях в компонентах и проекте и на силах
Если в нескольких словах, то наследование логики — плохо, а реализация абстракции — хорошо Более подробно можно найти по ключевой фразе Liskov substitution principle, LSP, SOLID
дада думала об абстракции
Если в абстракции будет только метод ngOnDestroy и это будет использоваться везде, то это все ещё будет наследование логики, а не реализация
Обсуждают сегодня