DEV Community

Module pattern in JavaScript

Tomek Buszewski on February 26, 2019

A module is a construct somewhat similar to a singleton class. It has only one instance and exposes its members, but it doesn’t have any kind of in...
Collapse
 
bayazz profile image
Bayazz

You said with Formatter.timesRun = 10; We access timesRun variable and change it. But actually when we call makeUpperCase method we see that timesRun is still 0 and it doesn't change. Could you please explain this strange behavior?

Collapse
 
tomekbuszewski profile image
Tomek Buszewski

Hi Bayazz!

Can you reproduce the problem or show the code? I did run the one from example on codesandbox and it seems fine.

Collapse
 
bayazz profile image
Bayazz • Edited

Hi Tomek,
thanks for the reply.

If we add console.log(timesRun);in the setTimesRun method right after ++timesRun; we can see in the console that timesRun is not 10. But with Formatter.timesRun it's 10.

codesandbox.io/s/lingering-sound-g...

Collapse
 
bayazz profile image
Bayazz

Any ideas? Im still struggling to understand it.
Thanks

Thread Thread
 
tomekbuszewski profile image
Tomek Buszewski • Edited

Hi, sorry for replying late, I've seen this before (I guess I didn't try it), but I'll try to come up with something in the upcoming days ;)

-- edit

In the meantime (and actually all the time) you should have explicit functions modifying such values. Take a look here: codesandbox.io/s/busy-field-2yf01

Thread Thread
 
bayazz profile image
Bayazz

I actually wanted to understand why it's like this.
Anyway thanks for the reply:)

Thread Thread
 
hilver profile image
Paweł Pęczkowski • Edited

When you do Formatter.timesRun = 10; you don't assign this value to the variable, but to the property of Formatter. You don't have directly access to variables in module pattern. Look here.

I hope this is more clear now :)

Thread Thread
 
tomekbuszewski profile image
Tomek Buszewski

Hey, I've totally forgot about this. Well, this is what you are getting when you are old :D

Thread Thread
 
bayazz profile image
Bayazz

Yeah it happens:)
Thanks, it's clear now:)

Thread Thread
 
hrexandro profile image
Hrexandro

I'm still confused, why is the property different from the variable? Where is it stored if the variable is not used and why does incrementing the property does not increment the variable?

Thread Thread
 
muewwy profile image
Muewwy

I'm only learning, so take this all with a grain of salt, but I was confused here to and this is what helped increment my understand of this error forward: The variable itself isn't returned because "return { timesRun }" is actually object property: value shorthand for "return { timesRun: timesRun }", so it is only creating the property to be stored in Formatter and setting the initial value, which is only set the first time Formatter is created. If you want to get a counter accessible from outside the function you can either:
a) create a function that gets and returns the current private value, because a function declared within the same scope of the private value will retain access to it when called from outside
b) make the property Formatter.timesRun a getter for timesRun, also declared within the same scope, or
c) use the property itself as the counter within the function.

Collapse
 
chengmo profile image
Cheng_Mo_

I think this behaviour because it's called Immediately Invoked Function Expression ... As a result it returned the property Immediately when it was equal to 0 before any calling for the public methods and any changes wouldn't affect the returned property unless you change it directly by Formatter.timesRun = ## .... That's my thought about this matter correct me if I'm wrong, I'm just a fellow learner just like you not an expert or something... Hope it helps!

Collapse
 
m0xai profile image
m0xai

A little thing:
Before running the code in Exposing a Module, you deleted the line " console.log("Start");" i mean, we can't see this console.log just before invoking the function. But in output you added it in first line.

Collapse
 
taf profile image
taff

great explanation. I don't know if this is obsolete anymore but I'm learning one at a time. thank you.

Collapse
 
hareom284 profile image
Harry • Edited

Thank man this article

Collapse
 
lizsafina profile image
LizSafina

Hey, great article. Thank you!
Just one thing:
I even removed the check inside makeUppercase, because it’s not needed anymore
Did you mean "you removed the check inside 'writeToDom'?"

Collapse
 
guico33 profile image
guico33

Now we have actual modules with esm or even commonjs, what's the point of creating modules using an IIFE?
To me it sounds like a pattern which should disappear in favor of more modern practices.

Collapse
 
tomekbuszewski profile image
Tomek Buszewski

Hi Guico,
You are right about the new modular approaches, I just might be a little late to the party with this article ;)

Nevertheless, I still find IIFE often in codebases I work with while doing consulting or audit stuff. And I don't think those are for refactor (even though it would be quite painless), as such modules are valid and fully functional parts of an application.

Collapse
 
axterix profile image
Axterix

Thanks for your post, clear a nice explained.... was very usefull and informative.