Closed Totenfluch closed 4 years ago
Generally, it's an anti-pattern to leak the resolve
and reject
methods outside the Promise constructor. How about we allow .enqueue()
to be async and await it instead?
@sindresorhus Thanks for you reply I don't think this would work. The idea of using the resolve as a parameter is that multiple requests can be resolve in a single method. AFAIK there is no way to "re-point" a promise to a result function other than calling resolve manually from the merged function.
If we use async for enqueue it creates another promise which does not help in this case because the actualy promise needed to make this work is only available as return from the add function, as this is the actual return of the queue and enqueue is merely a dummy
Do you have any other ideas how to make this work?
But even as it is I don't see an issue with going off pattern here because it is in the core code and is not exposed to users
this allows for more customized queue types such as a aggregation queue
Aggregation queues work this way:
with the constraint that 2+ single operations can be combined to do the same thing as a multi-operation. And the constraint that a single operation can be combined again with a multi operation.
Demonstrated here on the example of a mocked bitcoin transaction https://github.com/Totenfluch/p-aggregation-queue/blob/master/index.js
Once I get the merge operations standardised, I will create a pull request for this queue type writte in typescript like the priorityqueue you have in your package
As it is just an additional parameter, nothing should break with this pull request