The this parameter is a vital ingredient in object-oriented JavaScript and a deep understanding of how it behaves is key to unlocking so many other concepts. By the end of this article, you should have gotten the insight needed to forever dispel any uncertainty you may have on this subject matter (pun so intended).

What exactly is "this"?

When a function is invoked, in addition to the explicit arguments passed to it, it receives other implicit parameters under the hood that are accessible within the body of the function. One of these is the this parameter which represents the object that is associated with the function invocation. It is often referred to as the function context.

However, this and the way it is determined is one of those things in JavaScript that are not so straightforward. The value of this is not only dictated by how and where a function is defined, but also, largely by how it is invoked. To begin making heads or tails of how this in a function is determined, we have to revisit our knowledge of function behavior.

Invoking functions

There are four ways functions can be invoked in JavaScript, each with its own peculiarity:

1. As a function—averageJoe(), in which the function is invoked in a straightforward manner
2. As a method—averageJoe.talk(), which ties the invocation to an object, enabling object-oriented programming
3. As a constructor—new AverageJoe(), in which a new object is brought into being
4. Via the function’s apply or call methods—averageJoe.call(someObject) or averageJoe.apply(someObject)

— Secrets of the JavaScript Ninja, Second Edition

As a function

When a function is invoked in a straightforward manner, its function context (that is, the this value) can be two things. In non-strict mode, the global context (the window object) becomes the function context. In strict mode, it will be undefined.

function averageJoe() {
    console.log(this)
}

function strictJoe() {
    "use strict"
    console.log(this)
}

averageJoe()  //  window object
strictJoe()  //  undefined

The outcome is the same even if the function is defined within a function, so long it is invoked in a straightforward manner:

function outer() {
  function inner() {
    console.log(this)
  }

  function strictInner() {
    "use strict"
    console.log(this)
  }

  inner()  //  window object
  strictInner()  //  undefined
}
outer()

As a method

Functions can also be properties in objects and in that capacity, they are known as methods. When a function is invoked through an object (as a method), the object itself becomes the function context and is accessible within the body of the method via the this parameter.

averageJoe = {
  name: "Joe",
  talk: function() {
    console.log(this)
  }
}

averageJoe.talk()  //  {name: "Joe", talk: ƒ}

As a constructor

Constructor functions are essentially the same old, run-of-the-mill functions we've been dealing with. As the name implies, we use them to "construct" new objects. To invoke a function as a constructor, we precede the function invocation with the new keyword.

When a function is invoked with the new keyword, a new object instance is created and provided to the function as its context. Within the function, any reference to this is a reference to the newly created object instance.

function AverageJoe() {
  console.log(this)  //  {} 'new object'
  this.name = "Joe"
  console.log(this)  //  {name: "Joe"}
}
new AverageJoe()

Via the apply or call method

Functions in JavaScript have access to two inbuilt methods: apply and call.

func.apply(thisArg, argArray)

func.call(thisArg, arg1, arg2, ...)

They allow us invoke a function and explicitly tie it to an object. Any object supplied to the thisArg parameter becomes the function context and what is referenced by this within the function.

let averageJoe = {
  name: "Joe"
}

function randomGuy() {
  console.log(this)
}

randomGuy.call(averageJoe)  //  {name: "Joe"}

Taking a closer look at functions

Functions being first-class objects in JavaScript mean they can, among other things, be assigned to things and passed around just like other value types. Of course, being objects, when we do assign or pass them around, what we are actually passing is their reference.

This flexibility around functions creates plentiful variety in the manner in which they are applied and used. Let's see how the concepts we've covered so far come into play in some of these scenarios.

function loneGuy() {
  console.log(this)
}
loneGuy()  //  window object


let averageJoe = {
  name: "Joe",
  talk: loneGuy
}
averageJoe.talk()  //   {name: "Joe", talk: ƒ}


let anotherAverageJoe = {
  name: "Another Joe",
  speak: averageJoe.talk
}
anotherAverageJoe.speak()  //  {name: "Another Joe", speak: ƒ}


