Consider .next as an alias to .push

[dariomannu]

Describe the solution

Pushing a stream with .push() is great, but... many others like RxJS and the Observable web standards proposal use .next().

Fine if you wish to keep .push, but would you consider aliasing it to .next(), as well, to help migrating any code that's been created for RxJS first?

[hntrl]

I'm partial to not adding a bunch of aliases on core primitives just for transferability sake. Having class members that do the same thing seems redundant and adds bloat for not a lot of benefit.

That being said, I'm not opposed to something like a asNativeObservable utility that returns something that looks closer to the household observable interfaces if you think this is super important (I'm still not convinced it is). wdyt?

[dariomannu]

Pros and cons I see:

With native Observables you could seamlessly feed an Eventkit Stream straight from the DOM:

const s = new Stream;
document.when('click').subscribe(s);

Without that, you’d keep wrapping:

const s = new Stream;
document.when('click').subscribe(s.asNativeObservable());

No big deal if you do it once, manually, and if you only use Eventkit standalone, but in a medium-sized app with 30 components and 50 streams, that’s 50 extra .asNativeObservable() calls.

With Rimmel I'm thinking whether/how could we have an integration that just feels natural to developers, where Eventkit Streams "just work" in any UI component/template and are treated as first-class citizens, just like Observables and Promises.

For developers who are already familiar with Observables and are trying Eventkit, they could jump straight into the interesting and more unique features Eventkit can offer, like the generator/iterator aspects, etc, rather than fixing .next/.error/.complete integrations.

Angular taught us how messy constant conversion gets between Observables and Signals, and back.

On the other hand, if you have many users already accustomed to .push() and large codebases that depend on it they might not want to switch anymore, which would be totally understandable, as well.

Actually I do like .push() better than .next(). In fact the latter is quite confusing and unfortunate, since it already means pull from Generators/Iterables, vs push into Observers... but go tell the standards committees...

I think I'll create a hybrid Stream-Observable in the meantime to make examples and experiments work and look nice... perhaps other/better options may come to mind

[hntrl]

There's an avenue where AsyncObservable implements Symbol.observable, which if that's the way the proposal is going would mean that AsyncObservable to boot is compatible with observable APIs. Only thing I'm concerned about is that because AsyncObservable is endemically different from standard Observables (async by nature) that it will have weird compatibility issues

[dariomannu]

That's a valid concern when looking for compatibility, so you may want to consider this aspect carefully.

Anyway, when using these streams "properly", which means if all coordination is done with the correct operators (e.g.: zip, combineLatest, takeUntil, etc), no shared state or global/closure variables are referenced directly, no reliance on stream emission patterns, no imperative escape hatches are used/abused, it shouldn't really matter whether streams are sync or async.

What you might have is new glitches introduced or old, existing ones fixed.
This happens if the application has improperly reconnected diamonds (so it's prone to glitching), because the data propagation across those would change.

If we read and apply all effects at the same time at the end of a tick, we may eliminate glitches. This is something a framework or UI library should do for the application.