Just over a month ago, I blogged about the benefits of unobtrusive JavaScript, and how it helps not only produce standards-compliant HTML and CSS, but additionally creates a framework for creating applications that is extensible and reusable.
In this installment of this series, I would like to build on this idea a bit. As you delve into unobtrusive JavaScript, you will soon learn that generifying your JavaScript functions becomes unavoidable. Yes, I said "generifying." Let me explain.
Using inline JavaScript usually means one of two things: A.) you have a one-off function that you need to fire, and you just want to get something working NOW. Or B.) you've not really investigated unobtrusive JavaScript very thoroughly, and are content with using inline calls for even the most complicated functions.
If A.) is the scenario, as your application grows and you need more functionality from your JavaScript, life is going to suck very quickly because you're going to have to do a lot of backtracking to catch up all those inline calls to match any changes you've made to accomodate new functionality. And if you're one of the B.)'ers, you'll have to do what the A.)'s are stuck doing, plus you'll have some major structural changes that will have to be made to your inline logic to sync with application expansion.
So where does the generifying of JavaScript functions come into play? Well, it's related in the sense that as you begin to develop thoroughgoing unobtrusve methodology to your JavaScript programming, you begin to see new vistas of opportunity for function sharing, code reuse, etc. Instead of having the blinders of specific HTML and CSS use cases, you are able to step back and see how this particular bit of code fits into the broader scheme of the application, and can tool it in such a way that, where appropriate, it can be something that can be shared out across the application.
So let's take an example. Let's say that you have a div with a dark background color to which you want to apply some opacity. You could, of course, invalidate your CSS and explicitly state opacity in your stylesheet...OR you could use a JavaScript function to apply opacity to the element programmatically.
Now obviously, you could easily do something like this:
function setOpacity() {
var myDiv = document.getElementById('myDiv');
myDiv.style.opacity = '.85';
}
Here is some content
So easy enough. We've set the opacity, and everyone's happy. But wait. This function is really quite worthless outside of it's singular usage here. Because all of the logic has been funneled from the inline need, rather than from an overarching architectural standpoint, we're left with a one-and-done function.
If we begin from an unobtrusive perspective, however, we find a lot more flexibility is possible. But even more, we find that it nearly demands to be this. Let's go back to our example. Sure, we have a div that needs to have JavaScript opacity support. But surely in our application, there is the possibility that other elements will need the same support. Heck, I would argue that even if this is not the case, we should go ahead and build it for that contingency, just in case! So now we need to architect something that is flexible and will accomodate a wide range of scenarios.
What will this look like? Well, first of all, we need to get rid of the rigid invocation of the particular div in our function. Instead of specifying an individual div, let's build it so that any ID'ed div can be passed to the function (here, I would suggest using jQuery, Spry or another framework that have element selector shortcuts...it saves a lot of typing!):
function setOpacity(div) {
var myDiv = Spry.$(div);
myDiv.style.opacity = '.85';
} Here, using Spry's element selector syntax, I've told the function that a div is required, and that a variable should be created from whatever div is passed into the function. Even in this simple scenario, we have the foundations of a very flexible function. But let's go further. Maybe we want to have a variable amount of opacity on different divs. Okay, let's set that up:
function setOpacity(div,opacity) {
var myDiv = Spry.$(div);
myDiv.style.opacity = '.' + opacity;
} In a similar fashion, I have setup the opacity to now be a variable amount which can be applied as needed on a case by case basis (note: I am passing in a whole value here [e.g., "85"] because to properly set opacity, there are several CSS attributes that will have to be set, and some require a different syntax than '.85').
So there we have it. Our very simple function is complete. Now you may be underwhelmed by this example. However, do not miss the point. The beauty of programming this way is that the function we have created is completely ambivalent about the outside world. All it knows is that it applies CSS opacity to HTML objects. It doesn't care about specific ID's nor opacity amounts--it'll take anything and everything and do what it's supposed to do.
Hopefully this is making sense. What we are doing is setting the groundwork for a scalable function that can really become a handy shortcut as the application grows. Instead of having to create a billion custom functions that set CSS opacity, we have this one function that handles everything. And while this is a extremely rudimentary example, the principle can be applied to the most complex of functions, and the benefits are limitless.
More in this series:
On Becoming a Better Web Designer, Part Third
On Becoming a Better Web Designer, Part Deux
On Becoming a Better Web Designer [First Part]
Yeah, so I'm really dumb. For a long time, I've used DreamWeaver pretty much exclusively as an IDE for my web projects. There's something that makes sense here, as it has pretty good HTML and CSS features, and some limited ColdFusion and XML niceties. However, it is the suck when it comes to JavaScript editing.