Idea for sync subscription api

[tgriesser]

Creating a separate ticket for discussion from #25, as the ticket was originally about the naming of Symbol.observer but shifted to discussion of the pros/cons of providing both sync/async subscription apis.

The only question is whether subscription is always async, or if we additionally provide a back-door way to synchronously subscribe.

I agree that there is confusion in presenting multiple entry points for creating a subscription, but a fully async api seems to potentially limit any observable use cases where sync may be desired / beneficial.

What if the subscription object returned from subscribe containing two methods: unsubscribe and connect

var subscription = observable.subscribe(generator)
subscription.connect()

The connect would allow for the subscription consumer to signal to the observable it is ready to receive values (synchronously or otherwise). Calls to connect after subscription or unsubscription have taken place would have no effect.

This would maintain a unified subscribe api, give the consumer more control over both the subscription and the unsubscription behavior (defaulting to the potentially less confusing), and if connect is not called the default behavior would be as currently defined - the scheduledSubscription would take place as it is enqueue'd normally.

[benjamingr]

Nice to e-see you here!

Quoting some of my comments from earlier about sync subscription:

An important thing to realize is that the overhead for an async function call is the same if you have 10000 calls or 1 call since it groups all the calls and executes them synchronously after a single timer.

In addition, implementations can detect that the subscriber fired the event asynchronously (since they know before and after the observer function ran) (that is - post subscribe) and avoid the async overhead altogether and execute it synchronously (while still keeping async semantics).

Also +1 for "I don't think performance arguments without data hold any value"

And later:

Of course, the thing is like @domenic said is that the penalty for scheduling a function asynchronously happens once and can be avoided in practice in most cases. For example, in a chain of mapd observers you only need to perform the async deferral once - and even that's only true if you're only just setting the handlers up once you know you're in a future turn than the one you installed the handlers in you can invoke them synchronously.

This is a very simple optimization that some promise libraries do - basically you get async subscription semantics visibly but in practice your'e doing sync function dispatch most of the time.

I'm also with @zenpraing in that I'm not sure I understand your sync use case but would like to learn more about it ::)

[benjamingr]

The connect would allow for the subscription consumer to signal to the observable it is ready to receive values (synchronously or otherwise). Calls to connect after subscription or unsubscription have taken place would have no effect.

This would cause Zalgo, we might as well make it synchronous. Namely it is possible in this scheme to observe whether or not the a subscription happened before or after a value was received.

[tgriesser]

Nice to e-see you here!

You as well!

Also +1 for "I don't think performance arguments without data hold any value"

Yep, this is not as much of a performance argument as a more inclusive general use cases argument.

we might as well make it synchronous.

Well, not exactly, if it were fully synchronous you couldn't do this:

var subscription = observable.subscribe(generator)
subscription.unsubscribe()

And be guaranteed that the unsubscribe could be called before the first value is sent. Unless I misunderstand what you mean there

This would cause Zalgo

As I understand it Zalgo matters for promises because they're an object which is passed around/chained, so the async guarantees of the promise matter far beyond the initial call site.

Unlike promises, the effects of Observables are more or less limited to the containing scope(s), so it seems it'd be appropriate the consumer be able to shortcut the async guarantee as they are aware of the behavior of the observable, basically inverting the control of the guarantee of subscription execution a bit.

[benjamingr]

Unlike promises, the effects of Observables are more or less limited to the containing scope(s), so it seems it'd be appropriate the consumer be able to shortcut the async guarantee as they are aware of the behavior of the observable, basically inverting the control of the guarantee of subscription execution a bit.

That has not been my experience with observables - in libraries like RxJS (which I often use with React) observables are passed all around, chained, and moved between scopes.

Being able to shortcut a guarantee - especially if the guarantee is not the obvious default doesn't sound like much of a guarantee at all. With a symbol it at least looks private :)

[tgriesser]

That has not been my experience with observables - in libraries like RxJS (which I often use with React) observables are passed all around, chained, and moved between scopes.

Sure, probably the case for the higher order functions wrapping the observable primitive, but FWIW the RxJS Observable does not make any guarantees of asynchrony in the subscription.

Also, potentially relevant: ReactiveX/rxjs#12 (comment)

Anyway, yeah maybe the Symbol works as long as it's sticking around, just wanted to throw out another idea for this and see what anyone thought.

[tgriesser]

Closing in favor of discussion on #38