Module Pattern variations

Hi all,

I’m currently reading Learning JavaScript Design Patterns and I’d just like to get some clarity on a couple of points.

Addy references two variations to the Module pattern:

Import Mixins
It states that globals can be passed in as arguments to the module’s anonymous function, but if they are already in the global scope why do they need to be passed into the function? Can they not already be accessed inside the function without being passed in?

Am I ccrrect in saying that the only variation to the original pattern is that the module object and it’s propeties/methods are created privately, and then returned by the anonymous function? Effectively, exporting (some of) our private scope.

Thanks in advance for your help! :slight_smile:

Oh, I’ve wanted to read that – how is it? I have a dozen books I can’t get to. Programming gets in the way!

On 1), I don’t know specifically. But this approach facilitates “dependency injection” whereby you can pass in whatever you want without the module knowing about the outside lexical scope. This is great for unit testing, for example, and aids in decoupling. But that’s just my observation on this…

On 2), that sounds correct.

In truth, I rather enjoy the module pattern and I haven’t written any objects since the middle of the front-end track nor used the function constructor pattern. It’s needless in JavaScript.

1 Like

Thank you for your response @jboxman, I think I understand the idea behind Import Mixins now.

As I’m still a novice at this stage, I have a lot of time to read and study! I’ve really enjoyed it so far, I think it’s written in such a way that suits any JavaScript programmer, regardless of their expertise. Certainly worth a read, should you find the time.

I wanted to research design patterns as I understand that a lot of newbie developers focus quite heavily on syntax before understanding the fundamentals of programming. Feels like there is an awful lot to learn, but I’m enjoying the challenge! :smiley: