Hugo JS

Like any kind of apps, JavaScript apps also have to be written well.

Otherwise, we run into all kinds of issues later on.

In this article, we’ll look at some best practices we should follow when writing JavaScript modules.

Prefer Named Exports

Named exports have to be imported by the name that the member is exported as.

This is different than default exports which can be imported by any name.

Therefore, named exports are less confusing that default exports.

For example, instead of writing:

export default class Person {
  constructor(name) {
    this.name = name;
  }
  greet() {
    return `Hello, ${this.name}!`;
  }
}

We write:

export class Person {
  constructor(name) {
    this.name = name;
  }
  greet() {
    return `Hello, ${this.name}!`;
  }
}

The first example can be imported with any name.

The 2nd has to be imported as Person .

Autocomplete also works with named exports if the text editor we’re using has that feature.

No work during import

We shouldn’t do anything with our exported code.

It’s easy to get unexpected results if we export something with an expression that does work.

For example, the following export is no good:

config.js

export const config = {
  data: JSON.parse(str)
};

The work would still be done after the export is done, so we get the latest value.

When we import it, JSON.parse is called.

This means that the import will be slower.

If we have:

import { config } from 'config';

Then the JSON.parse will be run then.

To make JSON.parse run in a lazy fashion, we can write:

config.js

let parsedData = null;

export const config  = {
  get data() {
    if (parsedData === null) {
      parsedData = JSON.parse(str);
    }
    return parsedData;
  }
};

This way, we cache the parsed string in parsedData .

JSON.parse only runs if parsedData is null .

#javascript #web development #development

How to Write Better JavaScript Modules
27.40 GEEK