JSFeeds: anago.io - JavaScript design patterns #3. The Facade pattern and applying it to React Hooks

Monday, 9 December, 2019 UTC

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

Summary

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.

class Bed {
  makeTheBed() {
    console.log('The bed is ready');
  }
}

class AirFreshener {
  spray() {
    console.log('A nice smell spreads through the air')
  }
}

class TrashCan {
  takeOutTrash() {
    console.log('The trash is taken out')
  }
}

class Dishwasher {
  fill() {
    console.log('The dishwasher is filled');
  }
  wash() {
    console.log('The dishwasher is working');
    return new Promise((resolve) => {
      resolve();
    });
  }
  empty() {
    console.log('The dishwasher is empty');
  }
}

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.

class HoseCleaningFacade {
  constructor(bed, trashCan, airFreshener, dishwasher) {
    this.bed = bed;
    this.trashCan = trashCan;
    this.airFreshener = airFreshener;
    this.dishwasher = dishwasher;
  }

  cleanTheHouse() {
    this.bed.makeTheBed();
    this.trashCan.takeOutTrash();
    this.airFreshener.spray();

    this.dishwasher.fill();
    this.dishwasher.wash()
      .then(this.dishwasher.empty)
  }
}

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.

const houseCleaning = new HoseCleaningFacade(
  new Bed(),
  new TrashCan(),
  new AirFreshener(),
  new Dishwasher()
);

houseCleaning.cleanTheHouse();

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
```
response.json()
```
every time
throw an error if the request did not succeed

class API {
  constructor(authToken) {
    this.authToken = authToken;
  }
  constructHeaders() {
    const headers = new Headers();
    headers.set('Authorization', this.authToken);
    return headers;
  }
  handleResponse(response) {
    if (response.ok) {
      return response.json();
    } else {
      return Promise.reject({
        status: response.status,
        statusText: response.statusText
      });
    }
  }
  get(url, options) {
    return fetch(url, {
      headers: this.constructHeaders(),
      ...options,
    })
      .then(this.handleResponse);
  }
  post(url, options) {
    return fetch(url, {
      method: 'POST',
      headers: this.constructHeaders(),
      ...options,
    })
      .then(this.handleResponse);
  }
  put(url, options) {
    return fetch(url, {
      method: 'PUT',
      headers: this.constructHeaders(),
      ...options,
    })
      .then(this.handleResponse);
  }
  delete(url, options) {
    return fetch(url, {
      method: 'DELETE',
      headers: this.constructHeaders(),
      ...options,
    })
      .then(this.handleResponse);
  }
}

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.

const api = new API('my-auth-token');

api.get('https://jsonplaceholder.typicode.com/users/1')
  .then(data => {
    console.log('User data', data);
  })
  .catch(error => {
    console.error(error);
  });

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:

import React, { useState } from 'react';
import AddUserModal from './AddUserModal';
import UsersTable from './UsersTable';

const Users = () => {
  const [users, setUsers] = useState([]);

  const [isAddUserModalOpened, setAddUserModalVisibility] = useState(false);

  function openAddUserModal() {
    setAddUserModalVisibility(true);
  }

  function closeAddUserModal() {
    setAddUserModalVisibility(false);
  }

  function addUser(user) {
    setUsers([
      ...users,
      user
    ])
  }

  function deleteUser(userId) {
    const userIndex = users.findIndex(user => user.id === userId);
    if (userIndex > -1) {
      const newUsers = [...users];
      newUsers.splice(userIndex, 1);
      setUsers(
        newUsers
      );
    }
  }

  return (
    <>
      <button onClick={openAddUserModal}>Add user</button>
      <UsersTable
        users={users}
        onDelete={deleteUser}
      />
      <AddUserModal
        isOpened={isAddUserModalOpened}
        onClose={closeAddUserModal}
        onAddUser={addUser}
      />
    </>
  )
};

export default Users;

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:

function useUsersManagement() {
  const [users, setUsers] = useState([]);

  function addUser(user) {
    setUsers([
      ...users,
      user
    ])
  }

  function deleteUser(userId) {
    const userIndex = users.findIndex(user => user.id === userId);
    if (userIndex > -1) {
      const newUsers = [...users];
      newUsers.splice(userIndex, 1);
      setUsers(
        newUsers
      );
    }
  }

  return {
    users,
    addUser,
    deleteUser
  }
}

function useAddUserModalManagement() {
  const [isAddUserModalOpened, setAddUserModalVisibility] = useState(false);

  function openAddUserModal() {
    setAddUserModalVisibility(true);
  }

  function closeAddUserModal() {
    setAddUserModalVisibility(false);
  }
  return {
    isAddUserModalOpened,
    openAddUserModal,
    closeAddUserModal
  }
}

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.

import React from 'react';
import AddUserModal from './AddUserModal';
import UsersTable from './UsersTable';
import useUsersManagement from "./useUsersManagement";
import useAddUserModalManagement from "./useAddUserModalManagement";

const Users = () => {
  const {
    users,
    addUser,
    deleteUser
  } = useUsersManagement();
  const {
    isAddUserModalOpened,
    openAddUserModal,
    closeAddUserModal
  } = useAddUserModalManagement();

  return (
    <>
      <button onClick={openAddUserModal}>Add user</button>
      <UsersTable
        users={users}
        onDelete={deleteUser}
      />
      <AddUserModal
        isOpened={isAddUserModalOpened}
        onClose={closeAddUserModal}
        onAddUser={addUser}
      />
    </>
  )
};

export default Users;

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.

Summary

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.

The post JavaScript design patterns #3. The Facade pattern and applying it to React Hooks appeared first on Marcin Wanago Blog - JavaScript, both frontend and backend.

... more @ anago.io

anago.io