JavaScript Module Pattern (Part 2): Default Module Functionality & Object De-structuring

romverner

Roman Verner

Posted on August 4, 2020

JavaScript Module Pattern (Part 2): Default Module Functionality & Object De-structuring

I mentioned in a previous post that I've been trying to implement the module pattern to our front-end javascript code at work. And I'm happy to report that so far it's going well. I've made a few discoveries that I thought I'd share!

Default Module Functionality

When I first started learning about the module pattern -- and IIFE's in general -- I never considered the idea of adding default functionality to the newly created modules. In hindsight, now I realize that actually would have been quite useful! If you have a web app that contains many smaller apps within it, it can be tough to bring on new developers if you're not using a framework. Why? Because each app may be coded in an entirely different style -- one issue among many. Remember, one of the main reasons for introducing the module pattern is to begin to standardize.

Anyway, let's get to the code. Let's imagine we have a standard MAIN module from which all other modules will be created. Here, it's written in two different ways to show what's possible:

As you can see, in the first IIFE -- MAIN -- we store our modules in an object and then just point to it in the return object of the MAIN IIFE. In the second IIFE -- MAIN2 --, we actually create a reference to another IIFE in our return object. I prefer the object references of the first method for the sake of simplicity, but the second method allows anonymously scoped functionality to be added to all of our new modules!

Let's now take a look:

As you can see, both methods offer ways to provide default functionality; however, the second method allows us to take that default functionality to a whole new level. By modifying our _createModule function in MAIN2 and adding a second parameter for a file path, we are now opening up the possibility to load module settings as soon as the createModule function is run! No interaction outside of supplying the two parameters to _createModule required! While I still prefer the simplicity of the first method, the second method now allows us to further begin introducing a whole new set of coding standards that will unify our apps from a developers prospective. On top of this, the anonymous scoping and immediately invoked nature of IIFE's has also allowed us to start developing our very own little framework!

let me pat myself on the back

Now, bear with me, I only made these discoveries today, so I won't go into any further details until I've had some time to mess around with these concepts. In the meantime, here is one final applied example using a pretend app for Wahoo to help visualize how this organizes your code:

What are your thoughts? I may be biased, but I think that looks neat and tidy!

Object Destructuring Saves Time

Having the ability to add default settings to your modules aside, here's another small tidbit I'd like to share. Remember to de-structure your nested objects for easier access! Given that everything in your modules is in an object, you can just pick and pull what you need.

Anyway, that's all I have to share for now. Hope you found this useful!

💖 💪 🙅 🚩
romverner
Roman Verner

Posted on August 4, 2020

Join Our Newsletter. No Spam, Only the good stuff.

Sign up to receive the latest update from our blog.

Related