JavaScript Module Pattern (Part 2): Default Module Functionality & Object De-structuring
Tags: javascript, webdev, todayilearned, todayisearched
Published: 2020-08-04 22:30:18

I mentioned in a [previous post](https://dev.to/romverner/the-javascript-module-pattern-what-is-it-why-is-it-useful-18g5) 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:

{% gist https://gist.github.com/romverner/94aeb68a57c0759acfd754cf68b431cd %}

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:

{% gist https://gist.github.com/romverner/f6731f35defcc019b00fa378036be7d2 %}

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](https://media.giphy.com/media/mn1cym1jiJOUg/giphy.gif)

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:

{% gist https://gist.github.com/romverner/528fe82f445a29ba0fe81963369be3f7 %}

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.

{% gist https://gist.github.com/romverner/73e9ecb2e4e6eeb614312df14659d7f5 %}

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