Comments (6)
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 ::)
from proposal-observable.
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.
from proposal-observable.
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.
from proposal-observable.
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 :)
from proposal-observable.
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.
from proposal-observable.
Closing in favor of discussion on #38
from proposal-observable.
Related Issues (20)
- Invalid test based on Interface. HOT 1
- `obs.subscribe(next, error, complete)` should bind their callbacks to `undefined` when present HOT 5
- Why does `Observable.prototype.subscribe` report thrown errors from `observer.start(sub)` asynchronously instead of just propagating them?
- Minor spec bug WRT cleanup in `subscribe`
- `Observable.from` iteration functions incorrectly assume their observer parameter is native HOT 1
- [ALTERNATIVE] Proposal for an alternative
- Cleanup function should be passed to the SubscriptionObserver
- Simplification of Observable API HOT 69
- End a subscription if a completion token is returned HOT 1
- Even simpler API HOT 4
- Reduced API with async/await support HOT 23
- Observable should be async HOT 5
- Syntax Support HOT 4
- Alternative: Pub/Sub
- Moving to an API with AbortSignal HOT 9
- Retain core API and leave operators to user-land libraries HOT 15
- Permit unsubscribe to return a promise HOT 3
- Is there any update? HOT 34
- Support [Symbol.dispose]() for unsubscribe() HOT 1
- Unsubscribe
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from proposal-observable.