A common approach
A common approach when utilizing the module pattern or something close to it, is to attach the end object to the
window, or return the object inside some sort of local variable to create a namespace for your module.
So you might end up having something like this:
Of course, the obvious problems with this are:
- You attach a lot of stuff to the global scope (this can be overcome with various techniques, though)
- You have to get the order of your
<script>tags pretty exact (we’re pretending we’re not using a task runner here, like gulp)
… and probably several other I’m forgetting about. There are other ways to do this (a popular library like RequireJS, for example), but in my case, I wanted to try to use a basic object that would be attached to the
window, and have all of my dependencies attach to that global object.
A global dependencies object
For angular-state-manager, I utilized a global object called
stateManagerDependencies, or something along that line, to attach all of my modules to that would eventually go into the main
The purpose of this was to only have one object (the
stateManagerDependencies object) be attached to the global scope (i.e.
window object), and that would hold all of the dependencies, as opposed to attaching each dependency to the global scope at the end of each module.
Obvious downsides to this approach
- You’re still attaching some strangely named global object to the
- In each module that depends on the
dependenciesobject, there is no error-checking or method to list what modules are available inside the
dependenciesobject (a possible fix for this is to simply implement some of those methods, for example: