RxJS Streams Are Inconsistently Asynchronous In Angular 2 Beta 6

If you move the .delay(10) to the getStreamA() in the first example, do you get the same console output? Line 59 instead of 67.

AFAIK you can configure this behaviour in RxJS using schedulers ( https://github.com/Reactive-Extensions/RxJS/blob/master/doc/api/schedulers/scheduler.md ).

@Simon,

Thanks, that's good to know.

@Ben,

If you change getStreamA() method to the following, then I'll behave just like a promise:

function getStreamA() {
return( Rx.Observable.of( "stream" ).observeOn(Rx.Scheduler.default) );
}

By default Rx.Scheduler.immediate is used which makes the observable to work immediately (i.e. synchronously) as far as I understand.

@Ben,

I think the big difference is that Promises only resolve once. So you don't have a big trade-off if they are asynchron. Observable streams, on the other hand, can emit multiple times. This means, if you have an array with 1000 entries and emit each value within an Observable stream it would take about 4 seconds to complete with the asynchron approach (assuming setTimeout(function() {}, 0) takes 4ms). Most likely that wouldn't be what the developer wants.

This comes up a lot. I think on the surface, it can feel strange that you aren't able to know whether an Observable is sync or not.

The Rx answer to that concern is generally, done properly, it shouldn't really matter. Using Observables you typically do everything "in band":

someObservable
.someOperator()
.someOperator()
.someOperator()
.subscribe(v => //do side effect);

In an angular2 app, you can take this even further - using the async pipe you need not subscribe at all, and the whole application's data flow happens "in band"

The other thing to mention is *generally* Observables will be async - Observables from arrays are typically not all that common (and generally better handled as vanilla arrays...)

@Ben,

I think which behavior you want really depends on what you are building with RxJS (which is the reason there are different Schedulers for different use-cases). Only the first emit async and the rest not may work in some cases but not in all. For example if you are writing an EventEmitter with RxJS it wouldn't feel right if only the first emit() call is async and rest ist not.

Yes, this behavior is by design.

> Very interesting stuff. I tried to look into Schedulers a little when I was seeing if I could get them to work with the .throw() streams - the method signature looks like it accepts a scheduler as an optional argument. But, honestly, it went way over my head :D I'll have to circle back, now that my mental model is a little bit stronger.

Here's the idea behind schedulers: say you're going to call a function, and that function does something asynchronously via `setTimeout`. How would you unit test that function (without overriding global `setTimeout`), or otherwise change the asynchronous behavior (for example, if you need to render synchronously on the server)? The easiest way is to change the function signature to accept a `setTimeout` implementation.

Schedulers are just a generic interface for running a callback at some point in the future, just like setTimeout. And the operators in Rx that have the option of doing something in the future typically accept a Scheduler, so you can control how and when that operator's future things run.

> That said, all of these approaches still rely on the implementation to be a "known quantity" - an agreed-upon contract, so to speak, between the code consuming the stream and the code producing the stream.

That's one approach, but a better approach is to not make assumptions about whether the Observable will emit synchronously or asynchronously. Rather than modifying outside state from within your Observable handlers, you should put all the logic that depends on an event *inside* the functions you pass to `flatMap`, `subscribe,` etc. When you do that, it doesn't matter whether the Observable emits synchronously or asynchronously, your code is correct either way!

I would also encourage you to take a look at the decision trees for when you should use the various operators.

Operators for creating new Observables:
https://github.com/Reactive-Extensions/RxJS/blob/master/doc/gettingstarted/which-static.md

Operators for working with an existing Observable:
https://github.com/Reactive-Extensions/RxJS/blob/master/doc/gettingstarted/which-instance.md

For example, if you want to ensure your Observable dispatches asynchronously, that's just an operator away:

```
var Rx = require("rxjs");
var Observable = Rx.Observable;
var Scheduler = Rx.Scheduler;

Observable.of("a", "b", "c")
.observeOn(Scheduler.async)
.subscribe((val) => console.log(`observable ${val}`));

console.log('hey, this prints first!);

```

Interesting. True that promises have easily predictable interface; but in some situations it is actually a limitation.

With Rx approach there is **much more** flexibility, which imho is a good thing. It is not only sync vs async, but as well built-in cancellation mechanism, dealing with multiple values and a bunch of really nice operators.

The ultimate beauty and power of RxJS is when you start designing the whole logic / data-flows around it.

The only benefits of promises over observables I can think of are:
1. they are native objects (observables should follow shortly)
2. the learning effort is lower