Understanding asynquence begins with understanding a
fundamental abstraction: any series of steps for a task,
whether they separately are synchronous or asynchronous,
can be collectively thought of as a "sequence".
In other words,
a sequence is a container that represents a task,
and is comprised of individual (potentially async) steps to complete that task.
Each step in the sequence is controlled under the covers by a Promise (see Chapter 3).
That is,
every step you add to a sequence implicitly creates a
Promise that is wired to the previous end of the sequence.
Because of the semantics of Promises,
every single step advancement in a sequence is asynchronous,
even if you synchronously complete the step.
Moreover,
a sequence will always proceed linearly from step to step,
meaning that step 2 always comes after step 1 finishes,
and so on.
Of course,
a new sequence can be forked off an existing sequence,
meaning the fork only occurs once the main sequence reaches that point in the flow.
Sequences can also be combined in various ways,
including having one sequence subsumed by another sequence at a particular point in the flow.
A sequence is kind of like a Promise chain.
However,
with Promise chains,
there is no "handle" to grab that references the entire chain.
Whichever Promise you have a reference to only represents
the current step in the chain plus any other steps hanging off it.
Essentially,
you cannot hold a reference to a Promise chain unless
you hold a reference to the first Promise in the chain.
There are many cases where it turns out to be quite useful to
have a handle that references the entire sequence collectively.
The most important of those cases is with sequence abort/cancel.
As we covered extensively in Chapter 3,
Promises themselves should never be able to be canceled,
as this violates a fundamental design imperative: external immutability.
But sequences have no such immutability design principle,
mostly because sequences are not passed around as
future-value containers that need immutable value semantics.
So sequences are the proper level of abstraction to handle abort/cancel behavior.
asynquence sequences can be abort()ed at any time,
and the sequence will stop at that point and not go for any reason.
There's plenty more reasons to prefer a sequence abstraction on top of Promise chains,
for flow control purposes.
First,
Promise chaining is a rather manual process --
one that can get pretty tedious once you start creating and
chaining Promises across a wide swath of your programs --
and this tedium can act counterproductively to dissuade the
developer from using Promises in places where they are quite appropriate.
Abstractions are meant to reduce boilerplate and tedium,
so the sequence abstraction is a good solution to this problem.
With Promises,
your focus is on the individual step,
and there's little assumption that you will keep the chain going.
With sequences,
the opposite approach is taken,
assuming the sequence will keep having more steps added indefinitely.
This abstraction complexity reduction is especially powerful when you start thinking about
higher-order Promise patterns (beyond race([..]) and all([..]).
For example,
in the middle of a sequence,
you may want to express a step that is conceptually like a try..catch in that
the step will always result in success,
either the intended main success resolution or a positive nonerror signal for the caught error.
Or,
you might want to express a step that is like a retry/until loop,
where it keeps trying the same step over and over until success occurs.
These sorts of abstractions are quite nontrivial to express using only Promise primitives,
and doing so in the middle of an existing Promise chain is not pretty.
But if you abstract your thinking to a sequence,
and consider a step as a wrapper around a Promise,
that step wrapper can hide such details,
freeing you to think about the flow control in the most sensible way
without being bothered by the details.
Second,
and perhaps more importantly,
thinking of async flow control in terms of steps in a sequence allows you to
abstract out the details of what types of asynchronicity are involved with each individual step.
Under the covers,
a Promise will always control the step,
but above the covers,
that step can look either like a continuation callback (the simple default),
or like a real Promise,
or as a run-to-completion generator,
or ...
Hopefully,
you get the picture.
Third,
sequences can more easily be twisted to adapt to different modes of thinking,
such as event-,
stream-,
or reactive-based coding.
asynquence provides a pattern I call "reactive sequences"
(which we'll cover later) as a variation on the
"reactive observable" ideas in RxJS ("Reactive Extensions"),
that lets a repeatable event fire off a new sequence instance each time.
Promises are one-shot-only,
so it's quite awkward to express repetitious asynchrony with Promises alone.
Another alternate mode of thinking inverts the
resolution/control capability in a pattern I call "iterable sequences".
Instead of each individual step internally controlling its own completion
(and thus advancement of the sequence),
the sequence is inverted so the advancement control is through an external iterator,
and each step in the iterable sequence just responds to the next(..) iterator control.
We'll explore all of these different variations as we go throughout the rest of this appendix,
so don't worry if we ran over those bits far too quickly just now.
The takeaway is that sequences are a more powerful and sensible abstraction for
complex asynchrony than just Promises (Promise chains) or just generators,
and asynquence is designed to express that abstraction with just the right level of sugar to
make async programming more understandable and more enjoyable.