‘Less Popular’ JavaScript Design Patterns

Image from https://unsplash.com/As software engineers, we strive to write maintainable, reusable, and eloquent code that might live forever in large applications. The code we create must solve real problems. We are certainly not trying to create redund…

Image from https://unsplash.com/

As software engineers, we strive to write maintainable, reusable, and eloquent code that might live forever in large applications. The code we create must solve real problems. We are certainly not trying to create redundant, unnecessary, or “just for fun” code. At the same time, we frequently face problems that already have well-known solutions that have been defined and discussed by the Global community or even by our own teams millions of times. Those solutions to such problems are called “Design patterns”.

Design patterns in JavaScript

There are a number of existing design patterns in software design, some of them are used more often, some of them less frequently. Examples of popular JavaScript design patterns include factory, singleton, strategy, decorator, and observer patterns. In this article, we’re not going to cover all of the design patterns in JavaScript. Instead, let’s consider some of the less well-known but potentially useful JS patterns such as command, builder, and special case, as well as real examples from our production experience.

Command pattern

Just imagine there’s a TV in your flat, and you have a remote control for it. When you (“client”) press any button (for instance, “Volume Up”) on the remote control (“invoker”), it sends a signal to your TV (“receiver”) and the command executes with a particular result. That’s basically how a command pattern is used in action.

In our real-world case, this design pattern in JavaScript was useful for processing messages from a message broker. It helped considerably with decoupling the execution logic for each message, and made it easier to add new commands if necessary.

The implementation was approximately the following:

In some implementations, command pattern might include a rollback method and journaling of each executed command.

Builder pattern

Have you ever ordered something from McDonald’s? Generally speaking, after you place a complex order, your order will be built from several components, for instance, a drink, a burger, and French fries, step-by-step. You don’t know how it was built or cooked, you just wait for your ready-to-go meal. Similarly, a builder encapsulates an entire process.

The real-case scenario was building a report. The report had several major components, from various sources, and after all the data was built, the report was to be sent to a reporting service.

The high-level implementation of the described JS pattern:

This pattern helped achieve a clear separation between the construction and representation of an object, and better control over the construction process itself.

Special case pattern

From time to time, while defining classes and objects that will handle some data, we do not want to change the behavior of the code if something goes wrong. Instead, we will manage that unique situation safely to avoid immediate failure or error. This is when Martin Fowler’s Special case JavaScript pattern comes in.

The Special Case pattern is a refinement of the strategy pattern. Generally speaking, it’s a default strategy with the same interface as it’s siblings and is what the caller expects.

As an example, we had several types of content on our application, some of them should have been processed, some of them not. The processor was defined by the strategy based on content type and, by default, it returned a nullable/default processor.

Let’s have a look at a code sample of this JavaScript pattern:

The pattern helped us not be afraid of getting the wrong input, and enabled us to use the processor’s public interface safely without any kind of null exceptions or unnecessary checks.

Closing thoughts

Plenty of JavaScript design patterns are well-defined and explained in articles like this one. However, please avoid any tendency toward overuse. As they say, “If all you have is a hammer, everything looks like a nail.” You don’t want to fall into the trap of overuse, so use these JS patterns only when necessary, and when they might solve a real problem in your code.

Thanks for reading!

"Less popular" JavaScript Design Patterns

Unlock 10x development with independent components

Building monolithic apps means all your code is internal and is not useful anywhere else. It just serves this one project. And as you scale to more code and people, development becomes slow and painful as everyone works in one codebase and on the same version.

But what if you build independent components first, and then use them to build any number of projects? You could accelerate and scale modern development 10x.

OSS Tools like Bit offer a powerful developer experience for building independent components and composing modular applications. Many teams start by building their Design Systems or Micro Frontends, through independent components. Give it a try →

An independent product component: watch the auto-generated dependency graph

Learn more


‘Less Popular’ JavaScript Design Patterns was originally published in Bits and Pieces on Medium, where people are continuing the conversation by highlighting and responding to this story.


Print Share Comment Cite Upload Translate
APA
Rufat Khaslarov | Sciencx (2024-03-28T22:16:27+00:00) » ‘Less Popular’ JavaScript Design Patterns. Retrieved from https://www.scien.cx/2022/02/20/less-popular-javascript-design-patterns/.
MLA
" » ‘Less Popular’ JavaScript Design Patterns." Rufat Khaslarov | Sciencx - Sunday February 20, 2022, https://www.scien.cx/2022/02/20/less-popular-javascript-design-patterns/
HARVARD
Rufat Khaslarov | Sciencx Sunday February 20, 2022 » ‘Less Popular’ JavaScript Design Patterns., viewed 2024-03-28T22:16:27+00:00,<https://www.scien.cx/2022/02/20/less-popular-javascript-design-patterns/>
VANCOUVER
Rufat Khaslarov | Sciencx - » ‘Less Popular’ JavaScript Design Patterns. [Internet]. [Accessed 2024-03-28T22:16:27+00:00]. Available from: https://www.scien.cx/2022/02/20/less-popular-javascript-design-patterns/
CHICAGO
" » ‘Less Popular’ JavaScript Design Patterns." Rufat Khaslarov | Sciencx - Accessed 2024-03-28T22:16:27+00:00. https://www.scien.cx/2022/02/20/less-popular-javascript-design-patterns/
IEEE
" » ‘Less Popular’ JavaScript Design Patterns." Rufat Khaslarov | Sciencx [Online]. Available: https://www.scien.cx/2022/02/20/less-popular-javascript-design-patterns/. [Accessed: 2024-03-28T22:16:27+00:00]
rf:citation
» ‘Less Popular’ JavaScript Design Patterns | Rufat Khaslarov | Sciencx | https://www.scien.cx/2022/02/20/less-popular-javascript-design-patterns/ | 2024-03-28T22:16:27+00:00
https://github.com/addpipe/simple-recorderjs-demo