Which way is better to pass function in javascript?

Question

If I have 3 js files as follow:

file1.js

this.functionName = function(params) { //do something};

file2.js

function fucntionName(params) { 
     //do something
};

module.exports = {
     functionName
};

Then in the third js file, I can require an object of the two files and make calls to the two functions defined in them; so for example if I call them in index.js

let file1 = require('/file1');
let file2 = require('/file2');

file1.functionName('some param');
file2.functionName('some param');

What are the difference between the two and which is preferred?

score 1 · Answer 1 · answered Sep 23 '16 at 18:08

If you are using ES6 with Babel, it is a lot cleaner to use the export syntax. That is, if you want to reference the function directly, like this:

const fName = function(){
  /* do stuff here */
}
export default fName;

Or if you want to export multiple functions without having to manually assign them in module.exports, you can do this:

export const fName2 = function(){ /* do stuff */ }

So then you can import the first directly, and the 2nd through destructuring:

import fName from './file1';
import { fName2 } from './file2';

Hope this was helpful

score 0 · Accepted Answer · edited May 23 '17 at 12:15

The first one-ish

As quoted from this post:

In the top-level code in a Node module, "this" is equivalent to module.exports.

Therefore the 2 may seem equivalent. But, they're not - in your second example, you are changing the object referenced by "module.exports". This is dangerous since any prior modifications that you have made to the original object previously referenced by "module.exports" within the same module (thanks Kevin for letting me know this wasn't clear) will no longer be available when requiring. In the future, should someone want to add a function using the other method, and make it available before your re-assignment, they might find themselves unable to access it while having some correct looking code.

Also - by allowing yourself to believe the 2nd method has the same effect, you may be tempted to do something like:

module.exports = {
     functionName1
};
// code, code, code
module.exports = {
     functionName2
};

Which will obviously strip you of acces to the original functionName1 method.

Of course, you may add both of the functions to the new object at the same time but what if they're just not available in your scope (e.g. they've been definied inside another function)? You'll still have to use the 1st method anyway at the time when the function is available.

Both methods obviously work. I am recommending the 1st one since to me it's both the clearer and less error prone.

However

Since this is context dependent, drop it all together and stick to module.exports. You'll end up with something like:

module.exports.functionName = function(params) { 
    //do something
};

or

function mySimpleFunction(params){
    //do something
}
module.exports.functionName = mySimpleFunction;

(in case your concern was with associating the declared function)

Are you saying modifying `module.exports` such as in the second example could affect other unrelated modules being pulled in with `require`? that's what it sounds like you're saying... if not, and you mean just within that module, then yeah i guess that could happen, but... that's like saying don't use variables because you might accidentally reuse them. — Kevin B, Sep 23 '16 at 18:11
No, i'm saying it will affect access to methods made available in the same module on the "module.exports" object but prior to his reassignment. It's not like saying "don't use variables since you might reuse them" since the underlying issue here is not that "module.exports" is modified, but that the object returned to the requiring module is changed. If i were to add my own function to "module.exports", i would expect it to be available when the module is required. — Alex A, Sep 23 '16 at 18:15
... uhm. yeah then that's like saying don't use variables because you might forget and reuse them. — Kevin B, Sep 23 '16 at 18:15
... uhm. no then that's like saying don't give yourself unnecessary headaches because half a year ago you decided replacing the referenced object would be a smart idea. — Alex A, Sep 23 '16 at 18:40

Which way is better to pass function in javascript?

2 Answers2