Home > Blockchain >  Undertanding JavaScript methods
Undertanding JavaScript methods

Time:10-02

I am pretty new to JavaScript, coming from a Java background. I was just playing around with the NodeJS ("type": "module") Express framework but got between two types of ways for writing the methods in JS.

Below are the examples (check comments inline).

Type 1:

main.js

const method1 = () => {
    ...
    method2();
    ...
};

const method2 = () => {
    // this is not exported, so it works as a private method and won't be accessible in other JS files
    ...
};

.
.
.
// likewise there can be many other methods here

export { method1 }; // export other methods as well

Then, I can use the method1 (cannot use method2 as it is not exported) in any other JS file like below:

test.js

import { method1 } from './main.js';

method1();

Type 2:

main.js

class Main {
    
    method1() {
        ...
        method2();
        ...
    }

    #method2() {
        // this is a private method, so won't be accessible outside of this class
        ...
    }

    // likewise other methods here
}

const main = new Main();

export default main;

Then, I can use this class instance in any other JS file like below:

test.js

import main from './main.js';

main.method1();

I want to know what is the difference between these two, when to use which, and which is better.

CodePudding user response:

Both approaches work fine, but Type 2 is somewhat weird because you're using a class only to keep something from being exported.

Classes are usually used to group together data (properties on the instance of the class) with methods that operate on that data. For a silly example:

class NumberMultiplier {
  constructor(num) {
    this.num = num;
  }
  multiply(mult) {
    return this.num * mult;
  }
}
const n = new NumberMultiplier(5);
console.log(n.multiply(10));

Above, there is data (this.num), and there's also a method that operates on the data (multiply).

But in your case, you don't look to have instance data - you only want to group functions together, there's not really a reason to use a class. You can consider defining the functions individually - as you did in the first snippet - or you could use a plain object that gets exported, with only the properties you need:

const method2 = () => {
};
export default {
  method1() {
    method2();
  }
};

If you do have persistent data and want to put it on the class instance, using a class and # private methods is a possibility (creating a single instance with new and then exporting that instance is an example of a singleton).

A potential issue to be aware of is that if you use export default with an object, there's no way to extract a single property of the export when importing in a single line. That is, if you only have a default export, you can't do something like

import { method1 } from './main.js'.default;

You could only do

import theObj from './main.js';
const { method1 } = theObj;

which some would consider to look a bit ugly. Having independent named exports can make it a bit easier for the consumers of a module to import only what they need into standalone identifiers, in a single line.

CodePudding user response:

Classes in JS, unlike your familiarity in Java, are rarely used when not explicitly necessary. Nevertheless, there are situations where OOP in JS could be very useful.

Basically, the first method (Type 1) is what you're going to be using/seeing 99% of the time if you're doing just general JS programming such as front-end websites or apps.

If you're i.e. making a game however, you could use OOP to have better control over the different characters/object in your game.

In terms of back-end or on an infrastructural level, it really depends. You could perfectly use classes (Type 2) if you're following the MVC design pattern, but is again optional.

In the end, it comes down to your own design choice(s). You could go for FP (T1) or OOP (T2) whenever you like in JS, although there are some 'industry standards' for certain scenarios to decide when to use which.

CodePudding user response:

It actually depends on what you are exporting. The type 1 is more appropriate if you export only one or a few objects. With type 1, you can export any primitive type variables or objects and can be used straightaway in the main.js.

However, if you want to export many objects and/or variables, then type 2 makes sense. With type 2, all exports are stored in an object, so you have to access them using this object. Performance-wise both are same.

  • Related