Use cases/Last good value — fallback на предыдущий успех
Use cases · 64 操
Last good value — fallback на предыдущий успех
Паттерн
Dashboard обновляется каждые 30 секунд. Если очередной refresh упал — НЕ показываем пустой экран. Оставляем последние известные хорошие данные, но честно помечаем «stale, последнее обновление 2 минуты назад».
Какую проблему решаем
Императивный код часто сбрасывает data = null перед refresh, и после failure пользователь видит пустоту вместо вчерашних данных. Плохой UX. С другой стороны, скрывать факт устаревания — тоже плохо.
Операторы и зачем они нужны
catchError(() => of({type: 'error'})) внутри refresh — failed запрос становится event, а не падением stream.
scan — хранит last successful value между attempts. На success обновляет, на error оставляет старое + помечает status=stale.
startWith('ok') — initial refresh.
Подводные камни
catchError СНАРУЖИ trigger stream — первая ошибка остановит все будущие refresh. Stream умрёт.
Не скрывайте stale/error status. Пользователь должен знать, что видит старые данные.
Для критичных данных (баланс счёта, медицинские данные) last good value может быть бизнес-неприемлем. Решайте per case.
Что в итоге получаем
UI сохраняет последний хороший результат, но честно помечает его как stale при ошибке. Пользователь видит данные и понимает их актуальность.