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!
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!
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!