Tech Career Guru

Patterns You Should Know in Frontend Development

There are so many different programming languages, architectures, and other issues to consider that it may be difficult to know where to begin when you start a new project. This is where design patterns come into play.

A design pattern is similar to a project template. It follows certain norms, and you may anticipate certain behaviors from it. These patterns were created by combining the experiences of numerous developers, thus they are essentially distinct sets of best practices.

Because they just provide a rough framework of a solution, programming design patterns may be used to any programming language and every project.

 

Design Patterns in frontend development

 

The book Design Patterns - Elements of Reusable Object-Oriented Software, which is regarded one of the most significant publications on object-oriented philosophy and software development, has 23 official patterns. But in this article I will cover the most known 4 design patterns.

 

The Singleton Design Pattern

The singleton pattern restricts a class or object to having a single instance and stores that instance in a global variable. You may use lazy loading to ensure that there is only one instance of the class since it will only be created when needed.

This prevents many instances from running at the same time, which might lead to strange issues. Most of the time, this is done in the constructor. The singleton pattern is generally used to control an application's global state.

Your logger is an example of a singleton that you most likely use all the time.

I recomment reading: What's the Best Workflow for a Frontend Dev?

If you've ever worked with a front-end framework like React or Angular, you know how difficult it can be to manage logs from numerous components. This is an excellent example of a singleton in action since you should never have more than one instance of a logger object, particularly if you're using an error tracking tool.

 

The Strategy Design Pattern

The strategy design pattern is similar to a more sophisticated form of an if else statement. It's essentially where you create an interface for a method in your base class. This interface is then utilized to determine which method implementation should be used in a derived class. In this situation, the implementation will be determined at runtime dependent on the client.

This technique is very handy when a class has both mandatory and optional methods. Some instances of the class will not need the optional methods, posing a difficulty for inheritance solutions. You could use interfaces for the optional methods, but you'd have to create the implementation every time you used that class since there'd be no default implementation.

That's when the strategy pattern comes in handy. Instead of seeking for an implementation, the client delegated to a strategy interface, and the strategy finds the appropriate implementation. Payment processing systems are a popular use for this.

You may have a shopping cart that exclusively accepts credit cards, but you would lose clients that want to utilize alternative payment methods.

 

The strategy design pattern allows us to detach payment methods from the checkout process, allowing us to add or change strategies without modifying any code in the shopping cart or checkout process.

 

The Observer Design Pattern

You've already utilized the observer design pattern if you've used the MVC pattern. The Model component is analogous to a subject, and the View component is analogous to an observer of that subject. Your subject is in charge of all of the data as well as the condition of that data. Then there are observers, which are separate components that will receive that data from the topic as it is updated.

The observer design pattern's purpose is to establish a one-to-many link between the subject and all of the observers who are waiting for data so they may be updated. As a result, if the status of the topic changes, all observers are immediately alerted and updated.

 

This pattern may be used for a variety of tasks such as providing user alerts, updating, filtering, and dealing with subscribers.

 

The Decorator Design Pattern

It's easy to use the decorator design pattern. A base class may contain methods and attributes that are available when you create a new object using the class. Assume you have some instances of the class that need methods or attributes that were not provided by the base class.

You may add those additional methods and attributes to the basic class, but doing so may cause problems with your other instances. You may even create sub-classes to house unique methods and attributes that aren't available in your main class.

Both ways will fix your issue, but they are cumbersome and inefficient. This is when the decorator pattern comes into play. Instead of making your code base unattractive merely to add a few things to an object instance, you may attach those particular items right to the instance.

I recomment reading: Is front end development stressful?

So, if you need to add a new property that stores the price for an object, you can use the decorator pattern to add it specifically to that object instance, and it will have no effect on any other instances of that class object.

Have you ever purchased food from a restaurant online? Then you've most likely come across the decorator pattern. If you purchase a sandwich and wish to add unique toppings, the website does not apply those toppings to every sandwich that existing users attempt to order.

 

Software Architecture Patterns in frontend development

 

In back-end development, several software architecture patterns are extensively investigated and utilized. Front-end, in addition to its comparatively brief history, lacks such well-established methodologies. 

Nonetheless, with the rising popularity of several front-end frameworks such as Angular, React, and others, numerous architectural best practices have emerged in recent years. Let's take a look at several patterns that are unavoidable in today's front-end applications.

 

MVC (Model-View-Controller)

MVC (Model-View-Controller) was one of the original designs proposed decades ago, in which you would strive to divide distinct responsibilities such as Presentation and Data Handling among separate actors. 

MVC variants such as MVP and MVVM emerge over time. MVC (and its predecessors) have had a significant impact on modern front-end development, while certain aspects have not changed (SoC for example). 

 

Separation of Concerns

SoC is a design principle in computer science that divides a computer program into different components, each of which tackles a particular topic. A concern is a collection of data that has an impact on the code of a computer program.

SoC is the main model that even the following patterns where made.

 

Modular Architecture

Using Angular Framework as an example, we can observe that the application is divided into modules depending on distinct domains. 

Each Module has its own NgModule, which are self-contained containers, which are all aggregated in AppModule: the mother of all modules. Core and Shared Modules are also crucial Modules to examine.

 

Micro Frontends

Micro-frontend architecture is a method that divides the previously monolithic frontend code into smaller applications, ideally that can be used in other projects. All of these smaller parts combine to build a unified frontend interface that provides an excellent user experience while being simple to adapt and extend.

This use case area either have responsible frontend team members or in big applications separate teams handling the end-to-end micro sections.

 

Component Architecture

This pattern is developed from SoC as well, and it is a more granular separation of distinct presentation units in components. This implies that if we had an UI listing books, we would need to build a book component with all of the required code to display the list of books. We'd have a .html file for the view, a .ts file for component-specific business logic, a .scss (or .css) file for style, and a .spec.ts file for testing in the book component folder.

 

State Management

Because one of the goals of SoC was to separate data processing from data presentation, it was quickly realized that all UI data could not be totally separated on the back-end. As a result, an additional instance in the front-end that maintains track of temporary data was required.

Based on this concept, there is now a data store instance called State Management in front-end frameworks. In React, it would be Redux, and in Angular, it would be NgRx (Actually, both base on Redux Pattern).

 

Unidirectional Architecture

This is mostly associated with reactive programming. In today's frontend frameworks, data flow is unidirectional and driven by data flow streams. The data only moves in one direction, which is towards the display. Different actions will be triggered as a result of the view. 

This provides you more control over your data. When dealing with data streams, several libraries like as RxJs, NgRx, and Flux provide a variety of functions.

 

Final thoughts

 

You could think of design patterns as wacky, far-fetched software development recommendations. That couldn't be farther from the truth!

Some of the patterns I discussed are utilized in so many different applications that it will blow your mind. At the end of the day, they are simply theories. It is our responsibility as developers to use that notion in ways that make our programs simple to construct and maintain.

Refrence https://webdev-tech.com