JavaScript Design Patterns: A Complete Guide
Good JavaScript developers want to provide manageable, clean, healthy code. You tackle fascinating problems that, although unique, do not always call for original answers. You have probably found yourself developing code that resembles the answer of a completely different problem you have dealt with in past. You used JavaScript design patterns, but you might not know it. In software design, design patterns are reusable answers for often occurring issues.Many such reusable solutions are created and tested over the lifetime of each language by numerous developers from its community. This combined experience of many engineers makes such solutions so helpful since they enable us to solve the current problem at hand while simultaneously optimally writing code.
Design patterns mostly provide us the following advantages:
They are confirmed solutions since numerous developers make use of design patterns, thus you know they work. Furthermore, you are sure that they were changed several times and most likely improvements were applied.
They are rather reusable. Since design patterns are not connected to any one problem, they record a reusable solution which can be altered to solve several particular ones.
They communicate effectively. Design patterns can quite simply illustrate a great solution.
They simplify correspondence: Knowing design patterns helps developers to interact with one other about possible answers to a given challenge.
They avoid the necessity for code refactorizing: If an application is developed with design patterns in mind, it is usually the case that you won’t need to rewrite the code later on since applying the suitable design pattern to a particular problem is already an optimal solution.
They reduce the size of the codebase since, typically elegant and ideal solutions, design patterns demand less code than other solutions.
Although you’re ready to start right now, let’s review some fundamentals before you study all about JavaScript design patterns.
A Synopsis of JavaScript’s History
Among the most often used programming languages available for web development nowadays is JavaScript. Originally developed for one of the first web browsers as a form of “glue” for different displayed HTML elements, it is known as a client-side scripting language. Known as Netscape Navigator, it at the time could only show static HTML. As you might expect, the concept of such a scripting language resulted in browser wars among the major competitors in the browser development business back then, including Netscape Communications (now Mozilla), Microsoft, and others.
Every one of the major players sought to push through their own implementation of this scripting language, hence Netscape created JavaScript (really, Brendan Eich did), Microsoft built JScript, and so on. As you can picture, these implementations were somewhat different, hence development for web browsers was done per-browser using best-viewed-on stickers accompanying a web page. It immediately became evident that we required a standard, a cross-browser fix that would streamline the building of web pages and unite the development process. They devised what is known as ECMAScript.
There are several implementations — you could say dialects — of ECMAScript, a standardized scripting language specification that all modern browsers seek to support. The most often used one is JavaScript, the subject of this paper. ECMAScript has standardized many significant things since its first release; for those more interested in the intricacies, Wikipedia has a thorough list of standardized items for every version of the ECMAScript available. Although browser support for ECMAScript versions 6 (ES6) and higher is still lacking, it will be transpiled to ES5 to be completely supported.
Describe JavaScript here.
Let’s introduce some extremely crucial language traits that we need be aware of before going into JavaScript patterns so that we may completely understand the contents of this essay. Should someone ask you “What is JavaScript?” you might respond in some form between:
JavaScript supports first-class functions.
Since I came from a C/C++ background, this quality used to be difficult for me to understand when I was initially learning JavaScript. JavaScript treats functions as first-class citizens; so, you can give functions as parameters to other functions just as you would any other variable.
// we send in the function as an argument to be
// executed from inside the calling function
function performOperation(a, b, cb) {
var c = a + b;
cb(c);
}
performOperation(2, 3, function(result) {
// prints out 5
console.log("The result of the operation is " + result);
})JavaScript follows a prototype approach.
JavaScript supports objects, as is the case with many other object-oriented languages; among the first words that spring to me when considering objects is classes and inheritance. This is where it becomes a bit challenging since the language employs something known as prototype-based or instance-based inheritance instead of supporting classes in their plain English form.
The formal term class is just now, in ES6; so, the browsers still do not support this (remember, as of writing, the last completely supported ECMAScript version is 5.1). Though the name “class” is added into JavaScript, it still makes use of prototype-based inheritance under the hood.
In object-oriented programming, prototype-based programming is a method whereby behavior reuse — also known as inheritance — is accomplished by means of a process of reusing already-existing objects under delegation acting as prototypes. Once we reach the part on design patterns in the article, we will go further since many JavaScript design patterns exhibit this feature.
JavaScript Events Loops
Should you have JavaScript experience, you most certainly know the phrase callback function. A callback function — remember, JavaScript views functions as first-class citizens — is a function supplied as a parameter to another function and run following an event for those unfamiliar with the phrase. Usually, this is used for event subscription — that is, mouse click or keyboard button push.
Every time an event — which has a listener attached — fires — that otherwise the event is lost — a message is being delivered to a queue of messages being handled synchronistically, in a FIFO fashion. This is the event loop.
Every message on the queue serves a purpose connected with it. Once a message is dequeued, the runtime performs the function totally before handling any other message. This is to say, should a function include other function calls, they are all carried out before processing a fresh message from the queue. This is run-to- completion.
while (queue.waitForMessage()) {
queue.processNextMessage();
}A JavaScript design pattern
Design patterns, as I mentioned previously, are repeatable answers for often recurring software design challenges. Allow us to review some design pattern categories here.
Protosystems
How is one to establish a pattern? Suppose you identified a widely occurring issue and had your own original remedy, which is not internationally known and recorded. Every time you run across this issue, you utilize this fix; you believe it to be reusable and that the developer community might gain from it.
Does it develop right away into a pattern? Fortunately no. Usually, one may have solid code writing habits and just overlook something that seems to be a pattern while, in fact, it is not a pattern.
Opponents of patterns
An anti-pattern marks poor practice; a design pattern reflects good practice.
One could consider changing the Object class prototype as an anti-pattern. Almost all objects in JavaScript inherit from Object (remember that JavaScript utilizes prototype-based inheritance) hence consider a situation in which you changed this prototype. Every object that inherits from the object prototype — which would be most JavaScript objects — showcases changes to the prototype. There is a calamity just waiting here.
Categories of Design Patterns
Though other approaches can be used to classify design patterns, the most often used one is the following:
Creational design schemes
Patterns in structural design
Patterns of behavioral design
Concurrent design principles
Architectural designs with patterns
Creational Design Guidelines
These patterns address strategies for object generation that maximize object creation relative to a simple solution. The fundamental form of object generation could lead to design issues or more complexity in the design. Creational design patterns help to solve this via some control of object formation. Among the rather common design patterns in this category are:
Factory technique
Abstract manufacturer builder prototype
Singleton Patterns in Structural Design
These patterns deal with object relations. They guarantee that the whole system does not have to change along with one component if one changes. Among these, the most often occurring designs are:
Adapter Bridge Composite Decorator Facade Flyweight Shadow Behavioral Design Patterns
These kinds of patterns identify, apply, and enhance interactions among several items in a system. They guarantee that different portions of a system have coordinated knowledge. Common instances of these patterns are:
List of accountability
Command iterator mediator memento observer state strategy visitor concurrency design patterns
These kinds of design patterns address paradigms of multi-threaded programming. Among the rather well-known ones are:
Active object; nuclear reaction; scheduling architectural design patterns
Create architectural designs using patterns for specific usage. Among the most well-known are:
Model-View-Controllers, or MVC
MVP, or Model-View-Presenter:
MVVM, sometimes known as Model-View-ViewModel
We shall examine some of the previously described design patterns in more detail in the section that follows using examples to help to clarify them.
Designs Pattern Illustration
Every design pattern stands for a certain kind of solution for a particular kind of problem. There is no one universal set of rules that fits perfectly constantly. We have to find out whether a given pattern will really be valuable and when it will show benefit. Once we know the trends and situations they match best, we can quickly find whether or not a particular pattern fits a given problem.
Recall that using the incorrect pattern for a given problem could have negative consequences including needless code complexity, pointless overhead on performance, or maybe the emergence of a new anti-pattern.
These are all factors that should be taken into account while considering implementing a design pattern on our code. Every senior JavaScript developer should be familiar with some of the design patterns in JavaScript that we will review here.
Constructor pattern
In classical object-oriented languages, a constructor is a unique ability in a class which initializes an object with some set of default and/or sent-in data.
The three following are common JavaScript object building techniques:
// either of the following ways can be used to create a new object
var instance = {};
// or
var instance = Object.create(Object.prototype);
// or
var instance = new Object();Four methods — since ES3 — allow one to add properties to objects once they have been created. These include:
// supported since ES3
// the dot notation
instance.key = "A key's value";
// the square brackets notation
instance["key"] = "A key's value";
// supported since ES5
// setting a single property using Object.defineProperty
Object.defineProperty(instance, "key", {
value: "A key's value",
writable: true,
enumerable: true,
configurable: true
});
// setting multiple properties using Object.defineProperties
Object.defineProperties(instance, {
"firstKey": {
value: "First key's value",
writable: true
},
"secondKey": {
value: "Second key's value",
writable: false
}
});The curly braces and, when adding properties, the dot notation or square braces are the most often used methods of creating objects. Anyone having JavaScript experience has made use of them.
JavaScript supports constructors by use of a “new” keyword prefixed to a function call, however it does not support native classes as we just explained. This allows us to utilize the function as a constructor and start its attributes the same way we would in a conventional language constructor.
// we define a constructor for Person objects
function Person(name, age, isDeveloper) {
this.name = name;
this.age = age;
this.isDeveloper = isDeveloper || false;
this.writesCode = function() {
console.log(this.isDeveloper? "This person does write code" : "This person does not write code");
}
}
// creates a Person instance with properties name: Bob, age: 38, isDeveloper: true and a method writesCode
var person1 = new Person("Bob", 38, true);
// creates a Person instance with properties name: Alice, age: 32, isDeveloper: false and a method writesCode
var person2 = new Person("Alice", 32);
// prints out: This person does write code
person1.writesCode();
// prints out: this person does not write code
person2.writesCode();Facade Pattern
When we wish to establish an abstraction layer between what is on display and what is carried out behind the curtains, we apply the façade pattern. It is used when one wants an underlying item to be simpler or easier accessible.
Selectors from DOM modification tools including jQuery, Dojo, or D3 would be a perfect illustration of this trend. Using these libraries, you may have observed that they have rather strong selecting capabilities; you can write in sophisticated searches including:
jQuery(".parent .child div.span")It streamlines the selection features a lot; although on the surface it seems straightforward, there is a whole complicated logic applied beneath the hood for this to operate.
We also have to understand the balance between performance-simplicity. If more complexity isn’t worth it, it’s best to avoid it. Given their overall great success, the compromise in the case of the described libraries was well worth it.
Following Steps
Any seasoned JavaScript developer should be aware of the rather helpful tool design patterns offer. Particularly in the maintenance aspect of any project, knowing the intricacies about design patterns could prove quite helpful and save you a lot of time during the lifetime of any project. It could be rather beneficial to change and preserve systems built using design patterns that match the requirements of the system.
