For the purposes of this post, let’s imagine we have a product review that can receive a letter grade rating (“A”, “B”, “C”, “D”, or “F”). The designers decided to have a bit of fun with this one and mocked up the rating area so that all grades are visible and grey. The grade letter rating of the product gets highlighted in this list with a color specific to the grade. This is something CSS by itself should handle, but let’s assume that for this post that we only receive the grade rating via javascript.

Here’s what the markup looks like:

<ul id="grade">
	<li id="A">A</li>
	<li id="B">B</li>
	<li id="C">C</li>
	<li id="D">D</li>
	<li id="F">F</li>
</ul>

One approach to writing a javascript function to handle this would be to check which grade is being highlighted, and set a “color” variable accordingly:

function highlightGrade(sGrade) {
    var element = document.getElementById(sGrade);
    var color;

    if (sGrade === "A") {
        color = '#009933';
    } else if (sGrade === "B") {
        color = '#009933';
    } else if (sGrade === "C") {
        color = '#ff9933';
    } else if (sGrade === "D") {
        color = '#cc0000';
    } else if (sGrade === "F") {
        color = '#cc0000';
    };

    element.style.backgroundColor = color;
}

The problem with the above example is that the color for each grade rating is hard coded within the function. Suppose that later on, someone decides to add an “C+” rating (or an “E”, for that matter). Better yet, imagine that the colors all change as well. You’d have to edit the original function and add/remove conditions to it as needed. While it isn’t hard to do so in this specific example, this is not a good coding habit to have – as complexity increases, functions get bloated and hard to maintain, and the possibility of reuse is thrown by the wayside.

This is where the idea of property maps come in – by storing all the possibilities for grade colors in an object rather than conditions in the function, we create a maintainable configuration outside the moving parts of the function:

/**
* "colors" is our property map
*/
var colors = {
    "A" : '#009933',
    "B" : '#009933',
    "C" : '#ff9933',
    "D" : '#cc0000',
    "F" : '#cc0000'
};

function highlightGrade(sGrade) {
    var element = document.getElementById(sGrade);

    element.style.backgroundColor = colors[sGrade];
};

Further Abstraction

As long as we’re considering abstraction, let’s think about the reusability of this function. We may have other elements we may want to highlight with conditional colors…

function highlightElementByCondition(sElementId, sCondition, oMap) {
    var element = document.getElementById(sElementId);

    element.style.backgroundColor = oMap[sCondition];
};

//calling it to highlight a letter grade (element, condition, map)
highlightElementByCondition(myId, myGradeLetter, {
    // property map
    "A"     : '#009933',
    "B"     : '#009933',
    "C"     : '#ff9933',
    "D"     : '#cc0000',
    "F"     : '#cc0000'
});

Of course, there are two sides to every design pattern – as always, it comes down to a judgement call. Are the conditions for a function unusually complicated? Will the conditions be likely to change? Does your function have wider applications than the specific problem you’re trying to solve?

If you make a habit of asking these questions while writing code, your coworkers and/or clients may thank you later.