let anotherLoneGuy = anotherAverageJoe.speak
anotherLoneGuy()  //  window object


anotherLoneGuy.apply(averageJoe)  //  {name: "Joe", talk: ƒ}
averageJoe.talk.call(anotherAverageJoe)  //  {name: "Another Joe", speak: ƒ}

We begin by defining a function loneGuy that logs the current value of this within its function body:

function loneGuy() {
  console.log(this)
}

When invoked as an ordinary, standalone function, the window object is outputted as the value of this:

loneGuy()  //  window object

We go on to create an object that has a talk method that references the loneGuy function. When the talk method is invoked, its parent object, averageJoe now becomes the this value:

let averageJoe = {
  name: "Joe",
  talk: loneGuy
}
averageJoe.talk()  //   {name: "Joe", talk: ƒ}

We create another object anotherAverageJoe whose speak method is a reference to averageJoe.talk. The speak method is invoked via its parent object anotherAverageJoe, which is rightly outputted as the this value.

let anotherAverageJoe = {
  name: "Another Joe",
  speak: averageJoe.talk
}
anotherAverageJoe.speak()  //  {name: "Another Joe", speak: ƒ}

We create a new variable anotherLoneGuy and pass it a reference to anotherAverageJoe.speak. We go ahead to invoke it in a straightforward manner and sure enough, it gets the window object as its this value.

let anotherLoneGuy = anotherAverageJoe.speak
anotherLoneGuy()  //  window object

Next, we invoke the newly created anotherLoneGuy via the built-in apply method and explicitly provide averageJoe as its function context. Expectedly, it runs and logs averageJoe as its this value. We also invoke averageJoe.talk via the call method and provide anotherAverageJoe as its function context which it duly outputs as its this value, despite being a method in averageJoe.

anotherLoneGuy.apply(averageJoe)  //  {name: "Joe", talk: ƒ}
averageJoe.talk.call(anotherAverageJoe)  //  {name: "Another Joe", speak: ƒ}

From all the passing around and reassigning of our initial function, we can see that whilst where and how a function is defined may have a hand in how its this value is arrived at, how it eventually gets invoked is the most determining factor.

The curious case of arrow functions

Arrow functions came with ES6 and brought new elegance to how functions were wielded in JavaScript. They discarded some of the syntactic baggage of traditional functions and allowed functions to be expressed more succinctly and lucidly.

Arrow function expressions weren't just a syntactic retailoring of traditional functions though. They differed not only in syntax but slightly in behavior as well, one of which being how function context is determined. Arrow functions don’t have their own this value. Instead, they remember the value of the this parameter at the time of their definition.

Let's understand this by walking through some code.

function randomGuy() {
  function regularFunc() {
    console.log(this)
  }

  const arrowFunc = () => {
    console.log(this)
  }

  regularFunc()
  arrowFunc()
}
randomGuy()
//  regularFunc –> window object
//  arrowFunc –> window object


let averageJoe = {
  name: "Joe",
  talk: randomGuy
}
averageJoe.talk()
//  regularFunc –> window object
//  arrowFunc –> {name: "Joe", talk: ƒ}

To begin, we define a randomGuy function, inside of which we house two other functions—a normal function regularFunc and an arrow function expression arrowFunc—both of which log the value of this inside their respective bodies.

function randomGuy() {
  function regularFunc() {
    console.log(this)
  }

  const arrowFunc = () => {
    console.log(this)
  }

  regularFunc()
  arrowFunc()
}

We invoke randomGuy the straightforward way and its function context becomes the window object. The code executes beyond the function definitions and reaches the regularFunc invocation. It is also invoked in a straightforward fashion, thus, it gets the window object as its function context as well. Next, arrowFunc is invoked and as an arrow function that doesn't determine its own this value, it takes on the this value existing at the time it was defined, which was the window object.

randomGuy()
//  regularFunc –> window object
//  arrowFunc –> window object

