It's maybe a different perspective about design patterns
Tags: react, webdev, programming, discuss
Published: 2022-09-06 23:19:01


Have you ever been on a team where you don’t have like a clear idea about how to do an implementation of some feature? This is a common case as developer, also so many times we are working on similar features, always working with “objects” definitions, a new screen to handle a form, or doing a new request to get a list of data from the data base, all these cases are an example of where a design pattern is useful.

---

## What is a design pattern?

I understand a design pattern like:

> A defined approach to work when I’m working in some common functionality

I like this definition from `sourcemaking.com`

> In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern isn't a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations.

As engineers we like to know how to do the things, we need to understand what is the expected result from our work, there is where a design pattern helps us. We can imagine that we are working with so many incredible senior developers, and using their expertise, they propose a way to do our job, that is a design pattern, for us it is a define and optimized way to do our work.


## Types of design patterns

Exists a lot of design patterns, these can be classified in 3 types:

* **Creational**: Patterns designed for class or object instantiation
* **Structural**: Patterns about the structure and composition
* **Behavioral**: Patterns designed about how one class communicates with others

---

## Let’s talk about patterns in React.Js

React as UI library is a common way to compose a user-interface (UI) using JavaScript, when we work with React, we are going to create a whole UI by separating it into small reusable components, this is ****componentization****.

I’m going to introduce a couple of design patterns that I common use with React.

### Singleton Pattern

Singletons are classes that can be instantiated once, and can be accessed globally, this instance can be shared throughout our application.

If you are a React developer, probably you see some familiar behavior with global state managers, for example Redux, EasyPeasy, MobX, all of them are different ways to have a global state in our apps, its basically the singleton pattern, we are going to have a only instance for our state, and the state is shared across the entire app.

> did you see? the state management was a common problem in our applications, some developers understand that and fixed it using this design pattern

### Provider Pattern

In some cases, we want to make data available in some specific components, but maybe we don’t have a state manager library implemented, or we need to use a different approach. 

In React we can pass props far down the components tree, but exist a limitation if you required to pass props up in the components tree, its name is prop drilling.

In react you can create a new `context provider`, its an object to manage the context throughout the applications, to manipulate the context you can use a hook (useContext) to implement this provider pattern

### Container/Presentation Pattern

This is a way to enforce separations of concerns, the principle idea is to have separate the view from the application logic.

We can define **presentational components,** these are the components that take care about **how** to show data to the user, and also define **container components**, these are component that take care about **what** data is shown to the user.

If you think in a list of images, we can define a **container component** with all the logic to fetch data using an api service, and also define a **presentational component** with all the jsx code to displaying data.

### Hooks Pattern

This is my favorite! 😁

React 16.8 introduced a new feature called **Hooks.**

This pattern is derivation of **Container/Presentation pattern**, because is the same idea but implemented with hooks, so we are going to create a component with all the implementation about how to display the data, and then define a hook with all the logic related to the **presentational component**.

In this hook we can control everything related to logic, for example: interactions with services,  user events in the UI, or form validations.

### Other common design patterns

**HOC Pattern (higher order component)**, this pattern is a common way to reuse the same logic in multiple components, is used to add functionality or logic to components

**Proxy Pattern**, with this pattern we can define with more control the interactions in our objects. We can define functions over the object definition.

---

## Conclusion

At the end, Design Patterns is not something difficult to understand, they exists because when we are coding we are constantly resolving the same scenarios, and they give us a define and confirmed way to implement a solution.

**Sources**

Patterns: Stay up to date on the latest design and performance patterns. - [patterns.dev](https://www.patterns.dev/)

Source Making: I'm SourceMaking. I will tell you a lot of stories about good software… - [sourcemaking.com](https://sourcemaking.com/design_patterns)