JavaScript Revealing Module Pattern

javascript revealing module pattern

Now that we have a good understanding of closure, the prototype pattern, and the module pattern, let us now take a look at the JavaScript Revealing Module Pattern. You know it’s funny, we have all this verbiage to describe these patterns, and you might be scratching your head as to what a module pattern vs a revealing module pattern is. To be fair, the revealing module pattern is very similar to the module pattern, but it has a really nice way of exposing the api of a module to it’s users or consumers. I think you’ll find the revealing module pattern to be a really good balance of how to structure your JavaScript code for readability.

What does the revealing module pattern provide us?

The revealing module pattern is really almost the same as the module pattern. The major difference to be aware of is simply how the revealing module pattern exposes it’s api. In other words, what is contained in the return statement of the revealing module pattern is different than what is in the module pattern. In terms of what the revealing module pattern offers us, it is the same three things that we have been discussing in our study of patterns in JavaScript such as code reuse, ease of maintenance, and less use of the global scope. Just like we saw with the module pattern, the revealing module pattern also allows developers to emulate the concepts of public and private variables and functions. Like we said, the return statement differs between the two patterns, any many find the revealing module pattern easier to read and reason about. Recall that with the module pattern, we return an object literal. That object literal is exposing it’s api, or it’s methods, by defining their structure right inside that very object literal that is being returned. To me, this feels a bit clunky and not very friendly. With the revealing module pattern, you can define your variables and methods right up in the area we normally consider private (Section 2 of a module pattern). Then, you still return an object, but that object will have simple key/value pair references to anything you want to make public to a consumer of the module.

Has the same drawbacks of the module pattern

The revealing module pattern is not perfect, in fact it shares the same drawbacks as is found with the module pattern. Just like the module pattern, any functions that are defined inside of the module container will be duplicated in memory every time you create a new instance of the module. To be fair, this is probably not that big of a deal anyway. As getify so eloquently states in his You Don’t Know JavaScript series, the optimization engine in JavaScript can handle this with no problems. In addition, you probably would never notice performance problems until you start hitting thousands or hundreds of thousands of instances of a module on a page. When is the last time you ran into a situation like that? Right, never.

General Revealing Module Pattern Structure

This little outline we have above is an example structure of the revealing module pattern. At first glance, it does indeed look quite similar to the module pattern that we already had a look at. Can you spot what is different? Well first off, the name of the module is in lowercase. This is not an actual requirement, but it is a good idea from a conventions standpoint, as it gives an indication that the new keyword is not required with the revealing module pattern. The reason no new keyword is required is because of those two little parenthesis after the function declaration. This means it is a self-calling function. The biggest difference between the module pattern and the revealing module pattern however is in fact in the return statement. Recall that in the module pattern, we defined our public functions right in the returned object literal. With the revealing module pattern, there is no need to do this! You can simply define all of your variables and functions in one place, then for any of those that you want to make public, you simply give them an alias in an object literal and return that instead. Let’s go ahead and refactor one of our prior examples to make use of the revealing module pattern.

The Revealing Module Pattern in Action

Click Clear

Note the lowercase module name, and the immediate parenthesis after the function which makes it self invoking. This approach creates a singleton which is one single object in memory. Note that when we are calling methods in this case, we are calling them right on that singleton instance. For example tesla.gofast() instead of separate instances like model3.gofast() and roadster.gofast(). You may find this more limiting than when we were able to create new instances at will when we provided a demo of the module pattern. Fear not!

Use new with the Revealing Module Pattern if you like!

You can still make use of the new keyword with the revealing module pattern if you like. Simply leave off the immediately invoking () parenthesis after the module declaration, change the module name to lowercase (optional), then new up at will. Let’s test that approach out now.

Click Clear

Once again, this is working like a champ! I find this approach to be the best of both worlds. We get the benefits of the module container, an easier to read api, and the ability to new up as many instances as we like. Note that in the object literal, the name of they key of each key/value pair, is the name of the exposed member. In our example here we simply returned a one to one mapping of alias to name for the public members. This is a nice pattern since it avoids confusion. If you wanted to name your function one thing on the inside of the module, and expose it publicly as another name to external callers, you can do that as well. In our example we have a gofast() function and that is how we call it on our instances. What if you wanted to have people call that function using blastoff instead of gofast? Simple. Change the return statement in the module like so.

With that one small change, you can now call code such as model3.blastoff() and roadster.blastoff(), and behind the scenes, it is actually the gofast() function providing the implementation for you. It is a simple method of creating aliases for the functions you want to make public. Name them however you like, as long as they make sense to you.

JavaScript Revealing Module Pattern Summary

As we wrap up this tutorial, we have found that the revealing module pattern gives us a nice way to encapsulate variables and functions into a reusable object. We also saw the nice benefit of being able to declare all of your variables and functions in one area, then simply return an object that contains aliases for which you would like to call your functions by. It’s quite similar to the module pattern itself, however you might like the revealing module pattern better for it’s easier to read format. Like other software patterns, it helps us to ease maintenance, foster code reuse, and minimize naming collisions in the global namespace.