господа а какие преимущества недостатки у следующих двух записей в отличии друг от друга?

interval(10000).pipe(shareReplay(1), refCount())
interval(10000).subscribe(new ReplaySubject(1));

первая возвращает вечный обсервабл, вторая возвращает подписку

дам-с, много у вас в сообществе тех, кто понимает как оно работает...

я не спец, а что вы в итоге хотите получить?

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

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

и получается небольшая такая кашка из того какой подход выбрать

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

но
а) держать локальный стейт всех имеющихся продуктов = расход памяти
б) держать всех подписчиков - снова расход памяти
в) когда отписывать подписчиков и когда подписывать обратно

или я в переменную products$ сохраняю обсервабл, который будет открываться когда я подпишусь. но тогда вопрос - как сделать его кешируемым ровно до того момента, как мне захочется кеш этот обнулить. ведь shareReplay() сделает его закешированным навечно, а все условия его обновления на будущее предусмотреть сложно. думаю всё равно про управляющий сабжект, в который next() передается стейт, что по факту тот же сабжект с самими продуктами

или все таки наиболее центральный из этого путь это сделать управляющий сабжект куда присылается ('add', product), ('delete', product) и так далее, а сами продукты хранить в обычном свойстве сервиса и выводить в верстке из обычного свойства без асинков и прочего

я не понимаю проблемы. если вы про веб, то для решения подобных проблем уже  давно придумали redux. и библиотеки реализующие его. например для ангуляра это стейт менеджеры ngrx, ngxs ищи реализации стейт менеджеров для своей платформы, или пишите их аналог, по паттерну redux.

да, сейчас я в ангуляр подключу редукс и начну писать редюсеры

и будут у меня промизы обсерваблы и еще редюсеры

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

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

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

в ангуляре нет промисов, только rxjs

развивайте код на умные и глупые компоненты.

зачем умный компонент нужен если в ангуляре есть иньекция сервиса через конструктор. чем занимается умный?

а вообще я вас не понял.) вы умными словами описываете простые проблемы. на мой взгляд.