workq icon indicating copy to clipboard operation
workq copied to clipboard

inherit properties from prototype, add tests

Open StarpTech opened this issue 8 years ago • 8 comments

I need this feature because I don't want to define a onDrain handler on any new queue. This PR can simplify it to listen to "end" events with a single handler.

StarpTech avatar Nov 18 '17 17:11 StarpTech

~~We could also enable it only with an option.~~

StarpTech avatar Nov 18 '17 17:11 StarpTech

Feature is disabled by default and can be enabled by

const q = Queue({ shareDrainHandler: true })

StarpTech avatar Nov 18 '17 18:11 StarpTech

This could be solved by exposing the id property.

StarpTech avatar Nov 20 '17 10:11 StarpTech

That's true, but the queue id is something internal used just for debugging, it does not tell anything to the developer.

What is the use case that needs a shared drain handler?

delvedor avatar Nov 20 '17 10:11 delvedor

Imagine you have lots of nested queues and you don't want to manage the drain event for each queue it would be great to have a single place to observe when a queue is empty.

StarpTech avatar Nov 20 '17 11:11 StarpTech

I'm still not convinced :P Without a way to identificate the queue have a shared drain handler is useless. Expose the internal id is useless as well, because it has no meaning for the developer and since is an incremental id you can't even write a easy logic to handle it.

Another option could be add an event emitter for the 'drain' event, in this way you will have the .drain api for the specific queue and a generic drain event (but you will not know which queue has fired it for the same reason as above).

The unique way to fix the "not know which queue has just ended" is to add the possibility to customize the id. In the same way that we did in Fastify.

So the api will be something like:

const q = workq({ genId })

q.add(...)

q.on('drain', id => {
 // event emitter are detached from the context so no done callback
})

function genId () {
  var id = 0
  return function () {
    return id++
  }
}

What do you think?

delvedor avatar Nov 20 '17 12:11 delvedor

@delvedor I like it 👍

StarpTech avatar Nov 20 '17 13:11 StarpTech

What do you think about to add another hook and use the id strategy from above? I think we dont need an event emitter.

q.drainEach(id => {})

StarpTech avatar Nov 20 '17 13:11 StarpTech