Ну всё тогда, значит прояснили
Как и в компоненте, в сервисе нужно вызывать хук и делать отписку

Сервис задестроится только тогда, когда уничтожается Injector в котором он запровайжен.

Если сервис запровайжен в Injector модуля, то он будет уничтожен только во время разработки с использованием hmr.

Если сервис запровайжен в кастомном Injector или в Injector компонента, то при их уничтожении сервис будет уничтожен.

При уничтожении сервиса используется хук ngOnDestroy() у сервиса.

Если подписка висит, и на неё есть ссылка с Root Node (например, event listener, setTimeout, fetch), то подписка будет висеть в памяти и удерживать ссылки.

Поэтому отписываться лучше всегда и делать это тогда, когда подписка уже не нужна.

вообще делать подписки в сервисе это не очень. лучше выводить в компоненты и директивы

Скажи это тому, кто писал этот код)))

Товарищи, есть вопрос.
Можно сделать архитектуру так, чтоб не хранить никакие данные в сервисах\компонентах, а построить всё на observable. Есть кто нибудь, кто практикует такой подход?

построить все на обсервабл и хранить в них данные в сервисах :)

нее, вообще не хранить. Т.е. не создавать behaviourSubject в сервисе, например.

https://medium.com/ngx/practical-use-rxjs-81aaab57045c

типа такого от @thekiba

там есть publishReplay, а внутри него ReplaySubject

но там же все это в сервис происходит?)

понятно, но это не вручную создавать сабджекты и следить за ними

но это же не то же самое, что

private _subject = new BehaviourSubject({});
public observable$ = this._subject.asObjservable();

энивей от сабжектов никуда не убежишь :)

private _subject = new BehaviourSubject({});
public observable$ = this._subject.asObjservable();

почему же

replaySubject следит за ними сам, меня это устраивает)

есть такой кейс.

Пользователь тыкает какой то элемент в списке. Я могу сделать в сервисе subject, который будет делать switchMap на запрос к серверу и возвращать данные и отписываться от прошлого запроса.

В случае, если я храню данные в behavoirSubject, я такое реализовать не могу. Ну по крайней мере просто

ничего не понял)

Классический пример (как по мне) switchMap - это когда мы берём поток из input и свитчим его для запроса на бэк

data$ = fromEvent().pipe(switchMap())

С таким подходом мне очень просто данные вывести в шаблон и я их нигде промежуточно не храню.

Если же я храню данные в сервисе, типа

data$ = this._subject.asObservable();

то как мне реализовать подобное поведение? Чтоб при возникновении события у меня происходила отписка от прошлого запроса, если он не выполнился

а ошибки как обрабатываются при таком подходе?

data$ имеет тип что то вроде

{data: data, error:  string | null, state: 'loading' | 'failed' | 'succeeded' }

в switchMap можно вернуть в зависимости от результата запроса разные объекты