Tips on preventing the need for null or undefined checks in JS/Typescript singletons that have an initialization function

Question

Tips on preventing the need for null or undefined checks in JS/Typescript singletons that have an initialization function

Is there a way to streamline the process of handling props in an Object literal that is dynamically initialized only once? I'm looking for a pattern that would eliminate the need for repetitive null/undefined checks and throw errors when certain methods are called before initialization.

I also need to ensure that some methods can be called before the initialization process. Should I consider switching from an object to a class constructor following the singleton pattern? But then, how do I handle external dependencies for the constructor props?

Any suggestions on how I can improve this structure would be greatly appreciated.

interface StuffType {
  x?: string;
  y?: string;
  z?: string;
  fn?: () => void;
  isInit: boolean;
}

const _stuff: StuffType = {
  x: undefined,
  y: undefined,
  z: undefined,
  fn: undefined,
  isInit: false,
};

const isReady = () => _stuff.isInit;

const init = (x: string, y: string, z: string, fn: () => void) => {
  if(_stuff.isInit) return;
  _stuff.x = x;
  _stuff.y = y;
  _stuff.z = z;
  _stuff.fn = fn;
};

const method1 = () => {
  // depends on xyz, fn being defined
  if (!_stuff.isInit) throw new Error('not init');
  _stuff.fn!();
  _stuff.x!;
  _stuff.y!;
  _stuff.z!;
};

// All the following methods would depend on init being done
// would require check on init/throw error/bang operator on props
// const method3 = () =>
// const method4 = () =>
// const method5 = () =>
// const method6 = () =>

const method2 = () => {
  // does not depend on xyz, fn
};

export const Stuff = {
  init,
  isReady,
  method1,
  method2,
  //etc...
};

Stuff.method2(); // fine
Stuff.method1(); // throws here
Stuff.init('x', 'y', 'z', () => console.log('init'));
Stuff.method1(); // does not throw

javascript typescript design-patterns singleton coding-style

Answer 1

Answer №1

In order to streamline this process, my suggestion would be to consolidate the data that needs to be initialized into a single separate property. This way, you only have to check if that specific property exists, making the extra isInit property unnecessary.

interface StuffType {
  data?: {
    x: string;
    y: string;
    z: string;
  }
  fn?: () => void;
}
const _stuff: StuffType = {
  fn: undefined,
};
const init = (x: string, y: string, z: string, fn: () => void) => {
  _stuff.data ??= { x, y, z };
};
const method1 = () => {
  const { data } = _stuff;
  if (!data) throw new Error('not init');
  _stuff.fn!();
  data.x;
  data.y;
  data.z;
};

I also want method2 to be able to be called before the init so that I can enqueue some things

There is no indication in the signature of method2 that it relies on any other factors, so there's no need for any real adjustments there; you're free to add

const method2 = () => {
  // does not depend on xyz, fn
};

whatever you desire. (You might consider having a local queue variable within the module, such as const queue = [], which could be updated if method2 is invoked)

Answer 2

In order to streamline this process, my suggestion would be to consolidate the data that needs to be initialized into a single separate property. This way, you only have to check if that specific property exists, making the extra isInit property unnecessary.

interface StuffType {
  data?: {
    x: string;
    y: string;
    z: string;
  }
  fn?: () => void;
}
const _stuff: StuffType = {
  fn: undefined,
};
const init = (x: string, y: string, z: string, fn: () => void) => {
  _stuff.data ??= { x, y, z };
};
const method1 = () => {
  const { data } = _stuff;
  if (!data) throw new Error('not init');
  _stuff.fn!();
  data.x;
  data.y;
  data.z;
};

I also want method2 to be able to be called before the init so that I can enqueue some things

There is no indication in the signature of method2 that it relies on any other factors, so there's no need for any real adjustments there; you're free to add

const method2 = () => {
  // does not depend on xyz, fn
};

whatever you desire. (You might consider having a local queue variable within the module, such as const queue = [], which could be updated if method2 is invoked)

Answer 3

Answer №2

Avoiding a partial type where every property is optional individually can be achieved by making them dependent on each other using a discriminated union:

interface Stuff {
  isInit: true;
  x: string;
  y: string;
  z: string;
  fn: () => void;
}

type MaybeStuff = Stuff | { isInit: false };

const _stuff: MaybeStuff = {
  isInit: false,
};

export const method1 = () => {
  if (!_stuff.isInit) throw new Error('not initialised');
  // depends on x, y, z, fn being initialised
  _stuff.fn();
  _stuff.x;
  _stuff.y;
  _stuff.z;
};

An even simpler solution would be to make _stuff a mutable variable initially set to undefined:

interface Stuff {
  x: string;
  y: string;
  z: string;
  fn: () => void;
}

let _stuff: Stuff | undefined; /*
^^^ */

export const isReady = () => _stuff !== undefined;

export function init(x: string, y: string, z: string, fn: () => void) {
  if (_stuff) return; // throw new Error('already initialised');
  stuff = {x, y, z, fn};
};

