Sending messages between Javascript objects

Eneko Alonso — Fri, 24 Apr 2009 04:44:34 +0000

When applications (or websites) get pretty big, it usually happens that a lot of different objects or classes interact with each other or, even worst, depend on each other to achieve the site functionality.

A simple example could be a Tabs manager class, which controls a set of tabs in the page. Sometimes, the content in this tabs is sensitive to when the tabs are shown or hidden. At this point you have three options: either the Tabs class needs to know about the content or you create a set of callback functions or you use custom events. Still, for every one of these options you are going to need variables referencing the instances of your classes (this is: var myTabs = new Tabs())

Personally, I don’t like having global variables for the objects I create. I think the code gets very messy and complicated.

So, after dealing with all these issues at work day after day I thought it would be very cool to have a messaging system between my classes, the same way other languages like Cocoa do (in a more simpler way, at least for now).

Sending messages between classes

Wouldn’t it be nice if the Tabs class would send a message every time a new tab is selected? Wouldn’t it be nice if the objects that are going to reside inside those tabs could listen to that message and update accordingly?

To do this, I created a Base class and a Register, where my objects will register automatically upon instantiation (thanks to the Base class).

var InstanceRegister = new Class({
instances: [],
addInstance: function(object) {
this.instances.push(object);
},
broadcastMessage: function(msg) {
$A(this.instances).each(function(item, index) {
item.processMessage(msg);
});
}
});
var Register = new InstanceRegister();
var Base = new Class({
ClassName: 'Base',
Implements: Options,
initialize: function(options) {
this.setOptions(options);
Register.addInstance(this);
},
processMessage: function(msg) {
console.log(this.ClassName, ' msg received: ');
console.dir(msg);
},
sendMessage: function(msg) {
Register.broadcastMessage(msg);
}
});

As you can see, the register is just an array of Instances. Yes, Register is a global object, but it will be the only one we will need. Meanwhile, the Base class adds the new instance to the Register automatically. For convenience, the Base class has a sendMessage method. Also, for convenience, I like to add a ClassName property to all my classes in case I need it later for logging, instance class type identification, etc.

Now, thanks to MooTools, we can create our classes and make them inherit from Base. We can override the processMessages method and act accordingly:

var Tabs = new Class({
ClassName: 'Tabs',
Extends: Base,
…
activateTab: function(tab) {
…
this.sendMessage({msg:'tabActivated', data:tab});
}
});
var VideoPlayer = new Class({
ClassName: 'VideoPlayer',
Extends: Base,
…
processMessage: function(msg) {
if (msg.msg == 'tabActivated' && msg.data = 'video-tab') {
// Play video
}
}
});

The beautifulness of this code resides, as I mentioned before, in the absence of any object references. Tabs doesn’t know anything about the VideoPlayer class nor any other object listening to the messages. And the VideoPlayer doesn’t know anything about the Tabs class either. It only knows about the message it has to listen to. No object references, no methods, no callbacks.

Pay attention now. This is the best part! Whenever we instance our classes, no matter how many times we do, we don’t need variable references anymore:

new Tabs();
new VideoPlayer();

Nice, uh?

Since I implemented this class I use it a lot on every project at work. It makes my life easier, keeping my classes simple and independent from each other. It’s even better. We have got to a point where we have integrated this feature with our Flash components, so these send messages to the Register when needed and any JS object listening reacts to them as needed.

By doing this, even being unidirectional (Flash to JS only), we have achieved something great: from now on, our Flash objects don’t need to know anything about our JS objects at all. Just send a message to the register and done.

At any point, even from Firebug, you can send a message to the Register. This is very nice, even for debugging:

A listener class

I found it is very nice, while in development, to have a Listener class debugging any message received. This way I don’t need to add a console.log call on all my classes to output received messages. The Listener will do it for me:

var Listener = new Class({
Extends: Base,
initialize: function() {
this.parent();
this.ignoreMessages = false;
},
processMessage: function(msg) {
if (msg.msg == 'stopListener') this.ignoreMessages = true;
if (msg.msg == 'startListener') this.ignoreMessages = false;
if (this.ignoreMessages) return;
console.log('Listener: msg received:');
console.dir(msg);
}
});
new Listener();

