Modules. That’s a cool word. Ain’t it?

If you’ve talked to me at any point about my javascript in the past few months, I get really excited when I say that my proficiency in the language has increased dramatically since I started working a full time job only six months ago.

In my eyes, javascript is incredibly powerful, even when you don’t necessarily follow all of the best practices. Though if you take that leap and you put forth the effort, your code becomes staggeringly clean, cohesive, and easier to maintain.

Again, with my job, I’ve had the chance to have my code put through the rigors of code review, and as a result I’ve picked up a lot of cool things. One of these cool things I’d like to share is the concept of a module. Modules are made in javascript by what is known as an “immediately invoked function expression” (IIFE), which is a function that actually simulates public and private variables.

Yes, that’s right. When you’re dealing with Javascript, there’s really no such thing as a private variable. However, we can absolutely simulate that with a module. Let’s look at some code!

var thisModule = (function() {
    var myName = "Bradley";
    var myJob = "Web Developer"
    var myFavoriteColor = "Green"

    function reportName() {
      return myName;
    }

    function reportJob() {
      return myJob;
    }

    function reportColor() {
      return myFavoriteColor;
    }

    function reportAll() {
      return "My Name is " + reportName() + " and I work as a " + reportJob() + " and my favorite color is " + reportColor();
    }
  })();

Now if you remember anything about my last post, I talked about namespacing! A module is just a more involved namespace, it includes variables local only to the scope of that module (meaning sibling or parent objects can’t access those variables) as well as functions that can be made available or unavailable as you see fit.

Now, as it stands, our code won’t actually be able to be used. Even in accessing the module by namespace with thisModule.reportJob(); will do nothing.

This is because the IIFE isn’t returning anything. So when the function runs, everything ‘exists’ (at least until garbage collection picks it up). The variable becomes just a useless member of the window object.

In order to make this work, we need to return an object containing references to these variables and functions:

return {
  reportName: reportName,
  reportJob: reportJob,
  reportColor: reportColor,
  reportAll: reportAll
}

Each of the keys in this object is the key by which we’ll refer to the function or variable we want. If we wanted to print out my favorite color, we would call thisModule.reportColor().

You’ll also notice that the variables declared aren’t accessible to code outside of the module. This is the beauty of modules, it allows us to simulate private variables! If you want to expose it, place it in the return object! Otherwise it can be left in the function in which it’s declared

This is an interesting way to keep your code lowly coupled and allows you to separate concerns even further than simple namespacing. You could create a module for UI behavior and another module for shopping cart behavior on a website, for example.

Using modules is a nice way to make your code look a lot cleaner and feel a lot more like “big kid” javascript. There’s a book on this very topic that inspired this post And here’s my favorite module from that book!

Happy coding!