1 line
3.6 KiB
Plaintext
1 line
3.6 KiB
Plaintext
|
{"version":3,"file":"observeOn.js","sourceRoot":"","sources":["../../src/operator/observeOn.ts"],"names":[],"mappings":";AAEA,0BAAyC,wBAAwB,CAAC,CAAA;AAElE;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;GA6CG;AACH,mBAAkD,SAAqB,EAAE,KAAiB;IAAjB,qBAAiB,GAAjB,SAAiB;IACxF,MAAM,CAAC,qBAAW,CAAC,SAAS,EAAE,KAAK,CAAC,CAAC,IAAI,CAAkB,CAAC;AAC9D,CAAC;AAFe,iBAAS,YAExB,CAAA","sourcesContent":["import { Observable } from '../Observable';\nimport { IScheduler } from '../Scheduler';\nimport { observeOn as higherOrder } from '../operators/observeOn';\n\n/**\n *\n * Re-emits all notifications from source Observable with specified scheduler.\n *\n * <span class=\"informal\">Ensure a specific scheduler is used, from outside of an Observable.</span>\n *\n * `observeOn` is an operator that accepts a scheduler as a first parameter, which will be used to reschedule\n * notifications emitted by the source Observable. It might be useful, if you do not have control over\n * internal scheduler of a given Observable, but want to control when its values are emitted nevertheless.\n *\n * Returned Observable emits the same notifications (nexted values, complete and error events) as the source Observable,\n * but rescheduled with provided scheduler. Note that this doesn't mean that source Observables internal\n * scheduler will be replaced in any way. Original scheduler still will be used, but when the source Observable emits\n * notification, it will be immediately scheduled again - this time with scheduler passed to `observeOn`.\n * An anti-pattern would be calling `observeOn` on Observable that emits lots of values synchronously, to split\n * that emissions into asynchronous chunks. For this to happen, scheduler would have to be passed into the source\n * Observable directly (usually into the operator that creates it). `observeOn` simply delays notifications a\n * little bit more, to ensure that they are emitted at expected moments.\n *\n * As a matter of fact, `observeOn` accepts second parameter, which specifies in milliseconds with what delay notifications\n * will be emitted. The main difference between {@link delay} operator and `observeOn` is that `observeOn`\n * will delay all notifications - including error notifications - while `delay` will pass through error\n * from source Observable immediately when it is emitted. In general it is highly recommended to use `delay` operator\n * for any kind of delaying of values in the stream, while using `observeOn` to specify which scheduler should be used\n * for notification emissions in general.\n *\n * @example <caption>Ensure values in subscribe are called just before browser repaint.</caption>\n * const intervals = Rx.Observable.interval(10); // Intervals are scheduled\n * // with async scheduler by default...\n *\n * intervals\n * .observeOn(Rx.Scheduler.animationFrame) // ...but we will observe on animationFrame\n * .subscribe(val => { // scheduler to ensure smooth animation.\n * someDiv.style.height = val + 'px';\n * });\n *\n * @see {@link delay}\n *\n * @param {IScheduler} scheduler Scheduler that will be used to reschedule notifications from source Observable.\n * @param {number} [delay] Number of milliseconds that states with what delay every notification should be rescheduled.\n * @return {Observable<T>} Observable that emits the same notifications as the source Observable,\n * but with provided scheduler.\n *\n * @method observeOn\n * @owner Observable\n */\nexport function observeOn<T>(this: Observable<T>, scheduler: IScheduler, delay: number = 0): Observable<T> {\n return higherOrder(scheduler, delay)(this) as Observable<T>;\n}\n"]}
|