Even you can control the Listener by sending custom messages to it! Awesome!

Could this be achieved with custom events?

With Mootools, creating custom events is piece of cake. But from what I understand, custom events work only inside the object that is firing them. This is, if object A fires an event ‘customEvent’, you can only listen to it if you add a callback function when you instantiate that class:

var A = new Class({
Implements: Events,
initialize: function() {
document.body.addEvent('click', function() {
console.log('A: body clicked');
this.fireEvent('bodyClicked', [this]);
}.bind(this));
}
});
var B = new Class({
doSomething: function() {
console.log('B: doing something…');
}
});
new A({
onBodyClicked: function() {
// Tell B to do something (you need a reference to B!)
}
});
new B(); // Will never do something

Ideally, B should be able to listen to the bodyClicked event without passing any info when A is instantiated. But if I’m not mistaken, this is not possible.

Revised version

I decided that it would be cool to have the Messenger as something my classes could implement, instead of inherit from (Base). Also, it would be good if one object could register for a specific message only, which would improve performance too.

var NotificationServiceCenter = new Class({
instances: {},
addObserver: function(msg, instance) {
if (!this.instances[msg]) {
this.instances[msg] = [];
}
this.instances[msg].push(instance);
},
broadcastMessage: function(msg, data) {
if (this.instances[msg]) {
$A(this.instances[msg]).each(function(item, index) {
item.processMessage(msg, data);
});
}
}
});
var NotificationService = new NotificationServiceCenter();
var Messenger = new Class({
addMsgEvent: function(msg) {
NotificationService.addObserver(msg, this);
},
sendMessage: function(msg, data) {
NotificationService.broadcastMessage(msg, data);
},
processMessage: function(msg, data) {
// For implementation on the final Class
}
});
var A = new Class({
Implements: Messenger,
initialize: function() {
document.body.addEvent('click', function(){
console.log('A: document body clicked');
this.sendMessage('documentbodyclicked', 'Hello world!');
}.bind(this));
}
});
var B = new Class({
Implements: Messenger,
initialize: function() {
this.addMsgEvent('documentbodyclicked');
},
processMessage: function(msg, data) {
console.log('B: msg received: ', data);
}
});
new A();
new B();

Here you go!

July 20, 2009 -- Setters & Getters on Mootools classes (2)
April 7, 2009 -- Setting up timers and intervals inside JS objects (2)
January 2, 2009 -- Solving the 8 Queen Puzzle in Javascript (1)
January 18, 2010 -- Finally: Singletons, the Mootools way (0)

Gravity in the DOM

Eneko Alonso — Fri, 19 Dec 2008 05:58:27 +0000

A couple of days ago I created a demo to simulate planets on a 2D universe interacting each other like Gravity does in our lives. To compute the movements every planet had to be evaluated with each other on every step. Their position will be affected by the other planet position and in proportion to their respective mass. This means the speed of the planets doesn’t impact the attraction between them.

Today I decided to extend this demo a little bit more and I added a few things:

Mass parameter to make mass independent from size.
Collision detector to merge planets when they meet each other with color effect.
Orbit trails

The result is very nice. The first option make it possible to create bigger planets with more mass but with a size that fits appropiately on the screen. The second option merged planets that collide, making it more like a real world. Finally, the orbit trails are just some sugar to see the trajectory followed by the plantes. To avoid the screen getting very messy, the trails clean up themselves after 25 seconds.

As you can see, the universe controller uses the Thread class I was talking about few days ago.

See both demos here:
http://dev.enekoalonso.com/research/gravity.php
http://dev.enekoalonso.com/research/gravity-2.php

PS: Please note there is no Canvas involved here. All objects on screen are DOM elements. Of course this is not the best way to do graphic animations on the web, but it is fun!

January 15, 2010 -- I never use $$ on my projects (and barely use $) (0)
April 23, 2009 -- Sending messages between Javascript objects (2)
December 14, 2008 -- Threads in Javascript (1)
May 6, 2011 -- Finding duplicate ID’s on an HTML page (0)

dev.enekoalonso.com » system