Discussing the future of schedulers

[benlesh]

Schedulers exist so we can exercise more control over when subscription occurs and when values are observed. They also provide a mechanism we can hook to get more deterministic tests that run very fast.

A few issues with the current Scheduler set up

1. It's hard to build a test suite for people.

• do we need a global default scheduler? Should we just pass one around?
• if an operator defaults to a particular scheduler, do we patch it to make it use a test scheduler during test scenarios?

2. It's a large and complicated part of the library
3. It's a little-understood part of the library
4. Scheduler arguments aren't symmetric with proposed Observable APIs, like Observable.of
5. Still doesn't make it much easier to test things like animationFrame or the like.
6. When a scheduler is needed, it must be passed around and provided to every Observable creation call and time-related operator.

Questions

• In practice, is it better to have an Observable.of(1, 2, 3, async) or Observable.asyncOf(1, 2, 3)? Observable.of(1, 2, 3, asap) or Observable.microtaskOf(1, 2, 3) (name totally bike-sheddable)
• Could we potentially just use setTimeout or Promise then, and patch them temporarily at test time? It seems like that might make it easier to build test suites. It might also reduce the size of the library.
• How much do people really find the need to use Schedulers? How valuable are they if we found another way to deterministically test Observables?
• Would scaling them back a great deal reduce the size of the library significantly?

Other things

Having schedulers might enable us to centralize error handling in the next version, which could help performance and reduce library size. This was one of the central changes in "T-Rex".

NOTE: This is just a discussion to get us to question what we've been doing with schedulers, not a change suggestion per say

[staltz]

For a slightly different perspective on testing, I invite you to take a look at cycle/time, a tool that @Widdershin built inspired by the RxJS TestScheduler: https://github.com/cyclejs/cyclejs/tree/master/time#rxjs-why-would-i-want-to-use-cycletime-over-the-testscheduler-from-rxjs

The difference there is that the time-related operator, like delay, is passed as an input, as opposed to the scheduler passed as an input and used in the time-related operator.

Globals are tempting, but they are magic and sources of confusion. In Cycle.js we barely have any globals, but the ones we do have, such as the innocently small setAdapt, are constantly a source of discussion/annoyance.

I think the story around schedulers isn't entirely about testing, though. Issues like this combineLatest quirk are real gotchas for beginners and still a source of pain when migrating from RxJS v4 to v5+.

[benlesh]

I think the gotcha for beginners in the case outlined is really around not understanding that Observable.of is a synchronous loop that emits values.

Another thing to think about is the fact that our Observable.of and Observable.from are not really compatible with the current TC39 proposal. It would be nice to bring that in line.

In practice, I really do think it's worth taking a step back and asking what the schedulers really provide.

Globals are tempting, but they are magic and sources of confusion.

As for this, right now all of our provided scheduler instances are essentially global. They are a single, shared, stateful instance at a top level. They might not live in window or global but they are nonetheless accessible from almost anywhere and contain some shared state.

I think the larger problems are:

1. They're rarely needed
2. When one is needed, you have to pass it all over the place to every Observable creation method and timing operator.
3. In most cases, a separate Observable creation method could be provided that would eliminate the need for a scheduler argument.
4. I'm unsure it's good practice to have a method where one argument completely changes the behavior of the resulting type. Observable.of(1) vs Observable.of(1, async). For one thing, it complicates the method, for another thing, it means results are unpredictable for Observable.of(x, y) where you don't know what y is. (Yay dynamic languages).

[staltz]

In practice, I really do think it's worth taking a step back and asking what the schedulers really provide.

Simply put, schedulers solve concurrency ambiguities in a declarative style. The real problem of that Observable.of example is not its synchronicity, but the fact that combineLatest is sensitive to the ordering of input Observables: combineLatest(a$, b$) or combineLatest(b$, a$).

Although Schedulers were originally introduced to Rx(.NET) and heavily important for thread management, concurrency also exists in "single-threaded" JavaScript. Besides the simple Observable.of examples, concurrency problems with reactive streams occur in less obvious cases. For instance, race conditions that we found in Cycle.js. These conditions emerge easily once you have a multicasted observable and you need multiple observers subscribed and not have them compete in a race.

A simple statement of the important problem that schedulers solve: "how can we subscribe to both a$ and b$ simultaneously?". You cannot reliably provide an answer to this if the only thing that exists is the recursive scheduler. Schedulers allow you to describe what does "simultaneously" mean case by case.

