Rx schedulers provide an abstraction that allows you to schedule work, possibly in the future, without invoking code that needs to be aware of the mechanism used to schedule work.
Whenever the Rx method needs to generate a notification, it plans to work on the scheduler. By providing a scheduler to the Rx method instead of using the default, you can subtly control how these notifications are sent.
On Rx server implementations (such as Rx.NET), schedulers play an important role. They allow you to plan work with heavy loads in a thread pool or dedicated threads and run the final subscription to a user interface thread so that you can update your interface.
When using RxJs, it is actually quite rare to have to worry about the scheduler argument for most methods. Because JavaScript is essentially single-threaded, there are not many options for planning, and default schedulers are usually the right choice.
The only real choice:
immediateScheduler - Works synchronously and immediately. It looks like you are not using a scheduler at all. It is guaranteed that the planned work will be performed synchronously.currentThreadScheduler - Similar to immediateScheduler in that work is done immediately. However, it does not work recursively. So, if the work is done and more work is scheduled, then additional work is launched into the queue, which will be launched after the completion of the current work. Thus, work is sometimes performed synchronously, and sometimes asynchronously. This scheduler is useful to avoid or endless recursion. For example, Rx.Observable.of(42).repeat().subscribe() will result in infinite recursion if it is run in the immediate scheduler, but since return works on the currentThread scheduler by default, infinite recursion is excluded.timeoutScheduler is the only scheduler that supports scheduled work in the future. Essentially uses setTimeout to schedule all work (although if you plan on doing the job now, it uses other faster asynchronous methods to schedule work). Any work scheduled on this scheduler is guaranteed to be performed asynchronously.
Now there may be several more, for example, a scheduler planning to work with browser animation frames, etc.
If you are trying to write testable code, you almost always want to provide a scheduler argument. This is because in your unit tests you will create testScheduler instances that will allow your unit test to control the clock used by your Rx code (and thus control the exact time of operations).
Brandon Jan 27 '15 at 13:23 2015-01-27 13:23
source share