Let’s Talk About this…
You are going to love this.
A few months ago, Bee wrote a piece outlining the use of this and parameters in Javascript. Today we are revisiting that article, and getting into a little bit more detail about what they are and why we use them. Read on!
On parameters, properties, this, and that..
I’m currently learning JavaScript in the Skillcrush Front-End Developer blueprint. One of this week’s topics was the use of properties inside methods.
This is what I’ve got and please, oh, please, tell me if how much your interpretation differs from mine.
When using this inside a method, object.property becomes this.property in console.log, having to have had property previously defined. And that’s it.
When using a parameter, property is not defined but included in the function only as “property”, not “object.property”. Then in console.log, it’s included the same way. And the value is announced until you call it, as a string.
I think I understand the point of parameters better. But I really like the ease of using this. Although that’s besides the point because, scope… and that’s a whole other behemoth I hope you will help me tackle.
For now, comment and tell me about your own experience with properties inside methods and what you think on my first post!
Neat tricks, right? But why do we use them? Using this with parameters will make you a master of DRY programming- write a function using this and you can call the function as a method on any object. This gets bound to the object is was called upon and is infinitely reusable. Parameters let you further customize the function while it remains structurally the same. Welcome to concise and consistent code. We’ll take a look at some code from this very simple frogger arcade clone, built as part of Udacity’s Object Oriented Javascript course, to illustrate how this can improve your development process.
Our game has two actors that can affect the outcome: the player, controlled by the person playing the game, and the enemy, the computer opponent. The Catalyst superclass contains all the characteristics shared by both actors. It has three parameters, which determine the location and appearance of each instance of the catalyst object. These are things that must be determined for every actor in the game.
To create a new Player instance, we call on the Catalyst superclass and pass parameters that make it a Player. After Catalyst is called, the Player prototype adds further attributes that are unique to the Player class, and further makes use of this to update characteristics that will be unique to every Player instance. This way, every time the game resets, the Player will reset too.
The Enemy class relies on the Catalyst superclass to build each instance’s location and image the same way the Player does, but it has passed a different URL as a parameter to get the image- it’s still made the same way, but the new parameter gives it the appearance specific to its class. The Enemy is also different from the Player class because its movement is pre-programmed, so this is again used to refer to the object that the function is being called in. There are multiple instances of the Enemy present in each game, so using this further simplifies our code by allowing each one to hold its own data without rewriting the information each time.
Like a semicolon, a missing this, or one in the wrong place can cause big problems and be hard to find. An errant this will have your entire application jumping scope and crashing, and then what do you do? That’s right, you cry and stress eat for three days before identifying the problem.
So there you have it: this in action. Give it a try, your code will thank you. If this has got you interested in learning more, be sure to visit the MDN documentation.
We are not saying we are working on a special project for you to practice on your own, but if we were your cool teacher we would tell you to underline, take notes, and share with your friends…
