Automagic Event Registration

Further to last night’s post on custom events, I’ve set things up now to use “magic event registration”. It’s a little like the auto-wiring facility of a dependency injection container. It’s quite simple really – the app’s initialisation sequence does this:

  • Register all components that might listen to something.
  • Register all events they might listen to.
  • For each listener method among the components, automatically bind the event to it.

In code:


  1. var components = [siteFrame, singleTrial, trialController, statsZone, tableView, analysis, rawView, graphView];
  2.   var eventTypes = ["trialCreate", "trialUpdate", "trialSuspend", "trialRun", "trialComplete"];
  3.   $.each(components, function(i,component) {
  4.     $.each(eventTypes, function(i,eventType) {
  5.       var handler = component[eventType];
  6.       if (handler) $(document).bind(eventType, handler);
  7.     });
  8.   })

A component looks like:


  1. statsZone = {
  2.   trialCreate: function(e, trial) {
  3.     ...
  4.   },
  5.   trialUpdate: function(e, trial) {
  6.     ...
  7.   }
  8. }

And elsewhere in the code, the events it listens to get triggered through the normal jQuery custom events mechanism:


  1. $(document).trigger("trialUpdate", trial);

Part of this is based on what I said last night, which is (a) I’m keeping things simple – hence everything happens at startup and all the instances are singleton classes; (b) consequently, events are global, rather than being attached to any particular component.

Stepping back, what were the alternatives to this design:

  • Components register themselves as listeners – this would be the purist OO answer, i.e. keeping objects autonomous. A perfectly cromulent solution, but a little more redundancy than it needs to be. If objects really do have consistently named listener methods, it’s just as easy to handle registration automagically.

  • The initialisation routine manually wires up components to events. It has a certain Python-like “explicit” feel to it, but again is quite pointless if we can instead do it automagically.

So where does the automagic model fall down? If we are doing things dynamically, it would get more complicated and would, for example, require objects to register upon their creation. So I think that’s still okay. Another problem could be if a single method was listening to more than one event type, since this technique assumes it’s one-to-one from event type to methods. But that’s okay too – I actually had this problem and it was simply solved by getting both handlers to delegate to a third, common, handler:


  1. var trialController = {
  2.   trialCompleteOrCreate: function() {
  3.     ...
  4.   }
  5. }
  6. trialController.trialCreate = trialController.trialComplete = trialController.trialCompleteOrCreate;

I realised while working on TiddlySpace there’s a lot to be said for dependency injection style patterns in Javascript, and it’s not happening yet.

7 thoughts on Automagic Event Registration

  1. I like this a lot, but I think that the big thing is not whether or not things get auto-wired. but that they get wired at all.

    Several frameworks have message buses for efficient pubsub message passing, but so far no one have (AFAIK) implemented the kind of wiring that JDA (nowadays called contructibles had.

    The main idea was to have a simple way to expose widget interfaces to each other, and to register connections. Like a über-simple programmatic BPEL in the browser, just like you have started to to here.

    Cheers, PS

  2. Cheers for the link Peter.

    “”” I like this a lot, but I think that the big thing is not whether or not things get auto-wired. but that they get wired at all. “””

    Good point – I think what you’re getting at is that everything happens dynamically. So when a “trialUpdate” is triggered, the framework dynamically searches through for all components that can deal with it.

  3. Pingback: A jQuery Inheritance Experiment

  4. Pingback: Welches Framework? -

  5. I would just use a library like Ember or React now. They have carried forward the same spirit and will provide much better support than rolling your own.

  6. Pingback: Patterns For Large-Scale JavaScript Application Architecture | Mohamed Sharaf

Leave a Reply to Peter Svensson Cancel reply