Recently had a question asked regarding the right way to export an object in node. Consider the following code
class Foo {
constructor() {
this.foo = 'foo'
}
}
module.exports = function() {
return new Foo()
}
We have a class that exports a function which returns a shiny new Foo object.
Great! Then someone asks. Why bother wrapping it in a function when you can just return the object? Let’s see.
class Foo {
constructor() {
this.foo = 'foo'
}
}
module.exports = new Foo()
Basically the same thing right? Not so fast! Yes, the function is gone and now it is returning that shiny new Foo object directly. However this second version will only create one Foo object. You can require the module anywhere in your code and it will always return the same Foo object.
Take a look at this REPL (Read-Eval-Print-Loop)
> foo=require('./foo')()
Foo { foo: 'foo' }
> foo.foo='bar'
'bar'
> bar=require('./foo')()
Foo { foo: 'foo' }
> foo
Foo { foo: 'bar' }
As you can see above this is the foo module from our first example. You can tell by the trailing parens () on the require statement. That is executing the function that is exported by the module.
We assigned the Foo object to a variable named foo. You can see that the property ‘foo’ of object foo is set to a string with the value ‘foo’.
Next we set the property foo to a string ‘bar’ and then we require foo again. This time we assign it the variable bar and we see that it is in fact a brand new Foo object because bar.foo equals ‘foo’ but foo.foo equals ‘bar’
(wishing I’d used different variables at this point, oh well too late for that now) Still with me? Great!
So everything looks good… well, that is if you want a brand new Foo every time you require the module, but what about that second example. Let’s have a look.
> foo=require('./foo')
Foo { foo: 'foo' }
> bar=require('./foo')
Foo { foo: 'foo' }
> bar.foo='bar'
'bar'
> foo
Foo { foo: 'bar' }
> baz=require('./foo')
Foo { foo: 'bar' }
Here we require the same foo module twice assign it once to foo and once to bar. They are both the same, as you would expect however this time when we set bar.foo to the string value ‘bar’ we can actually see that we only have a single object because when we check our foo object the foo property is now a string with the value ‘bar’.
Just to make the point extra clear we require foo a third time and assign it to baz. Again you see that baz.foo equals ‘bar’.
This is what is known as a Singleton, the module only creates one object the first time it is used and then it hands that same object out every time it is required again.
This is a very important concept to understand and remember. One way isn’t better than another. The method you choose depends on what you are trying to accomplish. For example if you have a logging module that you want to configure once but use everywhere then you’ll want to use the second example but if you’re creating a catalog of items each with their own distinct properties you’ll want to stick with the first example.