The more time I spend with JavaScript and its rich ecosystem of frameworks the more I find myself looking back at the strongly typed Silverlight/C# horizon with a smirk on my face.

The dynamically, loosely typed nature of JavaScript excells in GUI development where binding from DOM elements, doing Ajax requests with JSON and extending functionality in third-party frameworks is an everyday task.

It has been a long path from the bias and naive developer judging JavaScript as a necessary evil whose sole existence was justified by being the only cross browser language. After reading the excellent and mind-opening book JavaScript – The Good Parts I started to realize the potential of the language and since then my expectations have been far exceeded.

There are a few quirks though..

The sparse native API can sometimes remind you that you are working with a language that was created in ten days. Fortunately, the dynamic typing comes to the rescue once again and allows for third-party frameworks to fill many voids and extend features you have got used to in other, more well-designed, languages. Sugar is an excellent testament to this.

… and I can live with that, but not this

This, also known as the scope, is the execution context of which the current function is executed in. In most object-oriented languages this usually refers to the object instance in which the function is declared. In JavaScript however, this can be anything. This often confuses people, like me for example, who comes from a background programming in languages where you never have to worry about what the current scope is.

If you have done any programming in JavaScript, how often haven’t you lost track of this? I do it all the time, in Ajax callbacks:

$.ajax({
    url: 'getorders/',
    success: function(result) {
        this.orders = result;
    }
});

and in event subscriptions:

this.articleName.subscribe(function(name) {
    this.articleSlug(name.toLowerCase());
});

even in for each loops:

this.callbacks.forEach(function(callback) {
    callback(this.sammy);
});

The problem with this is that no third-party framework can *fix* it. It’s part of the core language itself and therefore not subject to the same extension or modification methods that the API, the native objects, are.

If you are working mostly with the DOM using jQuery for example, you probably don’t have to worry about this that much. But if you’re like me, creating business applications with a great deal of data binding using view models and POJSOs (is that what you call them? plain old javascript objects?), then you will run into scope problems sooner or later.

OK, so how to make this suck a little less?

I have tried a few different approaches to make work with my Knockout view models simpler. One approach was inheriting from a view model base class, using the simple inheritance technique from John Resig. The base class would provide functions to its subclasses letting them do Ajax calls, subscribing to events and more with the scope always refering the to view model instance.

This worked somewhat well, what I didn’t like about this was that it only solved the problem when you used the functions provided by the base class. If you wanted to do something else, like subscribing to an Knockout observable in your subclass, you’re back to square one again.

The solution that I’ve never had any scoping problems with is when you copy a reference to this in your view model’s constructor. Then you’re always certain that self refers to the actual view model instance.

function MyViewModel() {
    var self = this;

    self.articleName = ko.observable();
    self.articleSlug = ko.observable();
    self.callbacks = [];
    self.orders = ko.observableArray();
    self.sammy = new Sammy.Application();

    $.ajax({
        url: 'getorders/',
        success: function(result) {
            self.orders(result);
        }
    });

    self.articleName.subscribe(function(name) {
        self.articleSlug(name.toLowerCase());
    });

    self.callbacks.forEach(function(callback) {
        callback(self.sammy);
    });
}

Some people say it’s a code smell to declare a self variable and I can agree to some extent but my experience is that it’s easily worth it.