I came across Addy Osmani's blog post about Learning JavaScript Design Patterns the other day. Loved it!
I think I'm one of those silly developers that gets super-duper excited when I see something that I like and then get to put it in practice. Well, I did exactly that. :)
I loved what Addy said about design patterns:
I was writing a rule engine for a part of our application. As you can see in the code below, the sp.editor.rules namespace contains the methods such as MeetsButtonCriteria that I can call.
The namespace also contains other helper methods that MeetsButtonCriteria calls such as _AreMultipleNodesSelected. In the code I simply used a convention that private methods begin with an underscore.
While that seems to do the trick, I still found that rather clunky and non-defensive. This is where I thought that the Revealing Module Pattern might help.
The main benefit of the pattern is that the pattern allows the syntax of our scripts to be more consistent. It also makes it more clear at the end of the module which of our functions and variables may be accessed publicly which eases readability.
So this is what the modified script looks like.
Easy-peasy na? Also, just a word of advise, I forgot to convert sp.editor.rules to a self executing function and spent like 15 minutes trying to figure out what was wrong. Yikes! So don't forget that.
I loved what Addy said about design patterns:
"Patterns are not an exact solution. It’s important that we remember the role of a pattern is merely to provide us with a solution scheme. Patterns don’t solve all design problems nor do they replace good software designers, however, they do support them".Let's get into it then ..
I was writing a rule engine for a part of our application. As you can see in the code below, the sp.editor.rules namespace contains the methods such as MeetsButtonCriteria that I can call.
$(function () {
if (sp && sp.editor) {
// Initialise the rules namespace
sp.editor.rules = sp.editor.rules || {};
// Private methods
sp.editor._AreMultipleNodesSelected = function () {
// Logic goes here.
};
// Rules for buttonize
sp.editor.rules.MeetsButtonCriteria = function (editor) {
if (sp.editor._AreMultipleNodesSelected(editor)) {
// More Code Here ..
} else {
// More Code Here ..
}
return true; // Temp Return True
};
}
});
The namespace also contains other helper methods that MeetsButtonCriteria calls such as _AreMultipleNodesSelected. In the code I simply used a convention that private methods begin with an underscore.
While that seems to do the trick, I still found that rather clunky and non-defensive. This is where I thought that the Revealing Module Pattern might help.
The main benefit of the pattern is that the pattern allows the syntax of our scripts to be more consistent. It also makes it more clear at the end of the module which of our functions and variables may be accessed publicly which eases readability.
So this is what the modified script looks like.
sp.editor.rules = function () {
// Declare the Private Functions Here!
var areMultipleNodesSelected = function () {
// Logic goes here.
};
var meetsButtonCriteria = function (editor) {
if (areMultipleNodesSelected(editor)) {
// More Code Here ..
} else {
// More Code Here ..
}
return true; // Temp Return True
};
// This is what gets returned (REVEALED).
return {
MeetsButtonCriteria: meetsButtonCriteria
};
}();
Easy-peasy na? Also, just a word of advise, I forgot to convert sp.editor.rules to a self executing function and spent like 15 minutes trying to figure out what was wrong. Yikes! So don't forget that.
