Matty F
Matty F

Reputation: 3783

Queueing events in the PubSub / Observer patterns

I've always found it easier to dive straight in to an example.

object.on('eventone', function() {
  console.log('eventone - listener one');
  object.trigger('eventtwo');
});
object.on('eventone', function() {
  console.log('eventone - listener two');
});
object.on('eventtwo', function() {
  console.log('eventtwo');
});
object.trigger('eventone');

In most PubSub implementations, this results in the following log order:

  1. eventone - listener one
  2. eventtwo
  3. eventone - listener two

In the past, this has presented issues with the semantics of this sequence. Often developers will assume that all listeners for 'eventone' have fired before 'eventtwo' has begun, which can introduce sequence logic bugs further on down the track. A more sensible log order would likely be:

  1. eventone - listener one
  2. eventone - listener two
  3. eventtwo

So I guess the question is - why do most implementations not follow event queuing? And what are some possible impacts of using it, versus not.

Cheers!

Upvotes: 1

Views: 586

Answers (1)

Paul Sweatte
Paul Sweatte

Reputation: 24617

Pubsub is intended to work such that one subscriber is not dependent, aware of, or impeded by the others. Here are a few questions which explore the pros and cons of each approach:

Upvotes: 1

Related Questions