DEV Community: Saiful Bashar

Stop Writing Singleton Classes: Use ES6 Modules (The TypeScript Way)

Saiful Bashar — Fri, 26 Dec 2025 12:44:16 +0000

If you come from an Object-Oriented background (Java, C#, etc.), you are likely familiar with the Singleton Pattern. It ensures a class has only one instance and provides a global point of access to it.

In traditional JavaScript, we often try to mimic this by writing Classes with static methods or complex getInstance() logic. But here is the secret: You don't need that boilerplate.

JavaScript has a built-in, native Singleton mechanism that you are probably already using: The ES6 Module.

In this post, I’ll explain why ES6 modules behave as singletons and show you a practical, type-safe React example of how to use them to share state or logic.

The "Old" Way (The Class Approach)

If you strictly follow the classical definition, a Singleton in JavaScript usually looks something like this. Note how verbose it becomes just to ensure type safety and singular existence.

// LoggerClass.ts
class Logger {
  private static instance: Logger;
  private logs: string[] = [];

  private constructor() {} // Private constructor prevents direct instantiation

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

  public log(message: string): void {
    this.logs.push(message);
    console.log(`LOG: ${message}`);
  }

  public getCount(): number {
    return this.logs.length;
  }
}

export default Logger.getInstance();

Using ES6 Modules

ES6 Modules are singletons by default. When you import a module, it is executed only once. The exported value is cached by the JavaScript engine.

Here is the exact same functionality, but cleaner and fully typed:

// LoggerModule.ts

// 1. Private State (Scoped to this file only)
const logs: string[] = [];

// 2. Exported Functions (The public API)
export const log = (message: string): void => {
  logs.push(message);
  console.log(`LOG: ${message}`);
};

export const getCount = (): number => {
  return logs.length;
};

That’s it. No class, no new, no static, and no private keywords required—the file scope handles privacy naturally.

How It Works: The "Magic" of Module Caching

You might be wondering: "If I import this file in two different components, won't it reset the logs array?"

No.

Here is what happens under the hood:

First Import: When your app first starts and import ... from './LoggerModule' is called, the JS engine executes the file and allocates memory for logs.
Caching: The engine caches this specific module instance.
Subsequent Imports: When another file imports ./LoggerModule, the engine looks at its cache. It sees the module is already loaded and hands back the reference to the exact same memory space.

Practical React + TypeScript Example

Let's build a Global Counter Service. We will define types for our subscriptions so consumers can't mess up the data flow.

1. The Singleton Service (Type-Safe)

We define a specific type for our listener callback to ensure strict typing across the app.

// services/CounterService.ts

// Define the shape of our listener
type Listener = (count: number) => void;

// Private state
let count: number = 0;
let listeners: Listener[] = [];

// Helper to notify all listeners
const notify = (): void => {
  listeners.forEach((listener) => listener(count));
};

// Public API
export const increment = (): void => {
  count += 1;
  notify();
};

export const getValue = (): number => count;

export const subscribe = (listener: Listener): (() => void) => {
  listeners.push(listener);

  // Return an unsubscribe function for cleanup
  return () => {
    listeners = listeners.filter((l) => l !== listener);
  };
};

2. Component A (The Modifier)

This component imports the functions directly. TypeScript knows exactly what increment does.

// components/CounterButton.tsx
import React from 'react';
import { increment, getValue } from '../services/CounterService';

const CounterButton: React.FC = () => {
  return (
    <div style={{ border: '1px solid blue', padding: '16px', margin: '16px' }}>
      <h3>Component A (Modifier)</h3>
      <p>Initial Value Load: {getValue()}</p>
      <button onClick={increment}>Increment Global Count</button>
    </div>
  );
};

export default CounterButton;

3. Component B (The Observer)

This component subscribes to changes. Thanks to the Listener type we defined earlier, TypeScript will error if we try to pass a listener that expects a string instead of a number.

// components/CounterDisplay.tsx
import React, { useState, useEffect } from 'react';
import { getValue, subscribe } from '../services/CounterService';

const CounterDisplay: React.FC = () => {
  // Initialize state with the current value of the singleton
  const [count, setCount] = useState<number>(getValue());

  useEffect(() => {
    // Subscribe returns the cleanup function, which useEffect uses perfectly
    const unsubscribe = subscribe((newCount) => {
      setCount(newCount);
    });

    return unsubscribe;
  }, []);

  return (
    <div style={{ border: '1px solid green', padding: '16px', margin: '16px' }}>
      <h3>Component B (Observer)</h3>
      <p>Watching singleton updates...</p>
      <h1>{count}</h1>
    </div>
  );
};

export default CounterDisplay;

When to Use This

This pattern is perfect for:

API Clients: Configuring a single Axios instance with interceptors.
WebSocket Connections: Maintaining one active socket connection shared across screens.
Feature Flags: A simple store to check if a feature is enabled.

It is not a replacement for Redux, Zustand, or Context API for complex UI state, but for utility logic and single-purpose services, it is the cleanest, most efficient solution.

Conclusion: The Hidden Performance Win (Tree Shaking)

While code cleanliness is a great reason to switch to ES6 Modules, the strongest argument might actually be performance.

Modern bundlers like Webpack, Rollup, and Vite use a process called Tree Shaking to remove unused code from your final production bundle.

Class Singleton vs. Module Singleton

The Class Problem:
When you export a class instance, it is treated as a single object. Even if you only use one method from that class, the bundler often has to include the entire class and all its methods because it's difficult to statically analyze which methods on the prototype chain are truly unused.

// Traditional Class Import
import Logger from './LoggerClass';

// You only use .log(), but .getCount(), .reset(), and .debug() 
// are likely still included in your bundle.
Logger.log('Hello');

The Module Solution:
With ES6 Modules, exports are static. If you have a utility file with 50 functions but only import one, the bundler can completely strip out the other 49 functions from the final build.

// ES6 Module Import
import { log } from './LoggerModule';

// The bundler sees that `getCount` is never imported.
// It removes it from the final JavaScript bundle.
log('Hello');

Final Summary

By switching from Class-based Singletons to ES6 Modules, you gain:

Simplicity: No boilerplate, new keywords, or static methods.
Safety: True private state via file-scope variables.
Performance: Granular imports allow for better Tree Shaking, resulting in smaller bundle sizes.

So, the next time you reach for a Singleton in React or TypeScript, remember: You probably just need a module.

The Great JavaScript Illusion: Why Primitives Act Like Objects

Saiful Bashar — Fri, 26 Dec 2025 12:01:06 +0000

If you’ve spent more than five minutes with JavaScript, you’ve probably written code like this:

let message = "hello world";
console.log(message.toUpperCase()); // "HELLO WORLD"

let score = 98.567;
console.log(score.toFixed(1)); // "98.6"

It seems totally normal. You have a string, you call a method on it. You have a number, you call a method on it.

But if you dig a little deeper into JavaScript theory, you hit a confusing contradiction: Strings and numbers are primitive values, and primitives are not objects.

If they aren't objects, how on earth do they have methods like .toUpperCase()? How can they hold properties like .length?

Welcome to one of JavaScript’s cleverest illusions: Autoboxing.

The Two Worlds of Data

To understand the illusion, we first need to understand reality. In JavaScript, data falls into two distinct categories:

1. Primitives

These are the simplest forms of data. They are immutable (cannot be changed) and hold a single value. They are lightweight and fast.

String ("hi")
Number (42)
Boolean (true)
null
undefined
Symbol
BigInt

2. Objects

These are collections of key-value pairs. They can be mutated, grow, shrink, and contain complex logic.

Arrays ([1, 2, 3])
Functions
Standard Objects ({ name: "Dave" })

Here is the golden rule: Only objects can have properties and methods.

So, looking back at our first example, "hello world".toUpperCase() shouldn't technically be possible.

The "Magic Trick" Explained

JavaScript knows that working with pure primitives can be tedious. If you couldn't do "hello".length, you’d have to pass that string into some utility function to count its characters. That’s clunky.

To solve this, JavaScript uses a mechanism called Autoboxing (or Primitive Wrapper Objects).

Think of it like a stunt double in a movie.

The actor (the primitive string) is standing on set.
The director calls for a dangerous action sequence (calling a method).
The actor cannot do this. So, instantly, a stunt double wearing an identical mask (the wrapper object) steps in.
The stunt double performs the action.
As soon as the action is finished, the stunt double vanishes, and the original actor is back.

Behind the Scenes

When you write this:

let str = "hi";
let loudStr = str.toUpperCase();

JavaScript secretly performs these three steps in microseconds:

Step 1: The Wrapper is Created
JavaScript sees you trying to access a property (the dot .) on a primitive string. It immediately creates a temporary object using the built-in String constructor.
Internal thought process: `let tempWrapper = new String("hi");`

Step 2: The Method is Executed
This temporary object does have methods. The operation is performed on the object.
Internal thought process: `let result = tempWrapper.toUpperCase();`

Step 3: The Wrapper is Destroyed
The result is returned to your variable (loudStr), and the temporary tempWrapper object is immediately thrown away into the garbage collector. It never existed as far as your code is concerned.

This happens every single time you access a property on a string, number, or boolean.

Why Bother with the Illusion?

Why doesn't JavaScript just make everything an object and be done with it?

Performance.

Primitives are incredibly cheap to store in memory and fast for the CPU to process. Objects are heavier. If every single number in your application were a full-blown object, your app would be significantly slower and consume far more memory.

Autoboxing gives you the best of both worlds: the speed and lightweight nature of primitives, combined with the convenient utility methods of objects.

The Dangerous Exceptions: null and undefined

Remember the list of primitives earlier? There are two outcasts in that group.

While String, Number, and Boolean have corresponding wrapper objects, null and undefined do not.

They are truly "naked" primitives. If you try to treat them like objects, there is no stunt double to save them. The program crashes.

let ghosts = null;
console.log(ghosts.length);
// Uncaught TypeError: Cannot read properties of null (reading 'length')

This is arguably the most common error in JavaScript history. It happens because you are trying to use the autoboxing feature on a primitive type that doesn't support it.

A Final Warning: Don't Do It Yourself

Knowing this, you might be tempted to create these wrapper objects manually:

// Don't do this!
let myStringObj = new String("hello");

While possible, it is almost always a bad idea.

A string primitive evaluates truthfully based on its content. A string object is an object, and in JavaScript, objects are always "truthy," even if they contain an empty string.

let primitiveEmpty = "";
let objectEmpty = new String("");

console.log(typeof primitiveEmpty); // "string"
console.log(typeof objectEmpty);    // "object" -> Confusing!

if (primitiveEmpty) { /* This won't run */ }
if (objectEmpty) { /* This WILL run! Danger! */ }

Conclusion

The next time you type .toFixed(2) on a number variable, take a moment to appreciate the little sleight of hand JavaScript just performed.

It briefly promoted a simple piece of data into a complex object, ran a calculation, and cleaned up the mess—all so you could write cleaner code. It’s one of those strange, beautiful design choices that makes JavaScript the unique language it is.

JavaScript Scope & Closure: Stop Memorizing, Start Understanding

Saiful Bashar — Fri, 26 Dec 2025 10:56:34 +0000

Let’s be brutally honest. When you walk into a JavaScript technical interview, the interviewer isn't looking for someone who can copy-paste from Stack Overflow. They are looking for someone who understands how the machine works.

Two concepts trip up developers more than any others: Scope and Closure.

Most developers have a vague, "hand-wavy" understanding of them. They know that it works, but not why. In an interview, "hand-wavy" doesn't cut it. When you can't explain why a variable is undefined, or why a loop is printing the wrong number, you fail the test.

To master these concepts, you have to stop treating JavaScript like a black box and start thinking like the JavaScript Engine.

Here is the mental model you need to internalize.

Part 1: Scope is a Set of Rules

The first mistake developers make is thinking Scope is a physical "place" where variables live.

It’s better to think of Scope as a set of rules that the JavaScript Engine uses to figure out where to look for a variable by its identifier name.

JavaScript uses something called Lexical Scope. This is the most important term you will read today. "Lexical" relates to the lexing or parsing stage of compilation.

In plain English: Scope is determined by where you, the author, physically write the code. The nesting of your functions determines the nesting of your scopes. Once written, these rules are (mostly) set in stone before the code even runs.

The Mental Model: The Office Building

Imagine your program is a multi-story office building.

The ground floor (lobby) is the Global Scope.
Every function you declare creates a new, private floor above the one you are currently on.

When the Engine is executing code inside a function (say, on the 3rd floor) and it needs to find a variable (let's call it starthroat), it follows a strict procedure:

Look locally: Does the 3rd floor have its own starthroat? If yes, use it.
Look outer: If no, take the stairs down to the 2nd floor. Do they have it?
Repeat: Keep going down one floor at a time until you reach the lobby (Global Scope).
Give Up: If it's not in the lobby, throw a ReferenceError. It doesn't exist.

Crucial Interview Note: Scope lookups only go up (outward). They never go down (inward). The lobby cannot see what's happening on the 3rd floor.

var buildingName = "JS Towers"; // Lobby (Global)

function floorTwo() {
    var manager = "Kyle"; // 2nd Floor Scope

    function floorThree() {
        var developer = "You"; // 3rd Floor Scope

        // The engine looks here (floor 3), finds nothing.
        // Goes down to floor 2, finds 'manager'. Success.
        console.log(manager); 
    }
}

Part 2: Closure is Not Magic

If Scope is the set of rules for lookup, Closure is what happens when you bend those rules.

Many define closure vaguely. Let's define it precisely.

Closure is observed when a function executes outside of its lexical scope, but still maintains access to that scope.

Normally, when a function finishes executing, its scope is garbage collected. The memory is freed up. Closure stops this from happening.

The Mental Model: The Backpack

If you define Function B inside of Function A, Function B gets a "hidden link" to Function A's scope surrounding it.

When Function B is passed out of Function A to be used elsewhere in your program, it doesn't leave empty-handed. It takes that hidden link with it.

Think of it like a backpack. Function B carries a backpack containing all the variables that existed in Function A when Function B was created.

Whenever Function B runs—no matter where it is, or how much later in time it is—it can open that backpack and access those variables.

function outer() {
    var secret = "XYZ_123"; // By rules of scope, this should die when outer() finishes.

    function inner() {
        // 'inner' closes over the 'secret' variable.
        // It puts 'secret' in its backpack.
        console.log("The secret is: " + secret);
    }

    return inner; // We send 'inner' out into the world.
}

// outer() runs and finishes entirely.
var myRef = outer(); 

// ... hours later ...

// myRef is executed in the global scope. 
// Yet, it still remembers the scope of 'outer'. 
myRef(); // "The secret is: XYZ_123"

In an interview, don't just say "it remembers." Say: "Because of closure, inner retains a reference to the lexical scope of outer, preventing it from being garbage collected."

Part 3: The Classic Interview Trap

If you are asked about closure in an interview, there is a 90% chance you will see a variation of this loop problem. It is designed to test if you understand the difference between scope boundaries and value references.

The Problem:

for (var i = 1; i <= 3; i++) {
    setTimeout(function timer() {
        console.log(i);
    }, i * 1000);
}

What the junior developer expects: It prints 1, then 2, then 3, one second apart.
What actually happens: It prints 4, then 4, then 4, one second apart.

How to explain this like a pro:

Identify the Scope: "The variable i is declared with var. This means it belongs to the global scope (or function scope if this were wrapped in a function), not the loop block scope."
Identify the Closure: "The timer function inside setTimeout forms a closure over that single shared global variable i."
The Execution: "The loop finishes running almost instantly. When it finishes, the value of i is 4 (because that's when the loop condition i <= 3 failed).
The Result: "When the three timer functions finally execute seconds later, they all look into their closure backpacks, find the exact same reference to i, and print its current value: 4."

The Fix (Pre-ES6 IIFE Pattern):
You need to create a new scope for every iteration of the loop to "capture" the current value of i.

for (var i = 1; i <= 3; i++) {
    // Create an Immediately Invoked Function Expression (IIFE)
    // This creates a new scope bubble for every loop iteration.
    (function(j) { 
        setTimeout(function timer() {
            // timer now closes over 'j', which is unique to this iteration's scope
            console.log(j); 
        }, j * 1000);
    })(i); // Pass in current 'i' value
}

(Note: In modern JS, you would just change var i to let i in the for loop head, because let creates a new block scope for every iteration automatically. Mentioning both shows historical context and modern knowledge.)

Summary

Don't memorize code snippets. Memorize the models.

Scope is about where variables are accessible, determined at write-time (lexically). Think of the office building floors.
Closure is about when variables are accessible. A function remembers its lexical scope even when executed later. Think of the backpack.

When you look at code in an interview, trace the scope lines mentally. Ask yourself: "Which scope bucket does this variable belong to?" and "What is this function carrying in its backpack?"

Do that, and you won't just pass the interview; you'll actually understand the language you use every day.

React Native: Using KeyboardAvoidingView for Multiline TextInput

Saiful Bashar — Mon, 03 Jun 2024 07:46:51 +0000

When using KeyboardAvoidingView with a single line TextInput, it looks like this:

Issue with Multiline TextInput
The issue arises when the multiline prop is added to TextInput:

Solution
The solution is to toggle the scrollEnabled property on focus using setTimeout and disable it on blur. Here is a code snippet demonstrating this:
github link

import React from "react";
import { StyleProp, Text, TextInput, View, ViewStyle } from "react-native";

export default function InputField({
  label,
  inputProps,
  containerStyle
}: {
  label: string;
  inputProps?: React.ComponentProps<typeof TextInput>;
  containerStyle?: StyleProp<ViewStyle>
}) {
  const [focused, setFocused] = React.useState(false);
  const [scrolled, setScrolled] = React.useState(true);

  return (
    <View style={containerStyle}>
      <Text style={{ marginBottom: 8 }}>{label}</Text>
      <View
        style={{
          borderWidth: focused ? 2 : 1,
          borderColor: focused ? "white" : "grey",
          borderRadius: 8,
          maxHeight: 200,
          flexDirection: "row",
          alignItems: "center",
        }}
      >
        <TextInput
          {...inputProps}
          scrollEnabled={scrolled}
          onFocus={(e) => {
            if (inputProps && inputProps.onFocus) {
              inputProps.onFocus(e);
            }
            setFocused(true);
            setScrolled(false);
            setTimeout(() => {
              setScrolled(true);
            }, 1000);
          }}
          onBlur={(e) => {
            if (inputProps && inputProps.onBlur) {
              inputProps.onBlur(e);
            }
            setFocused(false);
            setScrolled(true);
          }}
          style={{
            padding: 16,
            flex: 1,
            margin: 0,
            minHeight: inputProps?.multiline ? 100 : "auto",
          }}
          placeholderTextColor="grey"
        />
      </View>
    </View>
  );
}

Result
After implementing the solution, the behavior is as expected: