How to implement the Javascript mediator (publish-subscribe) pattern

Question

Background

We have a fairly complex Silverlight client which we are rewriting in HTML/Javascript/CSS, built on top of the same web services. Actually we have two Silverlight different clients which we are porting, which share some common functionality.

I read the article on http://addyosmani.com/largescalejavascript/ and am planning to use the proposed architecture, and in particular the mediator pattern.

A 10000 feet overview of the pattern described by Addy:

• code is divided into small Modules
• Modules are only aware of a mediator object; Modules cannot communicate directly with other modules
• the mediator has a simple interface for publishing and subscribing to messages
• Modules can subscribe to messages (through the mediator API), giving a callback function
• Modules can publish messages to the mediator, with a parameter object, and the mediator calls the callback method of any modules subscribed to the message, passing the parameter object

One of the main goals here is to achieve loose coupling between modules. So we can reuse the modules in the two clients. And test the modules in isolation. And the mediator should be the only global object we need, which has got to be good.

But although I like the idea, I have the feeling it is overly complicated in some cases, and that some of my team members will not be convinced. Let me explain by example:

Assume we have a helper function which performs a calculation - lets say it formats a string - and assume this function should be available to any module. This function could belong in a 'tools' or 'helper' module which is then reusable and testable.

To call this function from an arbitrary module I have to post a message, something like formatString with my input string as parameter. And the helper function has subscribed to the formatString message. But before I post the formatString message I first have to subscribe to a message like formatStringResult, with a callback function which can receive the result. And then once I get the result back, I unsubscribe from the formatStringResult message.

Question(s)

• Should the mediator rather offer this type of helper functionality directly in it's own interface?
• Or should I extend the publish interface to allow an optional result parameter, where helper methods can directly write a result?
• Is the tradeoff of having an extra mediator layer really worth the benefit of achieving loose coupling?

I'd really appreciate advice from developers with experience of achieving loose-coupling in 'complex' JavaScript applications.

Answer 1

I don't think that mediator is the pattern what you are looking for, at least not for what you described.
Just think of 2 object triggering formatString the same time. What each would get back in their formatStringResult?

Mediator is for broadcasting events to everyone who is listening. Publishers don't want to broadcast requests (e.g. formatString) rather want to notify others about a change in their own state. Note how the source and consumer of the information is different. Having a mediator means those parties don't have to have a reference to each other to communicate, thereby its lowering the coupling.

Answer 2

You actually perfectly described the BarFoos application Framework:

https://github.com/jAndreas/BarFoos