It is vital to understand the nuance here. Even though both functions ended up with the window object as their respective this values, the reasons were different. For regularFunc it was because it was invoked in straightforward manner, while for arrowFunc it was because the window object was the existing this value at the time of its definition and that was what it stuck with.

We go on to define an object averageJoe which has a talk method that is a reference to randomGuy.

let averageJoe = {
  name: "Joe",
  talk: randomGuy
}

When the talk method is invoked, the this value within its body becomes its parent object averageJoe through which it was invoked. We go past the function definitions and once again, regularFunc gets invoked in straightforward fashion making the window object its this value. Next, arrowFunc is invoked, and being an arrow function, it remembers the this value that existed at the time it was defined (the averageJoe object) and inherits it as its own this value.

averageJoe.talk()
//  regularFunc –> window object
//  arrowFunc –> {name: "Joe", talk: ƒ}

Arrow functions get their function context from the existing function context at the time of their definition. They remember this context and stick faithfully to it no matter how they're invoked later on.

Arrow functions as callbacks

An area where the practicality of arrow functions comes to bear is in the use of callback functions. Traditional functions have always been quirky in this regard and prior to arrow functions, developers had to resort to workarounds when using them as callbacks in certain cases. Take a look at this code for example:

let averageJoe = {
  hobbies: ["reading", "coding", "blogging"],
  printHobby: function(hobby) {
    console.log(hobby)
  },
  printHobbies: function() {
    this.hobbies.forEach(function(hobby) {
      this.printHobby(hobby)
    })
  }
}
averageJoe.printHobbies()  //  Uncaught TypeError: this.printHobby is not a function

In this scenario, using a traditional function expression as our callback brought us nothing but heartbreak. When the anonymous callback function we passed to the forEach method gets invoked, it takes on the window object as its function context and which, of course, isn't where the printHobby method resides. Hence, the error we got.

However, when we make use of an arrow function instead, we see that it captures the prevailing this value at the time of its definition (the averageJoe object) and this, in turn, leads to the output we desire:

// ...

  printHobbies: function() {
    this.hobbies.forEach(hobby => {
      this.printHobby(hobby)
    })
  }
}
averageJoe.printHobbies()  //  "reading", "coding", "blogging"

Using arrow functions as methods

You should be a bit careful with arrow functions. Their characteristic of inheriting the this parameter leads to a quirk when we use them as methods.

Take this for example:

let averageJoe = {
  name: "Joe",
  talk: () => {
    console.log(this)
   }
}

averageJoe.talk()  //  window object

Within the talk method, this now references the window object as opposed to its parent object averageJoe. Crazy, right? Don't panic, I will explain.

It's actually quite simple. Arrow functions always sticking to the this value existing at the time of their definition means that they won't take their parent objects as their function context when they're invoked through them as methods. In this particular case, averageJoe is created in global JavaScript code (that is, not within a function) where the value of this is the window object and that is what the arrow function expression used for the talk method stuck with.

This same behavior of arrow functions leads to a different outcome when we come to constructor functions:

function AverageJoe() {
  this.name = "Joe"
  this.talk = () => {
      console.log(this)
    }
}

let averageJoe = new AverageJoe()
averageJoe.talk()  //  {name: "Joe", talk: ƒ}

As we know, invoking constructor functions with the new keyword leads to a new object instance being created and made the function context. So, in essence, the object that we are passing the arrow function to as a method is also the existing function context at the time it was defined and that is what it will stick to whenever it is invoked.

In fact, however it is invoked.

averageJoe.talk()  //  {name: "Joe", talk: ƒ}

let loneGuy = averageJoe.talk
loneGuy()  //  {name: "Joe", talk: ƒ}  not window object

averageJoe.talk.call(window)  //  {name: "Joe", talk: ƒ}  still not window object

let anotherLoneGuy = averageJoe.talk.bind(window)
anotherLoneGuy()  //  {name: "Joe", talk: ƒ}  lol, still not window object

