1 | import { asyncScheduler, Observable, ObservableInput, SchedulerLike } from 'rxjs';
|
2 | import { timeoutWith as higherOrder } from 'rxjs/operators';
|
3 |
|
4 | /* tslint:disable:max-line-length */
|
5 | export function timeoutWith<T>(this: Observable<T>, due: number | Date, withObservable: ObservableInput<T>, scheduler?: SchedulerLike): Observable<T>;
|
6 | export function timeoutWith<T, R>(this: Observable<T>, due: number | Date, withObservable: ObservableInput<R>, scheduler?: SchedulerLike): Observable<T | R>;
|
7 | /* tslint:enable:max-line-length */
|
8 |
|
9 | /**
|
10 | *
|
11 | * Errors if Observable does not emit a value in given time span, in case of which
|
12 | * subscribes to the second Observable.
|
13 | *
|
14 | * <span class="informal">It's a version of `timeout` operator that let's you specify fallback Observable.</span>
|
15 | *
|
16 | * <img src="./img/timeoutWith.png" width="100%">
|
17 | *
|
18 | * `timeoutWith` is a variation of `timeout` operator. It behaves exactly the same,
|
19 | * still accepting as a first argument either a number or a Date, which control - respectively -
|
20 | * when values of source Observable should be emitted or when it should complete.
|
21 | *
|
22 | * The only difference is that it accepts a second, required parameter. This parameter
|
23 | * should be an Observable which will be subscribed when source Observable fails any timeout check.
|
24 | * So whenever regular `timeout` would emit an error, `timeoutWith` will instead start re-emitting
|
25 | * values from second Observable. Note that this fallback Observable is not checked for timeouts
|
26 | * itself, so it can emit values and complete at arbitrary points in time. From the moment of a second
|
27 | * subscription, Observable returned from `timeoutWith` simply mirrors fallback stream. When that
|
28 | * stream completes, it completes as well.
|
29 | *
|
30 | * Scheduler, which in case of `timeout` is provided as as second argument, can be still provided
|
31 | * here - as a third, optional parameter. It still is used to schedule timeout checks and -
|
32 | * as a consequence - when second Observable will be subscribed, since subscription happens
|
33 | * immediately after failing check.
|
34 | *
|
35 | * @example <caption>Add fallback observable</caption>
|
36 | * const seconds = Rx.Observable.interval(1000);
|
37 | * const minutes = Rx.Observable.interval(60 * 1000);
|
38 | *
|
39 | * seconds.timeoutWith(900, minutes)
|
40 | * .subscribe(
|
41 | * value => console.log(value), // After 900ms, will start emitting `minutes`,
|
42 | * // since first value of `seconds` will not arrive fast enough.
|
43 | * err => console.log(err) // Would be called after 900ms in case of `timeout`,
|
44 | * // but here will never be called.
|
45 | * );
|
46 | *
|
47 | * @param {number|Date} due Number specifying period within which Observable must emit values
|
48 | * or Date specifying before when Observable should complete
|
49 | * @param {Observable<T>} withObservable Observable which will be subscribed if source fails timeout check.
|
50 | * @param {Scheduler} [scheduler] Scheduler controlling when timeout checks occur.
|
51 | * @return {Observable<T>} Observable that mirrors behaviour of source or, when timeout check fails, of an Observable
|
52 | * passed as a second parameter.
|
53 | * @method timeoutWith
|
54 | * @owner Observable
|
55 | */
|
56 | export function timeoutWith<T, R>(this: Observable<T>, due: number | Date,
|
57 | withObservable: ObservableInput<R>,
|
58 | scheduler: SchedulerLike = asyncScheduler): Observable<T | R> {
|
59 | return higherOrder<T, R>(due, withObservable, scheduler)(this as any);
|
60 | }
|