Choo: discussion: cancellation of actions

[yoshuawuyts]

Right now actions cannot be cancelled - once called they're expected to either finish executing or return an error. Sometimes when one piece of a chain halts, there's no point in continuing the other, already started pieces. This is part of the design in pull-stream. At this point choo's actions have no concept of cancellation, so I'd like to start a bit of discussion about this:

• do we need a cancellation mechanism between actions?
• what are the use cases for cancellation?
• what prior art is there around this?
• (how) do the browser protocols handle cancellations (HTTP / WS / SSE / WebRTC)?

This is probably for more advanced use cases; but giving it some thought would definitely be worth it I reckon. Thanks!

[sotojuan]

IMO if anything needs cancellation it's effects as they are going to be typically used for async actions that devs may want to cancel for race condition or time out reasons.

Unfortunately the only prior art I am comfortable with is redux-saga which is a bit too different.

[yoshuawuyts]

Been thinking about this more - think that to support cancellation as a first class primitive we might need to use pull-stream as a primitive, being able to map the current V3 API onto it using #145. Damn it, I don't like breaking changes but this is something we're not accounting for that _is_ essential to fully supporting async - and I'm not seeing a different way of resolving this.

Interestingly enough it would also mean that we can support the choo v2 API through the same mechanism; perhaps unlocking different stages of composition in a learning curve hmmmm. Anyway this would be wayyy off still - there's more work to be done before we can hit this, and if we ever change the underlying mechanism we should make damn sure that existing code has a smooth can be ported over easy

[yoshuawuyts]

Ah right, from discussion on IRC with @toddself and @timwis we decided it's probs not wise to move to pull-stream because the default experience for choo would be... not great.

Instead what we might do is supporting cancellation in the existing API by (wait for it) adding _yet another callback_! :tada: - but this one would be totes optional, and we'd like never use it in any of the examples. It's only there so that if someone wants to upgrade to an async flow that supports cancellation it's possible. Wouldn't that be sweet? :grin:

So yeah, minor patch possible for this I reckon - keeps the upgrade flow nice and smooth :cool:

[yoshuawuyts]

I've been wondering about this a bit more lately. Do we truly need cancellation? Something we should ask ourselves is what use case it would support.

The way I'm viewing actions now is as immutable commands that either ACK or NACK - they're a bit expensive to send but that's cool. Because they're expensive to send, they shouldn't be used to stream data from. When streaming data it'd be recommended to buffer instead (even tiny buffers) rather than send a flood of actions. Because of this, it doesn't make sense to also have cancellation in there.

As a tl:dr; cancellation adds technical cost, can't really think of a scenario where I'd use it and send() is not great for streaming anyway

[yoshuawuyts]

Nah we shouldn't be able to cancel actions - closing!