Core Problem Statement
Processor functions that subscribe to events via a topic string may need to be prioritized for processing based on the topic itself. Conversely, certain events may be more numerous but should not limit the ability of the JS environment to respond and process other events, that may be more critical to either the User Experience (UX) or integrity of the system (e.g. events that trigger saving data to a back-end).
As Browser/CommonJS environments bring paradigms like UI event handling and back-end event handling into the same problem space, it is useful to apply common patterns used in Message-based Publish-Subscribe environments with message brokers, which is what the JS execution context often behaves as. The use case here is to ensure that one kind of event (e.g. event listeners for a ‘mouseMove’ event) don’t saturate or delay execution of other events (e.g. ‘dataAvailableForAutosave’) due to massive differences in event volume or conversely, expensive operations that block the execution thread in question.
Add metering options to the
addEventListener Options configuration object. These options control how the JS execution environment controls the throttling/firing of event handler instances in response to events that match the topic string of the subscription created by
maxInstances [Number / Function] used to decide how many event listeners can be invoked before throttling occurs. Throttling does not lose events but simply queues them.
throttlingQueueLength [Number] used to maintain an in-memory queue of un-processed events per Topic string, after throttling kicks in.
throttlingQueuePolicy [String] Values could be
exception - throws an exception when the queue length is exceeded,
rolling - drops the oldest events and pushes newer ones into the queue,
expand - allow the queue to expand to cover all events.
It might be even more useful if the options allowed targeting or creation of Web Workers (or Node child processes, depending on the execution context) based on the event handler configuration. This could potentially target CPU cores and/or O/S child processes / threads (depending on the O/S terminology for parallel execution).
The proposal below (link provided) should be part of the solution as it covers other metering options around debounce (which improves scale around event handling, which is in the same problem space) and handling throttling through frequency, which should be one of the alternatives in addition to my proposal above (they are orthogonal):