reduce the complexity of the return type and make it more expressive
give the caller a way to know with how many stages he will be working with (if possible)
This would result in the following:
async leave(): AsyncIterator<SomeType> {
or similar.
For this we could probably use the default interface of an AsyncIterator and extend it slightly with an optional length?: number value. it.length would then, if not undefined, allow a developer to display a proper progressbar in a frontend application, while the fact that an Iterator is returned perfectly conveys the fact, that multiple transactions are being awaited.
The intricacies of the implementation, whether the Stages helper is really necessary or just has to implement the AsyncIterator interface is up for the implementer to research and decide.
We currently have abominations like the following in our API:
It would be very convenient to:
This would result in the following:
or similar.
For this we could probably use the default interface of an
AsyncIterator
and extend it slightly with an optionallength?: number
value.it.length
would then, if notundefined
, allow a developer to display a proper progressbar in a frontend application, while the fact that anIterator
is returned perfectly conveys the fact, that multiple transactions are beingawait
ed.The intricacies of the implementation, whether the
Stages
helper is really necessary or just has to implement theAsyncIterator
interface is up for the implementer to research and decide.