2022-09-27
3445
#node#typescript
Ganesh Mani
33247
Sep 27, 2022 ⋅ 12 min read

Understanding design patterns in TypeScript and Node.js

Ganesh Mani I'm a full-stack developer, Android application/game developer, and tech enthusiast who loves to work with current technologies in web, mobile, the IoT, machine learning, and data science.

Recent posts:

Handling File Uploads In Next.js Using UploadThing

Handling file uploads in Next.js using UploadThing

Manage file uploads in your Next.js app using UploadThing, a file upload tool to be used in full-stack TypeScript applications.

Jude Miracle
Jun 21, 2024 ⋅ 15 min read
Exploring Advanced Support For Vite 5 In Storybook 8

Exploring advanced support for Vite 5 in Storybook 8

Explore the latest updates in Storybook 8, focusing on its improved support for Vite 5 as a build tool.

Will Soares
Jun 20, 2024 ⋅ 5 min read
Using Next Js With React Suspense To Create A Loading Component

Using Next.js with Suspense to create a loading component

Next.js 13 introduced some new features like support for Suspense, a React feature that lets you delay displaying a component until the children have finished loading.

Suraj Vishwakarma
Jun 19, 2024 ⋅ 9 min read
Exploring Angular 18's Redirectcommand Class And Let Block

Exploring Angular 18’s RedirectCommand class and @let block

Angular’s latest update brings greater control over redirects and the ability to define and assign variables within the template.

Lewis Cianci
Jun 19, 2024 ⋅ 6 min read
View all posts

6 Replies to "Understanding design patterns in TypeScript and Node.js"

  1. Singleton is antipattern, actually. At least in the described form. Makes testing really hard, creates hidden dependencies…
    If you have a dependency container, it can handle providing single instance of a service. This is a better form of singleton.

  2. The Singleton getInstance() implementation as presented may not work as expected depending on how MongoClient.connect is implemented. If the callback for .connect is invoked some time later when the connection is established (as is typical), then “this.instance” will not be set in time for the “return this.instance” line. If the assumption or behavior here is that getInstance() should return a promise that resolves to the client connection then the MongoClient.connect call should be wrapped in a “new Promise(…)” that resolves to mongo client inside the connect callback or rejects with an error from the callback.

  3. Singleton and Builder design patterns do not go well in javascript.
    Javascript has object literals, which solves the verbosity constructors with long parameter lists, funnily enough you gave an example of this User taking IUser object.
    And singleton is just a convoluted way to do something that is already solved by javascript modules.
    Each module is already a singleton imported via a path.
    It can export a class through the module, but that’s just extra unnecessary code.

    Please keep the Java/C# design patterns out of idiomatic javascript.

    Also Utill classes are not idiomatic javascript which has first cass support for functions.

Leave a Reply