Question

This is more of a general question about the structure of my JavaScript code and if I'm going in the right direction towards well structured code.

The current code I've got:

(function (myNamespace, $, undefined) {
    myNamespace.className = {
       init:function { } // do stuff
    }
} (window.myNamespace= window.myNamespace|| {}, jQuery)));

(function (myNamespace, $, undefined) {
        myNamespace.className2 = {
           init:function { } // do stuff
        }
} (window.myNamespace= window.myNamespace|| {}, jQuery)));

Obviously with the above code, I can use the same Namespace (as per page/site section) and call them via myNamespace.className.init() etc. I can also combine these if I want to, but I'm encapsulating classes for readability.

Now, I've been reading http://addyosmani.com/largescalejavascript/ about the concept of mediators. My secondary question is when (and if) I should be using these? From className2 obviously I can do:

 myNamespace.className2 = {
               init:function { myNamespace.className.init() } // do stuff
            }

So why would this ever subscribe to className like mediator.subscribe("classNameInit") and publish that event in className?

I'm highly open to suggestions about the structure of my code as this is something I need to get right whilst I'm changing the way I write my JavaScript.

Was it helpful?

Solution

You would use it when you have multiple pieces which will work together in unlimited combinations where you don't know all combinations ahead of time or where it's more efficient to assume all combinations.

Let's say you were building a social media app and you wrote a class to encapsulate a list of users. On some screens, clicking on a user in the list opens their profile, on another screen perhaps clicking a user searches for every comment they left, and on a third screen something else happens.

If you were to write this not using mediator/pubsub, what you'd end up with is a bunch of if statements in the onclick event...

UserList.prototype.onUserClick = function(user) {
     // Check if we're supposed to open a popup
     if (this.mode === 'profile')

     // Check for something else
     else if (this.mode === 'something else')

     // Check for another case
     else if (this.mode === 'foo')
}

Mediator is a solution to this problem because it doesn't require that UserList have knowledge of every single situation it might end up in. Instead, the above code in UserList could simply be refined to broadcast when a user is clicked on...

UserList.prototype.onUserClick = function(user) {
    this.publish('user-click', user);
}

Then each of your other screens or UI pieces can simply listen for the user-click message...

// On pages where there needs to be a popup profile
Mediator.onMessage('user-click', function(data) {
    showProfilePopup(data);
});

// Or perhaps on a search page
SearchBox.onMessage('user-click', function(data) {
    this.searchByUser(data);
});

Furthermore, where mediator begins to shine is because these other UI components, like SearchBox are not interested in specifically when UserList fires a user-click, they're interested only when a user-click is published, other UI controls on the page can fire user-click as well and these pieces can react to it.

On a side note, className = { } isn't creating a class. What you probably want is className = function() { }.

Licensed under: CC-BY-SA with attribution
Not affiliated with StackOverflow
scroll top