11 JavaScript Examples to Source Code That Reveal Design Patterns In Use
Tags: react, javascript, webdev, node
Published: 2022-03-21 01:30:31

![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/27htbdsmkpn7fobwpbus.jpg)

While we write code for web applications we are constantly trying to make good decisions. It's not always an easy task especially when our code becomes larger over time.

Fortunately there are some techniques we can incorporate into our code to solve complex issues. They're called _design patterns_.

This post will go over several source codes in the JavaScript world that you can look at to find some inspiration, answers, or even as a learning experience so that you can speed up your pace in learning the advanced coding techniques without feeling alone.

I noticed that not many articles out there directly reveal the patterns that are used in source codes and leave that task to the audience. I don't know about you but when I was new to programming this would have been very helpful. Don't worry, I got you covered.

## Builder Design Pattern

One of my favorite libraries demonstrating the builder pattern in practice is [spotify-web-api-node](https://github.com/thelinmichael/spotify-web-api-node/blob/master/src/spotify-web-api.js).

The builder design pattern is a behavior pattern that helps to construct objects that are otherwise complex without it.

This library constructs a builder that makes up a good majority of its implementation. For example most of its methods construct requests using one builder that _reads like english_:

![builder-pattern-in-javascript-spotify-web-api-node1.png](https://jsmanifest.s3.us-west-1.amazonaws.com/posts/11-javascript-examples-to-source-code-that-reveal-design-patterns-in-use/builder-pattern-in-javascript-spotify-web-api-node1.png)

Envision this without the builder providing this interface and you will see the benefit that the builder does for you.

## Chaining / Fluent interfaces

We have actually just seen this technique in the last example, but we can also talk about [jQuery](https://jquery.com/) that takes advantage of chaining methods together resulting in an easy to read fluent api to work with.

We are talking about a library that took the JavaScript community by storm before modern frameworks like React took their way into the scene, so this pattern is proven to be useful in programming.

jQuery was so popular back in the day that front end job listings preferred candidates with experience in jQuery. Although it isn't as popular as before, it is still being used by plenty of companies today.

[cheerio](https://cheerio.js.org/) is a library I still use today that was heavily inspired by the jQuery library, and remains popular today when topics like web scraping come up. It [uses chaining](https://github.com/cheeriojs/cheerio/blob/main/src/api/manipulation.ts) to manipulate DOM nodes similarly to jQuery.

The moral of the story? _It works_.

## Life cycles

As you start building more projects there will be a moment in time where you need to integrate some type of life cycle pipeline to ensure that functions are being processed in the correct time of events.

When consumed this can be useful to functions outside that need to tap into specific timing of events like manipulating DOM nodes _after_ they are done applying their style attributes.

A good repository to learn from this concept is [snabbdom](https://github.com/snabbdom/snabbdom), a virtual DOM library that focuses on simplicity, modularity, and powerful features to improve performance when working with the DOM.

They provide an extensible module api that allow developers to create their own modules to attach onto the main `patch` function. The core implementation of each module _is to tap into these life cycles_ which is what makes this library work in the way that it does for our web applications.

For example they provide an optional [event listeners module](https://github.com/snabbdom/snabbdom/blob/master/src/modules/eventlisteners.ts) that hooks into this life cycle and ensures that event handlers are correctly attached and cleaned up between each patch (in other words each "rerender").

## Command Design Pattern

Like jQuery, redux also soared in popularity but mostly within applications that needed to manage state which was basically every react app. It is by far my favorite example of the command pattern used in practice.

The pattern is facilitated through the concept of _dispatching actions_ where each action is _the_ command. [Their documentation](https://redux.js.org/api/createstore) exclusively mentions that the only way to change its state is by _dispatching actions_.

The benefits this pattern provides are the main reasons it was popularized in react. Redux takes advantage of the command pattern by separating the objects that invoke actions away from those that _know_ what to when they are being invoked. This is a perfect combination when used in conjunction with react. React is mostly about composition and separation of concerns between dumb and smart components. (However there are still different ways to architect react apps that don't utilize the concept of smart and dumb components).

Powerful middlewares were created to squeeze the most of the pattern's advantages such as being able to time travel in the [redux devtools](https://github.com/reduxjs/redux-devtools) extension.

## Modularity

When I first landed my eyes on the [lodash repository](https://github.com/lodash/lodash) to examine how their functions were structured, there were times I asked my self "What is the point of this function being here?" because functions like [flowRight](https://github.com/lodash/lodash/blob/master/flowRight.js) import another function just to call the function and return the result.

But over time as I started gaining more hands on experience I realized the beauty in structuring our modules/utility functions this way.

It helps you to think in the concept of _reusability_, functions with a single responsibility, and [DRY](https://en.wikipedia.org/wiki/Don%27t_repeat_yourself) (Do Not Repeat Yourself) when you write code. The benefit I take away from `flowRight` structured in the way that it is is that by depending on `flow` to do the "flow" logic, it only needs to be responsible for "flowing them to the right". Also, realize that if there updates in the impementation of `flow`, it automatically reflects in `flowRight` as well as all other functions that import `flow`.

## Abstract Syntax Trees and the Composite Design Pattern

I'll be honest, my approach to getting used to working with ASTs is a bit weird, but _it worked_ for me. For some reason the thought of working with the TypeScript AST sounds really attractive to me. I'm sure most people recommend to start deep diving [into babel first](https://github.com/jamiebuilds/babel-handbook) before getting used to working with [an AST with the TypeScript compiler](https://github.com/microsoft/TypeScript/wiki/Using-the-Compiler-API), but I started it the other way around. There is a great library called [ts-morph](https://ts-morph.com/) that focuses on making it easier for developers to work with the TypeScript compiler. Learning hands on with ts-morph _while_ getting used to their compiler api made babel _much_ easier to understand without ever touching babel.

You will also notice that a lot of objects you work with share a similar interface. This is their interface exposed to consumers that uses the composite design pattern.

## Proxy Design Pattern

The Proxy pattern provides a placeholder object to act as the real object. It controls access to the real object.

[immer](https://github.com/immerjs/immer) uses this pattern by [returning to us a draft](https://github.com/immerjs/immer/blob/master/src/core/proxy.ts) that represents the object you give to the `produce` function. What it gets from this pattern is _immutability_ which is great for react apps.

## Observer / PubSub Design Pattern

One library that uses this pattern extensively is [twilio-video.js](). Almost every object ultimately extends the `EventEmitter` whether by directly extending it or by inheritance.

Their core objects like [Participant](https://github.com/twilio/twilio-video.js/blob/master/lib/participant.js) implements this pattern extensively which enable consumers of the api to create an event driven video chat experiences in their apps.

For example to observe when a users' (or participant) media tracks are ready (these are what gets attached to the DOM and start the streaming) you would observe their remote participant object in code via `someParticipant.on('trackSubscribed', () => {...})` and handle it accordingly.

## Chain of Responsibility Design Pattern

Implementing chain of responsibility in JavaScript usually involves a pipeline of loosely coupled functions where one or more can handle the request.

The best example demonstrating this pattern is the [expressjs](https://expressjs.com/) library through the concept of [route handling](https://github.com/expressjs/express/blob/master/examples/search/index.js).

For example, if you create a route handler for the route `/dogs` and one for `/dogs?id=3` and a user has navigated to `/dogs?id=3`, there will be a chain of handlers invoking where `/dogs` will get called first and can decide to handle this request _or_ pass it on to the second handler that will get to decide from there, and so on.

## Visitor Design Pattern

You will rarely see this pattern implemented in practice until you start digging deeper into tools. The visitor pattern is useful in cases where you want to work with each object in ASTs by "visiting" each AST node.

Visitors are used for many reasons like extensibility, plugins, [printing an entire schema](https://github.com/graphql/graphql-js/blob/main/src/language/printer.ts) somewhere, etc.

Here is an implementation of one from the [graphql repository](https://github.com/graphql/graphql-js/blob/main/src/language/visitor.ts)

## Prototype Design Pattern

The Prototype pattern's main concern is to ensure that objects being created are not new instances each time. This means if we create an object `MathAdd` with a method `add`, we should just reuse `add` when we created multiple instances of `MathAdd` since the implementation doesn't change. This is a performance benefit as well.

The [request](https://github.com/request/request/blob/master/lib/querystring.js) library uses this pattern on nearly all of their class objects.

## Conclusion

And that concludes the end of this post! I hope you found this valuable and look out for more in the future!

Find me on [medium](https://medium.com/@jsmanifest)