RFC: Queueing Improvements

[hmans]

Instead of explicitly invoking the queued versions of mutator functions, let's change the API to the following:

world.queue(() => {
  world.createEntity(...)
  world.addComponent(...)
  world.removeComponent(...)
  /* etc. */
})
/* The queue will be flushed at the end of the function. */

It's important to have this work in a nested fashion, so I think the logic should work something like this:

• World gains a new internal state 'queueLevel' that is 0 when no queue is active, and increased by world.queue(), and decreased when world.queue() finishes.
• The mutator functions check if queueLevel is greater than 0. If it is, the mutations will be queued.
• When world.queue() exits and the queueLevel is back to 0, the queue is actually flushed.

Problems with this:

• The new mutator functions could be a little hard to type (since the synchronous version of createEntity would return an entity, but the queued version could not return anything), especially since it's not clear at the time of invocation if the requests are currently being queued or not.

[mikecann]

Seems like a good idea to me!

[hamzakubba]

I like the current API, I feel like maybe this can be added instead of replacing the current API? Also, how about:

world.queue.preFlush(() => { /* ... */ })
world.queue.postFlush(() => { /* ... */ })

Or something along those lines?

[hmans]

2.0 will not have any built-in queuing functionality, so this is now obsolete. (Queuing will be handled out of band, through other libraries, and the documentation will provide examples.)