Stream unsubscription interop

[dariomannu]

Describe the solution

Currently you can "unsubscribe" from a stream with subscription.cancel(), which is fine.

Most other reactive code around, designed for RxJS, still uses .unsubscribe(), though.
Other (minor) Observable implementations have subscribe as a function that returns an unsubscribe function subscribe = () => unsubscribe .
The WICG proposal went for the AbortController as the only way to cancel an Observable, to address the rare, but so called sync firehose issue

I know, not great having so many different interfaces for portability.

Is there any wish for Eventkit to become interoperable with any of these alternatives, by any chance?
The AbortController might be the nastiest one to integrate (IMO), but... if that's what the standards want to go for, it might be useful to consider... Also, creating a .unsubscribe() alias should be trivial, on the other hand, to help the transition?

[hntrl]

AbortController is interesting -- I don't know if it should be the exclusive controller for observables, but I could see a good story for it in eventkit since its pretty widely used in web APIs.

const stream = new Stream();
const controller = new AbortController();
const sub = stream.subscribe(console.log, { signal: controller.signal });

I don't think that will address the sync firehose issue though since that's just an unavoidable artifact of eventkit using the microtask queue instead of throwing events to subscribers on the main thread (there's some backpressure implications if we did impose some kind of mechanism there). Up until the point that the cancel signal is received, we'll create subscriber work since they arrive out of order asynchronously

[dariomannu]

The firehose issue should probably be (known, but) ignored. It's just a corner case that doesn't happen in real life more often than an infinite for(;;){}; loop, so I don't think we need a "fix" for either.

That said, I don't really like AbortController either, as you have to instantiate it, pass it to constructors, call it... but that's just my humble opinion. However, given it's so standard, it's worth being aware of it, at least, perhaps just consider supporting it.

One advantage of the AbortController is its ability to cancel multiple streams in one go, which actually makes it interesting for UI libraries, given the relevant support from the underlying streams infra.

The use case would be unmounting a whole subtree of components (like a view), and calling a single abort() on all reactive streams connected to it...

[hntrl]

yeah thats good too! I imagine if you wanted to "group and cancel" a bunch of observables, this is an alternate pattern of how to do that:

const stream = new Stream();

const group = stream.pipe();

const subA = group.subscribe();
const subB = group.subscribe();

// later
await group.cancel();

which would be analogous to somethign like:

const stream = new Stream();

const controller = new AbortController();
const subA = group.subscribe(..., { signal: controller.signal });
const subB = group.subscribe(..., { signal: controller.signal });

// later
controller.abort();

only thing we're missing out on is we're not waiting for cleanup work to be done when we call controller.abort()

[dariomannu]

only thing we're missing out on is we're not waiting for cleanup work to be done when we call controller.abort()

ok, so another one that may need some thought.
In the context of Rimmel it shouldn't matter most of the time: when you unmount a component, stuff gets unsubscribed. If you are still performing some async action, who am I to stop you? :)
So issues might happen, but in practice they don't really do.

Have you considered joining Hacktoberfest, which is starting right now? Might get either some contributions for basic tasks or a little bit of extra visibility

[hntrl]

If you are still performing some async action, who am I to stop you? :)

yeah this is a core tenant of eventkit -- we want to be highly consistent with the life cycle of promises (hence why we have Stream.drain(), etc.)

Have you considered joining Hacktoberfest,

good idea! Added the topic to the repo

[hntrl]

Regarding the original question -- I don't think that making members transferable between similar implementations is reason enough to influence the API design. Maybe this is a matter of opinion, but I want to think that .cancel is clearer than .unsubscribe with respect to what its actually doing.

[dariomannu]

Have you considered joining Hacktoberfest,

good idea! Added the topic to the repo

https://hacktoberfest.com/
And you may want to join the discord server to drop a link and a few notes there, too