DEV Community

Unlocking JavaScript Design Patterns: Mastering Singleton for Ultimate Code Efficiency

Nicolas B. on October 23, 2023

In the world of JavaScript, design patterns are your secret weapon to crafting efficient, organized, and maintainable code. Among these patterns, t...

Read full post

Rudy Nappée • Oct 23 '23 • Edited

Actually in JS, any ES module is a singleton ! No need for getInstance() or any other fancy OOP stuff 😅

Red Ochsenbein (he/him) • Oct 23 '23

Was about to say the same thing.

Dale Moore • Oct 24 '23

You beat me to it!

teamradhq • Oct 25 '23

To expand on what others are saying regarding ES modules being singletons: what this means is that every module you load in your program is only evaluated once.

So, while you can import a module multiple times, any code that's executed within its immediate scope only runs on the first import.

In your example, the way you would implement Logger as singleton is to just export an instance of the class:

// logger.mjs
console.log('Logger module loaded');

class Logger {
  constructor() {
    this.logs = [];
  }

  log(message) {
    this.logs.push(message);
  }

  showLogs() {
    console.log(this.logs);
  }
}

export default new Logger();

This guarantees that will only ever be one instance of Logger per process.

Consider this application structure:

// index.js
import logger from './logger.mjs';
import './module-a.mjs';
import './module-b.mjs';

console.log('Index loaded');
logger.log('Index:1');
logger.log('Index:2');
logger.showLogs();

// module-a.mjs
import logger from './logger.mjs';

console.log('Module A loaded');
logger.log('Module A:1');
logger.log('Module A:2');

import logger from './logger.mjs';

console.log('Module B loaded');
logger.log('Module B:3');
logger.log('Module B:4');

When we run index.mjs this is the output:

#$ node ./index.js
Logger module loaded
Module A loaded
Module B loaded
Index loaded
[
  'Module A:1',
  'Module A:2',
  'Module B:3',
  'Module B:4',
  'Index:1',
  'Index:2'
]

As you can see, all logs are sent to the same instance and modules are only evaluated the first time they're imported.

Nicolas B. • Oct 25 '23

Thank you for your very good explanation!

teamradhq • Nov 16 '23 • Edited

You're very welcome. I felt like "JS module is a singleton" isn't really an answer, and this fact doesn't make the singleton pattern redundant.

Exploiting JS module singleton is fine if you have a simple, single use case that doesn't require configuration. But if you have different implementations or use case requirements, then defining a singleton would be required.

An example of this in an Electron app I'm working on is handling IPC events when there are multiple render processes that need to handle events. Events need to be handled sequentially for each render process so I need some kind of queue system.

It's possible to achieve this with a JS module singleton. But it requires complex logic to determine which render process to delegate handling.

if (isMainWindowEvent(event) {
   mainWindow.invoke(handler)
} else if (isPlayerWindowEvent(event)) {
  playerWindow.invoke(handler)
} else {
  editorWindow.invoke(handler)
}

There's a lot of problems here and this control flow needs to exist on any method that interacts with render processes. It will get messy pretty quickly.

It's much simpler to just define a singleton that accepts the render process and reference this instead:

const mainIpcHandler = new IpcEventHandler(mainWindow);
const playerIpcHandler = new IpcEventHandler(playerWindow);
const editorIpcHandler = new IpcEventHandler(editorWindow);

So yeah, the fact that JS modules are singletons doesn't eliminate the need for singleton patterns in modular JS programs :)

Olivier • Oct 23 '23 • Edited

In your exemple nothing prevent 2 instance of the logger class which is the heart of the singleton "pattern".
Moreover your variable holding the instance reference is public hence the risk of letting the anyone resetting it to null.

A more secure approch could be :

class Logger {
  static #instance = null
  constructor() {
    if (Logger.#instance) {
      throw new Error("Singleton is limited to one instance. Use getInstance instead")
    }
    this.logs = [];
  }

  log(message) {
    this.logs.push(message);
  }

  showLogs() {
    console.log(this.logs);
  }

  static getInstance() {
    if (!Logger.#instance) {
      Logger.#instance = new Logger();
    }
    return Logger.#instance;
  }
}

Instance is private to the class , constructor will throw an error if an other instance exists

Nicolas B. • Oct 23 '23

Very interesting approach, thank's for your feedback :)

Dusan Petkovic • Oct 24 '23

If es modules are used, we wouldn't even need to worry about multiple instances being created, we could just:

export const logger = new Logger();

Khánh Hoàng (Marcus) • Oct 23 '23

I agree with @grunk comment, and we should make the access modifier of constructor is private to prevent new class

class Logger {
  static #instance = null
  private constructor() {
    if (Logger.#instance) {
      throw new Error("Singleton is limited to one instance. Use getInstance instead")
    }
    this.logs = [];
  }

  log(message) {
    this.logs.push(message);
  }

  showLogs() {
    console.log(this.logs);
  }

  static getInstance() {
    if (!Logger.#instance) {
      Logger.#instance = new Logger();
    }
    return Logger.#instance;
  }
}

Olivier • Oct 23 '23

Unfortunately you can't in JS 😉

Dusan Petkovic • Oct 24 '23

If there are multiple methods that we can execute as part of the logging mechanism then probably a class approach like in the example would be a good solution vs just es modules, that way its more explicit

Pimp My Ruby • Oct 23 '23

Very interesting thanks!

Shinigami • Oct 25 '23

I appreciate all the ESM comments, but I have a usecase where I create named logger instances.
So I call const logger = loggerFactory('MyService'); and behind that I have a Map<string, Logger>