export function method1() {
  if (!_stuff) throw new Error('not initialised');
  // depends on _stuff being initialised
  _stuff.fn();
  _stuff.x;
  _stuff.y;
  _stuff.z;
}

export function method2() {
  // does not depend on xyz, fn
}

To avoid repeating the if (!_stuff) … line in methods needing the stuff object, create a helper function for them:

function get(): Stuff {
  if (!_stuff) throw new Error('not initialised');
  return _stuff;
}
export function method1() {
  const stuff = get(); // depends on _stuff being initialised
  stuff.fn();
  stuff.x;
  stuff.y;
  stuff.z;
}

export function method2() {
  // does not depend on xyz, fn
}

export function method3() {
  const stuff = get(); // depends on _stuff being initialised
  …
}

[I have] an Object literal that is dynamically initiated only once at some point. This object would serve as a singleton in a lifecycle of the application. Is there a way to make this cleaner?

Creating a proper singleton requires it to be initialised at the start of the application and not during its lifecycle with parameters passed later on. Consider refactoring your module into a class, eliminating the mutable _stuff static variable and the init method. Construct the object when parameter values are available, and let that module provide the instance to the rest of the application (via global variable, singleton pattern, dependency injection, etc.).

Also, ensure that method2 is either a static method of the class if stateless or a method of the module managing initialisation state if it queues tasks until initialisation.

Answer 4

Avoiding a partial type where every property is optional individually can be achieved by making them dependent on each other using a discriminated union:

interface Stuff {
  isInit: true;
  x: string;
  y: string;
  z: string;
  fn: () => void;
}

type MaybeStuff = Stuff | { isInit: false };

const _stuff: MaybeStuff = {
  isInit: false,
};

export const method1 = () => {
  if (!_stuff.isInit) throw new Error('not initialised');
  // depends on x, y, z, fn being initialised
  _stuff.fn();
  _stuff.x;
  _stuff.y;
  _stuff.z;
};

An even simpler solution would be to make _stuff a mutable variable initially set to undefined:

interface Stuff {
  x: string;
  y: string;
  z: string;
  fn: () => void;
}

let _stuff: Stuff | undefined; /*
^^^ */

export const isReady = () => _stuff !== undefined;

export function init(x: string, y: string, z: string, fn: () => void) {
  if (_stuff) return; // throw new Error('already initialised');
  stuff = {x, y, z, fn};
};

export function method1() {
  if (!_stuff) throw new Error('not initialised');
  // depends on _stuff being initialised
  _stuff.fn();
  _stuff.x;
  _stuff.y;
  _stuff.z;
}

export function method2() {
  // does not depend on xyz, fn
}

To avoid repeating the if (!_stuff) … line in methods needing the stuff object, create a helper function for them:

function get(): Stuff {
  if (!_stuff) throw new Error('not initialised');
  return _stuff;
}
export function method1() {
  const stuff = get(); // depends on _stuff being initialised
  stuff.fn();
  stuff.x;
  stuff.y;
  stuff.z;
}

export function method2() {
  // does not depend on xyz, fn
}

export function method3() {
  const stuff = get(); // depends on _stuff being initialised
  …
}

[I have] an Object literal that is dynamically initiated only once at some point. This object would serve as a singleton in a lifecycle of the application. Is there a way to make this cleaner?

Creating a proper singleton requires it to be initialised at the start of the application and not during its lifecycle with parameters passed later on. Consider refactoring your module into a class, eliminating the mutable _stuff static variable and the init method. Construct the object when parameter values are available, and let that module provide the instance to the rest of the application (via global variable, singleton pattern, dependency injection, etc.).

Also, ensure that method2 is either a static method of the class if stateless or a method of the module managing initialisation state if it queues tasks until initialisation.

Tips on preventing the need for null or undefined checks in JS/Typescript singletons that have an initialization function

Answer №1

Answer №2

Similar questions

I am having trouble getting the hoverOffset feature to work with doughnut charts in vue-charts.js

Missing expected property in TypeScript casting operation

How to display only a portion of content using UI Bootstrap collapse feature

Exploring the process of iterating through a JSON response in PHP to extract all values

Utilizing vanilla JavaScript or ES6 to extract data from a JSON file

Executing Ionic function before application shutdown

Tips for transforming a date into a time ago representation

Unable to execute AJAX POST request

Having trouble with VS Code on my Linux system - npm error popping up?

"Here's a simple guide to generating a random number within a specified range

Discovering the type in Typescript without explicitly defining a type variable for the callback

Updating React markers dynamically on Google Maps issue

The jQuery validation feature permits entering a code that falls within the range of user1 to user100

Methods for reloading the requirejs module

Guide to acquiring the webViewLink using Google Drive Api v3?

Move the div containing an <audio></audio> tag

Deactivate the other RadioButtons within an Asp.net RadioButtonList when one of them is chosen

I attempted to implement dialog functionality using material-ui code from the documentation, but for some reason it's not functioning correctly. Can anyone point out what I might

The new experimental appDir feature in Next.js 13 is failing to display <meta> or <title> tags in the <head> section when rendering on the server

Issues with AngularJS dirty validation for radio buttons not being resolved