Cache invalidation — обновляем shareReplay cache

Паттерн

shareReplay кеширует ответ для всех подписчиков — отлично, пока данные не меняются. Но после mutation (создали/удалили/изменили запись) нужен способ принудительно перезагрузить кеш.

Какую проблему решаем

Если просто использовать shareReplay(1) — ответ навсегда заморожен. Сделали POST, обновили данные на сервере, а UI показывает старое. Императивный сброс полей сервиса разваливается при множественных подписчиках.

Операторы и зачем они нужны

• Subject — invalidation trigger. Вызываем invalidate$.next(), чтобы пересоздать кеш.
• startWith — initial load без отдельного метода. Первая загрузка происходит сама.
• switchMap — при новом trigger отменяет старый запрос, начинает свежий.
• shareReplay({ bufferSize: 1, refCount: true }) — все подписчики получают один и тот же кешированный ответ. refCount нужен, чтобы отключать upstream, когда подписчиков нет.

Подводные камни

• shareReplay(1) без object-конфига — refCount: false по умолчанию, и upstream живёт вечно. Это утечка.
• mergeMap вместо switchMap — два параллельных refresh, старый может перетереть новый.
• Не забывайте вызывать invalidate$.next() после успешной mutation. Иначе UI будет показывать stale-данные.