mf Object Methods Part 2 {mf.object}

This is a series of posts that explains some of the fundamental rules for developing complex JavaScript applications and the mf framework.

In my previous post on the mf object methods I discussed several methods that act against a single object. In this next series of object methods I will begin demonstrating some of the mf object methods that deal with arrays of objects. When we look at applications within the business sphere we in most cases have to deal with large amounts of data that is displayed in grids and other standard user interface implementations. When dealing with this type of data you need to envision, in regards to a grid, what types of behaviour and functionality you need to provide to the consumer. There are some obvious features like sorting and search plus filter. As such we need to provide these types of methods as part of the object methods. In the future of mf I will be developing a store object which will make significant use of these methods. In this post I will discuss the following methods…

• mf.object.exec
• mf.object.normalize
• mf.object.merge
• mf.object.sort
• mf.object.search
• mf.object.difSearch

Creating Object Properties {the dangling participle of JS Objects}

This is a series of posts that explains some of the fundamental rules for developing complex JavaScript applications.

As most of us know, well I would hope most of us that is, properties in objects have some fundamental flaws in them, that, like many situations in JavaScript our bits and bites are left hanging out!  Object properties that are exposed publicly, whether in a module pattern or an instance have absolutely zero control over them.

If one does some research however you will dig up the Object.defineProperty method and supporting methods that as of IE9 are now common across all modern browsers.  If you are interested in reading up on the defineProperty Object method I have found the best documentation to be over at Mozilla . While Object.defineProperty does provide us enhancements such as read only, freezing and preventing deletion is certainly does not, in my opinion, provide much power. A property should provide the following:

• Verbose setters and getter methods,
• Conditional checking on setters,
• Chaining of base object setters,
• Watches and events.

Singleton to Prototype Design Guidelines

This is a series of posts that explains some of the fundamental rules for developing complex JavaScript applications.

I am a real bugger when it comes to how my code is organized. Given the advanced user interfaces that we have today I have often noticed that JavaScript developers have become, for lack of a better adjective, bloody lazy!  Before we get into the singleton design patter a short discussion is warranted on when a singleton should be used versus a class that supports instantiation.

The most common examples of a singleton are existing JavaScript frameworks such as ExtJs, jQuery, etc. In essence we would only ever have a single instance of each of these frameworks each represented by its own unique namespace Ext and $ respectively. The other most common example of the singleton pattern is the root namespace that represents your JavaScript application because you would under most circumstances only have one. Note I said most circumstances.  There is often the case in the real world where a requirement initially requires a singleton pattern but over time it becomes evident that a class instance would be better.  The golden rule of ‘the only constant is change’ should always be kept in mind when designing your code structures. The purpose of this post is to demonstrate how to effectively use the singleton pattern properly and in such a way as to allow for the easy migration to a class pattern. The secondary goal is to show how writing your singletons in this fashion leads to consistency of code which is something we should all strive for!

First let’s look at the basic singleton design pattern that I often see exemplified on the web.

var mySingleton = {
                 globalVar1 : null,
                 globalVar2 : null,
                 myMethod1 : function(){},
                 myMethod2 : function(){}
 }

So I will state this very clearly and strongly, the above is NOT a singleton.  In my opinion this is a simple object that does nothing more provide a hierarchical structure of variables and methods under a root namespace.  For starters this pattern does NOT use closures and does not have the concept of private/protected vs public methods and variables. At a minimum the singleton design pattern should be written as follows.

Writing Flexible JavaScript Functions

This is a series of posts that explains some of the fundamental rules for developing complex JavaScript applications.

How often have we seen function grow over time with just one more parameter added for that supposed last little piece of functionality we have to add. Far too often I would imagine.  Then add in the new requirement that some of the parameters on the function need to be optional and the next thing you know you are in a world of hurt. There is a basic maxim in any software development, the only constant is change. As a result as a software writer I strive to ensure my code recognizes this maxim along with a couple of others.

Alas for JavaScript, the poor Yorick of languages we all know so well, it does not give us a lot of flexibility in the function object. Unlike other languages, even SQL, functions/methods provide much greater flexibility in there definition, including default values, optional parameters, name parameter calling, e.t.c. It would certainly be nice if we could provide a similar model to JS function calls and definitions. Many a moon a go I started developing in ExtJS and was introduced to a very simple method called Ext.apply and Ext.applyIf. In essence these methods take two objects as parameters and merge them into one. So if you call Ext.apply({a:1,b:2},{c:1}) you would get back {a:1,b:2,c:1}.  Sounds simple enough right? The applyIf works in the same fashion but makes a test in the receiving object to see if the property already exists and if so does not over write it. This is a very simple piece of code that we can look at below:

function applyIf(objectTo,objectFrom){
              if(objectTo){
                          for(var property in objectFrom){
                                      if(typeof objectTo[property] == 'undefined' ){
                                                  objectTo[propety] = objectFrom[property];
                                      }
                          }
              }
              return objecTo;
  }

So in essence, enumerate through the properties in objectFrom and if the property does not exist in the objectTo then add the property and its value from the objectFrom. So what does this have to do with functions you are probably asking? Let’s have a look at a mythical function as an example

function doSomethingCool(
              // width of element
              width,
              // height of element
              height,  
              // text of element
              text,
              // optional x and y, element type and style string
              ,x,y,elType,style){…do some stuff}

Looks simple enough but what’s with the four of optional parameters at the end of the function.  As you well know from in your function code you end up with a bunch of if statements along the lines of if(x===undefined){x=0}.  This of course gets to be a pain in the code rear. Now let’s change our function to accept to a single parameters as an object.

function doSomethingCool(config){
            config=applyIf(config,{
                          width : null,
                          height : null,
                          text : ’’,
                          x : 0,
                          y : 0,
                          elType : ‘div’,
                          style : ‘position:relative’
              })
… do some stuff
  }

So now in our doSomethingCool function we can easily default each parameter in our function and reduce the amount of if conditions to test for them.  By defaulting each of our values we also reduce the risk of errors being introduced by bad callers.

This may seem like a simple idea but it has a couple of extremely important advantages.  How many times have you had to go and look up a function you wish to call to check the order or the parameters? I would guess far too many times. Using a single parameters object order of the values in the object to not matter. But there is a far more important reason to use this method and that is in regards to the caller.  In the standard function design you would see some code calling the method like thus:

doSomethingCool(10,10,’my text to display’,undefined,undefined,’span’)

Really does not really tell you much when you look at it does it. When another developer has to go through your code the above line tells him/her absolutely nothing and forces them to go and look at the doSomethingCool function to determine what 10 and 10 is and why are there two undefined. Now lets make the same call to the function using the config object parameters:

doSomethingCool({
              width : 10,
              elType : ‘span’,
              height : 10,
              text : ‘my text to desolay’ 
  })

Looks a lot better doesn’t it! Not only is it very clear on what we are passing, we also did not need to add in a bunch of undefined definitions to get to the elType parameter. Notice also that in the above the order of object properties do not matter either.

A couple of noteworthy things about implementing your functions this way. If you need to add another parameter to your doSomethingCool function you can simply default it the default config object that is applied without any concern of impacting existing callers.  Another great benefit is code readability. How often have you had to take someone else’s code over? Now imagine reading through that code and seeing all these clearly understandable calls.  Not only does it benefit you when you need to revisit something but it will benefits the next developer who has to hit your code to make a modification.

In the next part of the series I will be exploring Crockford’s singleton pattern vs the prototypal pattern and how to merge, extend them and organize code.