I understand that testing is clumsy, we can explore our options for that. I understand that we could simplify the codebase by deleting some parts. But let's not reinvent the wheel or throw away an important part of RxJS, which also makes it uniquely interesting over alternatives like Most.js, xstream or Bacon.js.

As a secondary note, I much prefer Observable.asyncOf(1, 2, 3) over Observable.of(1, 2, 3, scheduler).

[benlesh]

Simply put, schedulers solve concurrency ambiguities in a declarative style.

There is very little that is declarative about how Rx is using schedulers. It's pretty imperative... callThis(arguments, here, btw, scheduler). You can't move the scheduler around to change the behavior, it's a pretty specific instruction to the method you're calling. "create this observable, have it use this scheduler".

A more declarative solution would be specialized operators similar to subscribeOn or observeOn...

source$.async()

// or 

source$.queue()

This would mean your combineLatest problem would be solved like a$.queue().combineLatest(b$.queue(), (a, b) => a + b). So that on the rare and strange occasion you're dealing with all synchronous observables that you want to deal with in a breadth-first manner, you can do so.

concurrency also exists in "single-threaded" JavaScript.

This is the entire basis of Rx. So I know this.

Currently dealing with scheduler defaults in operators is a huge problem when trying to create a test suite. If you're trying to test code that is using .delay() or the like, or is even creating Observables with something like interval or even range internally, and doesn't allow you to pass a scheduler around to everything, the test suite is screwed. That's not a big win.

Scheduling seems to be something that was designed to accommodate 100% of the use cases 100% of the time, but in practice some of what it accommodates doesn't make sense. "I want immediate scheduling on a$, but animationFrame scheduling on b$ and the delay operation I'd like to be scheduled virtually". I mean, it could happen... but is it worth the additional download size and code complexity? That's the real question I'm asking.

an important part of RxJS, which also makes it uniquely interesting over alternatives like Most.js, xstream or Bacon.js.

It also makes it uniquely heavier than any of those mentioned.

So maybe better questions are:

1. How much do schedulers and supporting schedulers cost in terms of size and performance?
2. Do they live up to their value proposition in JavaScript-land given the cost of 1 above?

I suspect that some members of our core team has a very skewed point of view compared to the to outside developers who have started using RxJS in droves over the last year. The MO for most of us, myself included, has been resistance to change and reluctance to explore alternatives.

[benlesh]

If we could simplify the library, make it smaller and faster, and have deterministic tests and still support composition of different scheduling behaviors, is that something worth exploring?

[benlesh]

ALSO: I'm playing devil's advocate this is exploratory, I'm taking the "what if" stance to contrast other opinions and keep people thinking.

Just to be clear.. I'm not arguing with @staltz ... just want to get people thinking.

[benlesh]

So one common use case for me and schedulers is for animations like:

Observable.interval(0, animationFrame)

// or

Observable.range(0, Number.POSITIVE_INFINITY, animationFrame)

// or

Observable.timer(0, 0, animationFrame)

But I wonder if it would be better/more efficient/easier to understand/etc to just have:

Observable.animationFrames(); 

[kwonoj]

subscribeOn / observeOn is not available usecase in here?

[staltz]

I still maintain my previous arguments, but after having thought about this for some hours I realized it's enough (for the JavaScript Rx) to be able to specify breadth-first ordering or depth-first ordering. I don't see the benefit of multiple Schedulers that accomplish breadth-first, we could have just one breadth-first Scheduler. So there's some opportunity for code deletion somewhere.

[staltz]

I noticed yet another cool and unexplored benefit of a breadth-first scheduler: avoiding ReplaySubject or BehaviorSubject when subscribing to a multicasted observable.

Note

const a$ = Rx.Observable.interval(1000).startWith(-1)
  .publishReplay(1).refCount();

a$.subscribe(x => console.log(x));
a$.subscribe(x => console.log(x));

versus

const a$ = Rx.Observable.interval(1000).startWith(-1)
  .observeOn(Rx.Scheduler.asap)
  .publish().refCount();

a$.subscribe(x => console.log(x));
a$.subscribe(x => console.log(x));

[trxcllnt]

@benlesh I'm still in favor of an option to specify the scheduler at subscription time, which would compose all the way through the operator subscriptions and could be used in place of operator defaults, e.g. subscribe(observer, scheduler). Tests would then just need to pass the TestScheduler as the second argument when they subscribe.

[staltz]

Great idea, Paul. Are there any obstacles for doing that? And I suppose observeOn would interrupt that bottom-up propagation.

Since the recursive scheduler is basically "no scheduler", how would the default case work, given subscribe(observer) and supposing we have a delay(1000) upstream? Would the delay just default to asap like it does today?