Модуль 4 · урок 6 з 13
Керування часом
Оператори часу вирішують одну задачу: подій занадто багато. Користувач набирає десять символів — це десять запитів. Скролить сторінку — сотні подій за секунду. Ці кілька операторів перетворюють потік подій на розумну частоту.
debounceTime — дочекатись паузи
searchInput$.pipe(
debounceTime(300), // чекаємо 300 мс тиші, і лише тоді пропускаємо значення
);
debounceTime реагує на кінець серії подій, throttleTime —
на початок і далі обмежує частоту.throttleTime і auditTime
scroll$.pipe(throttleTime(200)); // перше значення одразу, далі не частіше ніж раз на 200 мс
scroll$.pipe(auditTime(200)); // навпаки: останнє значення в кінці кожного інтервалу
Для скролу зазвичай беруть auditTime: важлива не позиція на початку руху,
а та, на якій зупинились.
delay — зсунути в часі
of(MOCK_TASKS).pipe(delay(400)); // імітація мережевої затримки
Це основа мок-шару з уроку 11: без затримки скелетони й індикатори завантаження просто не встигають зʼявитись, і перевірити їх неможливо.
timeout — не чекати вічно
this.api.getTasks().pipe(
timeout(5000),
catchError(err => {
this.error.set('Сервер не відповідає');
return EMPTY;
}),
);
distinctUntilChanged — не смикатись на однаковому
query$.pipe(
debounceTime(300),
distinctUntilChanged(), // набрав, стер, набрав те саме — запиту не буде
);
Порядок тут важливий: спершу debounceTime, потім
distinctUntilChanged. Навпаки теж працює, але тоді порівнюватимуться всі проміжні
значення, а не лише ті, що пройшли паузу.
startWith('') → debounceTime(300) →
distinctUntilChanged() → switchMap(запит).
Чотири оператори, які закривають одразу пʼять проблем: порожній екран на старті,
запит на кожну літеру, повторні однакові запити, гонки відповідей і зайве навантаження
на сервер. Запамʼятай його — це найчастіший фрагмент RxJS у продакшн-коді.