On a quick note, you shouldn't use arrow functions as methods as they aren't fit for that purpose. This was only for demonstration purposes.

Conclusion

We've covered ample ground on this topic. We started off by getting to know what this was. We looked at functions, the variety of ways they are invoked, and how they affect how this is determined. We also took a good look at arrow functions and their interesting peculiarities.

Hopefully, this article has done enough to demystify and help you understand the this parameter once and for all. Thanks for reading!

All of these packages live in a centralized repository known as the NPM Registry and are the handiwork of developers scattered around the globe. This article aims to show you the ropes on how to go about creating and publishing your own NPM package.

What are we going to make?

Programmers that work with frontend libraries like React know that directly modifying the values in a component's state object is a no-go area. This often means that developers have to, first of all, make a copy of whatever value they need from the state into new a variable before it can be used for anything. For arrays and objects, this can be more tricky as JavaScript objects are copied by reference and so, arrays and objects have to be copied more carefully to avoid passing reference to the same state property inadvertently. And with components' state objects usually having properties consisting of nested objects and arrays, trying to decouple and safely copy them from the state quickly becomes a task.

Well, developers can now breathe a sigh of relief! What we're going to be creating is an NPM library that allows us to make perfect clones of objects and arrays effortlessly.

Setting up an NPM Registry account

To sign up for an account, click here

1) Click the "Sign Up" button

2) Fill all the fields and click on "Create an Account" (you'd receive an email shortly after). Take note of the credentials you entered as you'd be needing it soon.

3) After receiving the email confirming your newly created account, login to the NPM Registry from your terminal:

npm login

You will be prompted for your username, password and email.

Writing the code

Create a new folder object-cloner in your IDE. Inside it, create a new file index.js and write out this clone function:

function clone(item) {
// Clones an array or object using
// the spread syntax

  return Array.isArray(item) ? [...item] : { ...item };
}

Now, to test that the code is working properly, we're going to add these lines of code to index.js:

let arr = [1, 2, 3];
let arrClone = clone(arr);
arrClone.shift();
console.log("- arr", arr);  // - arr [1, 2, 3]  Original array is unaffected
console.log("- arrClone", arrClone);  //  - arrClone [2, 3]

Next, run the code from your terminal:

node index.js

This should be the output you get:

Seeing as our function works fine, let's remove the last set of lines we added and go ahead to export the clone function with a module.exports statement. Your index.js file should now look like this:

function clone(item) {
// Clones an array or object using
// the spread syntax

  return Array.isArray(item) ? [...item] : { ...item };
}

module.exports = clone;

Whatever you export from index.js is what will be available for importing when the library is installed in a project.

Alright, let's go ahead and publish what we've built.

Package.json

Well, not just yet. Every NPM package requires a package.json file—you can't publish without it. Create a package.json file initialized with the defaults by running this in the package root directory:

npm init -y

The newly created package.json file should contain something like this:

{
  "name": "object-cloner",
  "version": "1.0.0",
  "description": "",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": [],
  "author": "",
  "license": "ISC"
}

Okay, let's take a moment to take note of somethings. Firstly, there's the "name" field which represents the name of the package. It has to be lowercase and MUST be unique; it can't bear the same name as an existing NPM package. You can go to the homepage of the NPM Registry and search to see if there's something by that name already.

If you do want a particular name for your package which happens to be taken already, you could make it a scoped package instead. Scoped packages come in the form @username/package-name, where a package name is prefixed with an NPM account followed by a slash. You should change the package name in your package.json file to something else ("object-cloner" is already taken by yours faithfully) or to this instead:

{
  "name": "@your-username/object-cloner"
}

There's the "version" field as well which, together with the "name" field, make up the two most crucial things in the package.json file. Changes to a published package should be accompanied with changes to the "version" field. NPM follows a versioning system called SemVer, which is short for Semantic Versioning.

The summary of the gist is:

Given a version number MAJOR.MINOR.PATCH, increment the:

