JavaScript’s cryptic ‘this’ – what, when and why

*Photo by Tarun Ram on Unsplash

Before MDN started to organize their JavaScript documentation, finding answers to your JavaScript questions often landed you on Stack Overflow.

Welp, these days MDN has mostly done away with that practice, that is, except if you’re looking for answers around the usage of JavaScript’s this keyword.

The documentation is great, it really is, but it’s not exactly full of helpful, real-world examples. So I thought I’d put together a few tips and tricks about the ever so magical this keyword.

Old-skool JS

“Back in my day we had to alert out our objects!”

Ok, so yeah, if you run console.log(this) in your dev console you’ll generally see that by default, this = Window{}. Super helpful…😏

It gets more interesting when you check the value of this inside a function:

function mahFunc(){
    console.log(this);
}

mahFunc();
// Window{}

You should still see the Window object. Ok so, nothing new here.

But what if you add 'use strict'?

function mahFunc(){
    'use strict'
    console.log(this);
}
// undefined

Hmm.

Ok now, but what if you call mahFunc() on the Window global (since it’s a global function)?

function mahFunc(){
    'use strict'
    console.log(this);
}

window.mahFunc();
// Window

Huh?

Strict mode is a funny beast, but it generally makes errors more obvious and cleans up your JavaScript. Something not mentioned in the MDN docs is that bundlers/loaders/concatenators like Webpack/Browserify, may have strict mode enabled by default. You might end up with some wacky loader that enables it with out you knowing. So keep an eye out if you ever see your this call returning something funny.

Call me plz

Ok so this in a global context is weird, but who doesn’t use objects and ES2015 classes these days? If you’d like to use a different value for this, (as-in not undefined or Window) inside your function, you can pass a context with .call() and .apply(). I always remember these with ‘yadda-yadda.prototype.call()’.

function mahFunc(){
    console.log(this);
}

const config = {

    stepOne(){
        //do step one
    },

    stepTwo(){
        //do step 2
    }
}

mahFunc.call(config);

//{stepOne: ƒ, stepTwo: ƒ}

And there you go. this references the object passed in argument to .call(). Cool right?

This way you’re able to specify a context for a function. It’s super handy and what a lot of frameworks and bundlers use internally – check out your Webpack bundles!

I won’t go over all the possible cases/uses of this, there’s quite a few and the MDN doc is really good.

It’s important to remember this 🙄.

Open Source, PHP and Visual Studio Code

Lately, VS Code has been getting a lot of hype in the dev community. It’s been around since for a few years and TBH is a really sweet editor. Lots of great extensions and community support. It’s also quite fast (for an Electron app 😬) and the peeps and Microsoft seem to be keeping it up to date and iterating quickly.

However, anything you really need to work with PHP is missing by default. I believe this is by design to encourage a vibrant extensions community. Luckily, like most languages, there’s a vibrant open source PHP extension community. There’s a few great extensions for PHP: PHP IntelliSense, PHP Debug (both by the same developer) as well as PHP Intelliphense (#wat?). There’s even a really great intro by Jeffrey Way on Laracasts outlining everything you need to do to get VS Code set up for PHP dev.

Some of the PHP packages work fine and have over a million installs (!!!). Sometimes, however, they don’t work. Like, at all. Just today, the PHP Debug extension completely broke. Luckily the developer was paying attention and rolled out a fix within hours. Pretty awesome support for an open-source product!

However, if you paid for the editor, say something like PHPStorm, you could go and raise an issue on their support channel. You could complain about the product not working, rightly so, as you’ve paid for the right! As a ‘customer’ you have a certain amount of clout with a vendor like Jetbrains. This is NOT the case with open source, and I feel that we developers forget this.

This is where I take issue. I’m all for open source software. I’ve built my career on it. The issue is that the developer for this plugin had to fix the issue himself. There’s an expectation there that he HAS to fix the issue, and do it RIGHT NOW. And if it’s not done immediately people freak out, complain on Twitter, write a blog post about, have a cow 🐮, man.

Open source is just that, open. If you find an issue with a plugin, editor, extension or WHATEVER, see if you can fix it! That’s the whole point. Let’s not throw our hands up and complain, let’s get our hands dirty and fix the damn thing.

That’s what open source is all about. Let’s remember that.

/rant