BACK
Use casesTimeout fallback — API завис
Use cases · 30

Timeout fallback — API завис

Паттерн

Внешний API завис. Может, перегружен. Может, временная сетевая проблема. Мы не можем ждать вечно — экран не должен бесконечно показывать loading. Через N секунд показываем закешированные данные или сообщение.

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

Императивный setTimeout вокруг fetch сложно отменить, и легко получить двойной resolve: и таймаут сработал, и поздний ответ всё-таки пришёл. Какое значение применить?

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

  • timeout({ first: 30 }) — если первый ответ не пришёл за 30мс, генерирует error.
  • catchError — ловит timeout-ошибку и отдаёт fallback Observable.
  • of(fallback) — отдаёт закешированное значение или дефолт.

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

  • takeUntil(timer(N)) вместо timeout — просто complete без error. UI не покажет fallback, потому что не было ошибки.
  • Слишком короткий timeout — будете получать ложные таймауты на медленных мобильных сетях.
  • Не делайте retry на timeout бесконечно — это многократно усилит нагрузку на и так перегруженный API.

Что в итоге получаем

Зависший API превращается в предсказуемый fallback. Пользователь видит хоть что-то, а не вечно крутящийся спиннер.

script.ts // TypeScript
CONSOLE · Console Output
Нажмите на запуск, чтобы увидеть результат...