1. MAJOR version when you make incompatible API changes,
2. MINOR version when you add functionality in a backwards compatible manner, and

3. PATCH version when you make backwards compatible bug fixes.

   (https://semver.org)

The "description" field is where we include a succinct description of our package. Also, there is the "main" field which denotes the entry point to our package, which is index.js in our case. The "keywords" field is an array of strings which will be the keywords that are associated with our package and helps people discover it. Lastly, there is the "author" field and this is where we put our name, email and website.

After filling the fields, you should have something like this:

{
  "name": "object-cloner",  // "@your-username/object-cloner"
  "version": "1.0.0",
  "description": "A simple utility library for cloning objects and arrays",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "keywords": ["clone", "objects", "arrays"],
  "author": "eedris <alabialade@gmail.com> (https://twitter.com/eedrxs) ",
  "license": "ISC"
}

Publishing

Alright, we can now publish. In your terminal, run:

npm publish

If all goes well, you should see something like this:

npm notice 
npm notice 📦  object-cloner@1.0.0
npm notice === Tarball Contents === 
npm notice 176B index.js    
npm notice 365B package.json
npm notice === Tarball Details ===
npm notice name:          object-cloner
npm notice version:       1.0.0
npm notice filename:      object-cloner-1.0.0.tgz
npm notice package size:  459 B
npm notice unpacked size: 541 B
npm notice shasum:        e5fdba39cf9ec463a4ec777b9247fd55ce19d3c5
npm notice integrity:     sha512-Pv6n04FnBOd+k[...]V/APMfXSQhaEA==
npm notice total files:   2
npm notice
+ object-cloner@1.0.0

Now, that wasn't so hard, was it? 😎

NOTE: If you decided to publish your package as a scoped package, running npm publish will fail and give you an error like this:

npm ERR! code E402
npm ERR! 402 Payment Required - PUT https:// registry.npmjs.org/@eedris%2fobject-cloner - You must sign up for private packages

Why is this so? Well, this is because scoped packages are published privately by default as they are also used by companies (or individuals) to create packages that are used internally. To go around this, we simply have to let NPM know that we are magnanimous people and actually want our scoped package to be available publicly. To do that, we run:

npm publish --access=public

Installing and using the package

Now that we've published our package, let's put it to work. Open up a new folder in your IDE and install the package from your terminal:

npm install object-cloner

Next, create an index.js file and fill it with these lines of code:

import clone from "object-cloner";

let obj = { name: "eedris", id: 123 };
let objClone = clone(obj);
delete objClone.id;
console.log("- obj", obj);
console.log("- objClone", objClone);

NOTE: You may need to include the "type" field in your package.json and set it to "module" to be able to use the import syntax in your code. Check to see if it is already set; if it isn't add it to your package.json:

"type": "module"

Running node index.js in your terminal should give you this output:

We really should give ourselves a pat on the back at this point. We've published, installed and also made use of our package in our code.

Making changes

If you have a sharp eye, chances are that you'd have noticed an issue with our clone function. Whilst it does create clones of objects or arrays, the cloning only goes one level deep.

import clone from "object-cloner";

let obj = { tutor: { name: "eedris", id: 123 } };
let objClone = clone(obj);
delete objClone.tutor.id;
console.log("- obj", obj); // - obj { tutor: { name: 'eedris' } }  😨

As you can see, removing the tutor.id property from objClone also removed it from obj. Since our clone function only goes one level deep, nested objects or arrays beyond the first level still get passed as references and not as fresh copies.

To rectify this, we're going to rewrite our clone function to not only clone, but to deep-clone.

function deepClone(item) {  // renamed to "deepClone"
  //  Deeply clones an object or array

  return JSON.parse(JSON.stringify(item));
}

Remember from earlier that each update to a package has to be accompanied with a change to its version. So, we have to determine the kind of change we made to the package and increment the package's version in a manner that reflects that change and goes in line with the SemVer system. To do that, we make use of the command:

npm version <update_type>

where "update_type" can be either major, minor or patch

We reworked our cloning logic. More pertinently, we renamed the function name and this sort of change makes this new version of our package backward-incompatible. A project that was written using the earlier version of our package will spit out errors if we tried to make use of this new version with it as our package no longer exports the clone function that it relies on. This calls for a major update, so run:

npm version major

Running this takes the "version" field in our package.json file to 2.0.0. To publish the update, run:

npm publish

Drum roll... 🥁🥁

npm notice 
npm notice 📦  object-cloner@2.0.0
npm notice === Tarball Contents === 
npm notice 256B index.js    
npm notice 365B package.json
npm notice === Tarball Details ===
npm notice name:          object-cloner
npm notice version:       2.0.0
npm notice filename:      object-cloner-2.0.0.tgz
npm notice package size:  504 B
npm notice unpacked size: 621 B
npm notice shasum:        1bb417d5d2cc87aeb1789dbca8b08e1d79af5d37
npm notice integrity:     sha512-/XtyouHWgotLv[...]acqQN1WAZC+9A==
npm notice total files:   2
npm notice
+ object-cloner@2.0.0

Our package is successfully updated! 🥳🎉

Conclusion

We've been able to create and publish an NPM package, as well as make updates to it. We were also able to install it and put it to use.

It is recommended you include a README.md markdown file in your package root directory to describe what it's about and also give examples of how to use it. I added a README.md to my package and this is how it now looks on the NPM Registry:

Our package is tiny and definitely not the most sophisticated. However, the primary focus here was about illustrating the process, and not so much about the product itself. NPM packages can be much more grand and more often than not, involve the use of other NPM packages as well. It all depends on the problems you're trying to solve or the functionalities you want to provide.

With all we've done, you should now know all you need to know to start creating your own NPM packages. Thanks for reading!

After you finish building a project, you'd usually want to take it out of your localhost and put it somewhere else where you or others can access it as well. The next point of call would be to deploy the project to any of the several cloud hosting platforms available.

Some of these hosting platforms even give you free hosting and if you are like virtually every other developer, chances are that's what you'd be opting for. Of course, what you get is a subdomain and limited resources—but that is often more than enough for most stuff you'd be building. You're usually able to set the subdomain name from which your project will be accessed at the point of deployment. But, as it happens sometimes, your preferred subdomain may already be taken (or maybe you're just in a hurry) and you may opt for an auto-generated subdomain name which you can change later on if you wish.

However, after coming across several sizable projects (and even a personal portfolio site!) with auto-generated subdomains of the "notorious-badlands-47642.hostingplatform.app" kind, it became clear to me many either don't know they can customize their projects' subdomain names or just don't know how to. And that was why I set out to write this article. Picking three among the top cloud hosting platforms used by developers, I'd be showing you how to do just that.

Vercel

1) Log in and click on the project whose subdomain name you want to change

2) After it opens up, go to the settings page and click on "Domains"

3) Click on the "Edit" button on the particular domain you want to change

4) Edit it and click on "Save" after you are done

5) That's it! Your new Vercel subdomain is ready.

Heroku

1) Log in and click on the project whose subdomain name you wish to change

2) After it opens up, click on "Settings"

3) Change the text in the "App name" input field to your preferred subdomain name and click on "Save"

4) Done and dusted! Your new Heroku subdomain name is set.

Netlify

1) Log in and click on the project whose subdomain name you want to change

2) After it opens up, click on "Domain settings"

3) Under "Custom domains", click on "Options", then on "Edit site name"

4) Input your preferred subdomain name and click on "Save"

5) Just like that—you've got a new Netlify subdomain name!

Conclusion

Whatever it is you're building, presentation is always essential. Whether your side project or your portfolio site, the domain name is the first point of contact for all who will behold whatever you've built. Random strings spat out by an algorithm do not make for a presentable domain name.

Hopefully, with all the info in this article, your "notorious-badlands-47642" days are over! 😉