“This. Is Not. For. Practice!” – a phrase used to emphasize that you must get things right. Mentors have used it to mean “Get serious, now!”.
For years jQuery has been a tremendous productivity boost for client-side development; so successful, that it gave rise the Single Page Application (SPA) where a good portion of your application logic was now written with Javascript. Soon, so soon, we all learned that the increased complexity of our client side solutions required good organization, a better architecture. Time to get serious about clean code.
If you are .Net developer, then many times you can fall into the ECMAScript trap: all ECMAScript must be the same. What I know from C# must be applicable to Javascript, ’cause it looks the same. Sad news, it’s not. Javascript executes in a much different environment. And to make things more confusing, close cognates such as this are not close enough. “this” in C# is a reference to the current object. “this” is Javascript is , well, it all depends. “this” in Javascript changes context dependent on many factors. A good reference is here at Mozilla. Let’s create a quick summary, and where relevant we’ll talk relevant areas that impact programming practice:
Global Context
When you are outside any function, this is referred to as the global context. ”this” will refer to document. So if you fire up the console and perform this test:
console.log(this == document); // true.
And in web browsers this also equals the window. So:
console.log(this == window); // true.
Yikes! Wait there’s more. Try this little piece:
var yikes = "ouch"; console.log(window.yikes); // ouch
window is our global memory space. So think back to any client side code you have written, and this should be very familiar to you:
<script type="text/javascript" src="scripts/jquery.min.js"></script>
This loads jQuery into the global memory space. Go look at window and you will see “window.$” and “window.jQuery”. You guessed it, jQuery is now loaded into the global namespace.
This may seem like a digression, but we need to pause at this very important point. You must be really careful what you put into this global space. As you grow in Javascript capability you will eventually develop your own utils or libraries. So consider this very innocent utility file:
function objectToArray(sourceObj) {
var results = [];
for (var key in sourceObj) {
if (sourceObj.hasOwnProperty(key)) {
var newObj = sourceObj[key];
newObj.objectKey = key;
results.push(newObj);
}
}
return results;
};
function localize(t) {
var d = new Date(t + " UTC");
return d;
}
function parseDecimal(d, zeros, trunc) {
if (d == null)
return 0;
if (typeof d == "number") {
return parseFloat(d);
}
d = d.replace(/[a-zA-Z\!\@\#\$\%\^\&\*\(\)\_\+\-\=\{\}\|\[\]\\\:\"\;'\<\>\?\,\/\~\`]/g, "");
while (d.indexOf(".") != d.lastIndexOf("."))
d = d.replace(/\./, "");
if (typeof zeros == 'undefined' || zeros == "") {
return parseFloat(d);
}
else {
var mult = Math.pow(10, zeros);
if (typeof trunc == 'undefined' || (trunc) == false)
return parseFloat(Math.round(d * mult) / mult);
else
return parseFloat(Math.floor(d * mult) / mult);
}
};
All of these functions are now attached to the global namespace, our what is called “polluting the global namespace”. Most likely a utility class will have 20 – 30 functions, not the mere three listed above. These functions will remain in memory until the user refreshes or navigates away from the page. With a small app, this will be no problem, but anything with a moderate degree of code will soon balloon and consume memory. And in some cases, such as a mobile friendly websites, you want to conserve as much memory as you can, only loading the objects that you need then allowing them to be garbage collected.
Wow – we’ve only covered “this” in a global context, and if your head isn’t a little numb, don’t worry, do another shot and see if it gets worse!
Function Context – Simple Call
Here we get a strange, as this is the rule: ”this” will depend on how the function is called. Consider this code:
var myFunc = function(){
return this;
};
myFunc() == window;
Since we are not using strict mode “this” must refer to something so it will default to the global object. Changing the code to:
var myFunc = function(){
"use strict";
return this;
};
myFunc() == "undefined";
Function Context – As An Object Method
The rule here is “this” refers to the object that the method is called on. For example:
var mathDoer = {
someNumber: 13,
addSomeNumber: function(addMe){
return this.someNumber + addMe;
};
};
mathDoer.addSomeNumber(7); // returns 20
You’ll note that both mathDoer.someNumber and mathDoer.addSomeNumber() are public in scope. When first developing in Javascript it may be tempting to create your objects as depicted below, and while it is legitimate, it will lead to clutter very quickly:
var mathDoer = {};
mathDoer.someNumber = 13;
mathDoer.someArray = [];
mathDoer.addSomeNumber = function(){ ...};
Imagine this is a none trivial object, and you will have a cluttered mess. Also, all your methods and properties are public, which you may not want to expose.
Function Context – As A Constructor
When used in a constructor “this” will refer to the object that is being instantiated. This is best illustrated with the following:
var mathDoer = function(){
this.someNumber = 13;
this.addSomeNumber = function(addMe){
return this.someNumber + addMe;
};
};
var mathIsFunObj = new mathDoer();
mathIsFunObj.addSomeNumber(7); // returns 13
Many of you may be coming to Javascript via KnockoutJS, a data binding library that provides two way binding between the DOM and Javascript objects. Many of the KnockoutJS samples use this “style” for creating ViewModels:
var mathDoerViewModel = function(){
this.justAnInt = 5;
this.someNumber = ko.observable();
this.addSomeNumber = function(addMe){
return addMe + this.someNumber();
};
};
var vm = new mathDoerViewModel();
ko.applyBindings(vm);
Again, our observables and functions are public in scope. If you have a separate file for this ViewModel and simply include it with the HTML your “vm” variable is now added to the window object and part of the global memory space. This can be considered good or bad. From a diagnostics perspective, you can sit at the console and see what our ViewModel is doing by simply issuing commands like “vm.someNumber(45);” Good for debugging. This is also considered bad by others for two reasons: everything is public, and this can lead to bloated objects that are hard to use; and, you have added yet another item to the global memory space. Imagine you have several ViewModels for a single page. Things can get confusing very quickly.
So how can you make items private? Remember that the scope of “this” when used in a constructor is a reference to that object – in our case that object is mathDoerViewModel. If you were merely to declare a variable in the constructor, the scope of that variable would be local to the constructor. This “hides” the variable from contexts that are outside the scope of the constructor. That would look like this:
var mathDoerViewModel = function(){
var _justAnInt = 5; //this makes the variable private
// function is local in scope
var privateFunction = function(){
// our locals are available as well a methods and properties from the object ("this")
return _justAnInt + this.someNumber();
};
this.someNumber = ko.observable();
this.addSomeNumber = function(addMe){
return addMe + this.someNumber();
};
};
From the console still can interact with mathDoerViewModel.someNumber() and mathDoerViewModel.addSomeNumber(). We also have private functions and variables now: _justAnInt and privateFunction. For the .Net developer these conventions should have more familiar feel.
When you scour the web for Javascript code, you’ll find that many of the Javascript heavies will use a different standard for variable / scope hiding. We touch on that briefly here before we move on. In Javascript, your constructor returns a reference to the object you are creating. In other words, your constructor will return a version of “this” that refers to the objects properties and functions. However, your constructor can also return an object. This gives you great flexibility, and makes the “Module Reveal Pattern” possible. First here is what our ViewModel would look like using the Module Reveal Pattern:
var mathDoerViewModel = function(ko){
var _justAnInt = 0;
var _someNumber = ko.observable();
var privateFunction = function(){
return _justAnInt + _someNumber();
};
var addSomeNumber = function(addMe){
return addMe + _someNumber();
};
var setJustAnInt = function(value){
_justAnInt = value;
};
var showMeTheInt = function(){
return justAnInt;
};
// We return an object that refers to items we want to be public
return {
someNumber: _someNumber,
addSomeNumber: addSomeNumber,
showMeTheInt: showMeTheInt
};
};
Looks a little different. In our constructor we are creating local variables and local functions, and in fact our observable – _someNumber – is now a local variable. But we “reveal” the items that we want to be public with the “return” statement. So in this case, we return an object with someNumber that references _someNumber, and references addSomeNumber. As a result, we can create:
var vm = new mathDoerViewModel(ko); // Set value of someNumber vm.someNumber(35); vm.addSomeNumber(5); // returns 40 // Let's use our setter vm.setJustAnInt(12); vm.showMeTheInt(); // returns 12
Notice that we are passing in a “ko” variable in the constructor call. This serves many purposes: firstly, it makes the ViewModel modular, and allows us to load the module asynchronously with AMD tools like requirejs or curljs; secondly, the constructor signature lets us know that we are depending “ko” to make our ViewModel work; finally, it gives us a tiny speed boost as now that “ko” is local, since Javascript does not have to search up the stack to find it.
You should avail yourself of the fantastic book “Learning Javascript Design Practises” by Addy Osmani. He’s been kind enough to place a copy online. This will help you understand some of the code that is that would otherwise seem very strange compared to what you are used to in C#.
Function Context – As A DOM Handler
Moving on the DOM, “this” takes on a different context. You’ll most likely be familiar with this common jquery statement:
$(".apparea").on("mouseover", ".milestone-border", function (event) {
// here this means the DOM element with a class of "milestone-border"
$(this).addClass("selected-children");
});
The rule here is that “this” means the DOM object that fires the handler. So in this case “this” is equal to event.currentTarget.
Go Forth And Create
By now your head should hurt a little, with all these nuances it’s wonder that you don’t feel more beaten up. That’s where the complexity of web development is under appreciated. Hopefully we have covered enough here for you to save some time debugging, designing, or trying to understand some the vast Javascript frameworks, utils and libraries that are out there. If you are coming from .Net and are new to Javascript, you avoid the trap that many have fallen into of creating monstrous Javascript objects of pure public functions and properties jammed into a single file. This will lead to a deep valley of frustration when it comes time to refactor your code after you realize you have a hard time maintaining things. If you can keep your code modular and have things reside in separate files, you’ll be better off.
We covered “this” in order to reveal some deeper yet vital nuances to Javascript. Mastering “this” and the related topics above are going to help. A lot. This brings Javascript from being a “toy” to really productive platform because you can avoid some pitfalls that slow you down. In future posts we continue to build on this foundation where we focus on modular design and asynchronous loading.
