JavaScript design patterns #3. The Facade pattern and applying it to React Hooks

JavaScript React

The essential thing when approaching design patterns is to utilize them in a way that improves our codebase. The above means that we sometimes can bend them to fit our needs. The Facade design pattern is commonly associated with object-oriented programming. That doesn’t change the fact that we can take its fundamentals and apply them to something else. In this article, we explore the Facade pattern both in a conventional setting and with React hooks.

The fundamentals of the facade pattern

The facade pattern aims to provide a simplified way to interact with multiple components by creating a single API. By masking the underlying interactions, it helps us to keep our code more readable. The facade pattern can also help us to group generic functionalities into a more specific context. It is especially useful in situations when our system is quite complex, and we can see some patterns in the way we interact with it.

Let’s say we have a set of classes and methods that we want to use.

We often might find ourselves wanting to execute the above methods in a particular order. Doing so multiple times across our codebase would violate the Don’t Repeat Yourself (DRY) principle. To avoid the above, we can create a Facade class. It can keep track of the dependencies and execute our methods in a particular order.

Now we have a simple way to use a more complex set of actions with a lot of different parts. We can use it in a straightforward way and keep our application more readable.

It is limiting in comparison to executing every method separately, but it provides consistency across our application. If at some point we decide to change the logic in our Facade, it affects every part of the application in which we’ve used it.

Using the Facade pattern with third-party functionalities

It is also a common approach to use a Facade to interact with a third-party library or some complex native functionalities. A good example of the above is the Fetch API. It can be considered to be low-level compared to libraries like axios. Let’s create a simplified interface that deals with some of its shortages. We want to:

  • automatically inject authentication tokens
  • parse the body of the response so that we don’t need to call   every time
  • throw an error if the request did not succeed

Now we have a class that wraps existing native functionalities with additional logic. You can easily expand it if you ever need some additional functionalities or if you need to adjust it for the API you use.

If you want to know more about the Fetch API, check out Comparing working with JSON using the XHR and the Fetch API

Applying the Facade principles to React Hooks

Even though the Facade pattern is usually referred to when using classes, we can use its principles when designing our custom React Hooks. First, let’s look at an example that might need some refactoring. Then, we are going to attempt to fix it by applying the Facade pattern.

Let’s look into an example that needs some refactoring:

The first thing we notice above is a lot of different hooks. It is not very readable and certainly not reusable. Even though the useState hook is very generic, we put it in a specific context. All of the hooks combined, give us the possibility of managing the table of the users. Due to all of the above, it is a perfect place to use some of the principles of the Facade design pattern.

We can easily group the above functionalities into custom hooks:

The only thing that’s left is to use our newly created Facade. By doing so, we make the component a lot lighter.

We also make it more testable by moving the logic outside of the component. Nowadays, packages like the react-testing-library have a set of tools for testing hooks.

The above helps us in multiple ways. It makes our code highly reusable, following the DRY principle. We can also easily modify it. If we ever decide to implement some state management, such as Redux, we would just need to adjust our custom hooks. Putting the logic of a component behind a Facade also simplifies the code a lot and makes it more readable.


The Facade design pattern proves to be very useful. With it, we can make our code cleaner and more reusable. In this article, we’ve gone through the fundamentals of what the Facade is. We’ve also written some examples of how it might be useful. Aside from using it conventionally, we’ve also implemented the concept of Facade in React Hooks. By doing the above, we’ve proven that the Facade is, in general, a concept worth looking into if we want to improve the quality of our code.

Series Navigation<< JavaScript design patterns #2. Factories and their implementation in TypeScriptJavaScript design patterns #4. Decorators and their implementation in TypeScript >>
Notify of
Newest Most Voted
Inline Feedbacks
View all comments
3 years ago

Great post, help me a lot to understand how facade pattern can be used in frontend part of the app. Thanks 😉

3 years ago

Totally disagree. Your Facades are hard to understand and won’t clean code. They clean part of the code at the cost of extra files and making somewhere else dirty. They also increase the expertise level of the codebase.

Uncle Bob
Uncle Bob
2 years ago
Reply to  Somebody

Agree with this, I feel like this adds a lot of unnecessary abstraction to the project.

2 years ago

I think the first Example HouseCleaningFacade is more like template pattern.

Last edited 2 years ago by windliang
Gerardo Lima
Gerardo Lima
1 year ago

Creating a class to provide a single function is how Go4 implemented this pattern … in Java — most likely because that language does not accept functions on the top level. As JavaScript / TypeScript doesn’t have the same constraint it just feels wrong to create a class for this purpose.