Как подписаться на изменения LocalStorage

2 года назад·3 мин. на чтение

Нередко возникает необходимость подписаться на изменения значений в LocalStorage. В этой статье напишем универсальную реализацию, которая не будет привязана к определенному фреймворку.

Иногда есть необходимость подписываться на изменения значений в LocalStorage и быстро на них реагировать. В этой статье напишем универсальную реализацию на JavaScript, которая не будет привязана к определенному фреймворку. Нужно будет просто добавить необходимую прослойку. В React этой прослойкой будет являться кастомный хук, отвечающий за подписку/отписку на событие внутри useEffect. Реализация будет состоять из нескольких частей:
  1. Реализация шины событий
  2. Класс-обертка для работы с LocalStorage
  3. Прослушивание нативного события storage
  4. Добавление в React-компонент

Шина событий

Есть множество паттернов для реализации отправки и прослушивания изменений объектов. Возьмем за основу паттерн Pub/Sub (Издатель/Подписчик) и реализуем класс для шины событий.
// EventBus.js

class EventBus {
  constructor() {
    this.topics = {};
  }

  notify(key, value) {
    this.topics[key]?.forEach((cb) => {
      cb(value);
    });
  }

  subscribe(key, cb) {
    if (!this.topics[key]) {
      this.topics[key] = [];
    }
    this.topics[key].push(cb);
  }

  unsubscribe(key, cb) {
    this.topics = this.topics[key]?.filter((_cb) => _cb !== cb);
  }
}

Класс-обертка для работы с LocalStorage

Сервис для работы localStorage будет содержать экземпляр шины событий. При установке нового значения по ключу мы будем оповещать подписчиков этого ключа и сохранять значение в localStorage . При помощи метода subscribe можно будет подписаться на изменения значений по переданному ключу. Этот метод также возвращает функцию для отписки. Метод getItem просто отдает значение из localStorage по ключу. В нем при необходимости можно реализовать логику парсинга для чтения объектов из localStorage.
// LocalStorageService.js

class LocalStorageService {
  constructor() {
    this.eventBus = new EventBus();
  }

  getItem(key) {
    return window.localStorage.getItem(key);
  }

  setItem(key, value) {
    const oldValue = this.getItem(key, value);
    if (oldValue === value) return; // если значение не изменилось - ничего не делаем

    window.localStorage.setItem(key, value);
    this.eventBus.notify(key, value);
  }

  subscribe(key, cb) {
    this.eventBus.subscribe(key, cb);
    return () => this.eventBus.unsubscribe(key, cb);
  }
}

// экспортируем экземпляр класса
export const localStorageService = new LocalStorageService();

Прослушивание нативного события storage

Это событие будет полезно если есть необходимость следить за изменением localStorage из другого документа, т.е. между вкладками. Это событие не отправляется при изменениях localStorage на той же странице. Оно будет полезно для общения разных страниц одного и того же домена. Страницы разных доменов не имеют доступа к localStorage друг друга. StorageEvent наследуется от класса Event и имеет следующие поля:
const storageEvent = {
  key: "token",              // ключ, значение которого изменилось
  newValue: "token_value_b", // новое значение
  oldValue: "token_value_a", // старое значение
  storageArea {              // объект хранилища со всеми ключами и их значениями
    token: "token_value_a",
    user_settings: "",
    length: 2
  },
  url: "http://localhost:3001/" // url документа, ключ которого изменился
}
Добавим подписку на событие storage.

class LocalStorageService {
  constructor() {
    this.eventBus = new EventBus();

    this.handleStorage = this.handleStorage.bind(this);     // свяжем функцию с контекстом
    window.addEventListener('storage', this.handleStorage); // подпишемся на событие storage 
  }

  // добавим функцию для обработки события storage
  handleStorage(event) {
    this.eventBus.notify(event.key, event.newValue);
  }

  //…
}
Теперь если продублировать приложение в соседней вкладке и изменить токен, обновленный токен появится и на первой вкладке. Если изменить значение ключа в localStorage вручную через devtools, то обновленное значение также появится и в интерфейсе приложения.

Добавление в React-компонент

Добавим кастомный хук useLocalStorageKey, который будет принимать ключ, значение которого будет прослушивать.
// useLocalStorageKey.js

import { useEffect, useState } from 'react';
import { localStorageService } from './LocalStorageService';

export const useLocalStorageKey = (key) => {
  const [value, setValue] = useState(localStorageService.getItem(key));

  useEffect(() => {
    const onUpdate = (newValue) => {
      setValue(newValue);
    };

    // возвращаем функцию очистки
    return localStorageService.subscribe(key, onUpdate);
  }, [key]);

  // функция для изменений значения по переданному ключу
  const setLocalStorageValue = (value) => {
    localStorageService.setItem(key, value);
  };

  return [value, setLocalStorageValue];
};
И добавим вызов хука в компонент. Две кнопки просто устанавливают разные значения токена.
import { useLocalStorageKey } from './useLocalStorageKey';

const KEY_TOKEN = 'token';

function App() {
  const [token, setToken] = useLocalStorageKey(KEY_TOKEN);

  const handleAddTokenAClick = () => {
    setToken('token_value_a');
  };

  const handleAddTokenBClick = () => {
    setToken('token_value_b');
  };

  return (
    <>
      <button type="button" onClick={handleAddTokenAClick}>
        Add token 'a'
      </button>

      <button type="button" onClick={handleAddTokenBClick}>
        Add token 'b'
      </button>

      <p>Token: {token}</p>
    </>
  );
}

export default App;
Исходный код

Многоуровневая архитектура React компонентов

год назад·4 мин. на чтение

Раскрываем секреты создания масштабируемых и поддерживаемых React компонентов

Сопровождаемость является важным аспектом любой системы. Он определяет, насколько легко система может быть обновлена. Система будет работать оптимально только в том случае, если все компоненты хорошо обслуживаются. Если ваш проект имеет хорошо поддерживаемую архитектуру, разработчики могут легко понять проект и внести точечные изменения, чтобы повысить производительность при одновременном сокращении циклов разработки, тестирования и выпуска. Архитектура проекта является ключевым фактором, определяющим простоту обслуживания компонентов проекта. Многоуровневая архитектура является одной из лучших архитектур для написания поддерживаемых компонентов для UI фреймворков, таких как React. Поэтому в этой статье мы обсудим, как использовать многоуровневую архитектуру для написания простых в обслуживании компонентов на React и каких ошибок следует избегать.

Что такое многоуровневая архитектура и зачем ее использовать?

Многоуровневая архитектура — это шаблон проектирования программного обеспечения, который организует приложение на несколько уровней, каждый из которых имеет определенный набор обязанностей. Эти слои организованы иерархически, при этом уровни более высокого уровня полагаются на слои более низкого уровня. Большинство многоуровневых архитектур имеют три или четыре стандартных уровня. Каждый слой может быть разработан и протестирован независимо в многоуровневой архитектуре, и изменения в одном слое не влияют на другие. Такое разделение позволяет разработчикам создавать организованные, модульные и масштабируемые системы, которые легче поддерживать и обновлять. Кроме того, такой подход позволяет вносить изменения в приложение без необходимости переписывать большие участки кода, снижая риск внесения ошибок или нарушения существующей функциональности. Давайте рассмотрим трехуровневую архитектуру в качестве примера, чтобы увидеть, как она может улучшить процесс разработки.

Трехуровневая архитектура

Вот эти три основных слоя: Презентационный слой (уровень представления, presentation layer) Уровень бизнес-логики (business logic layer, BLL) Уровень доступа к данным (data access layer, DAL) Уровень представления управляет взаимодействием с пользователем и представляет данные пользователю. Этот слой может представлять собой форму веб-интерфейса, десктопного или мобильного приложения. Он взаимодействует с уровнем бизнес-логики для выполнения действий и извлечения данных. Уровень бизнес-логики отвечает за реализацию бизнес-правил и рабочих процессов приложения. Этот уровень должен быть полностью независимым от уровня представления и не иметь представления о пользовательском интерфейсе. Он должен содержать всю логику и алгоритмы приложения и взаимодействовать с уровнем доступа к данным для получения необходимых данных. Уровень доступа к данным отвечает за взаимодействие с источниками данных приложения. Этот уровень отвечает за извлечение и хранение данных и должен быть отделен от уровня бизнес-логики. Он должен включать весь код, связанный с доступом к базе данных, вызовами API и другими внешними источниками данных.

Как использовать трехуровневую архитектуру в React

Давайте теперь рассмотрим, как мы можем применить принцип многоуровневой архитектуры к нашим React приложениям.

Уровень доступа к данным

Этот слой обычно реализуется в виде набора служебных функций (утилит), которые могут быть повторно использованы различными кастомными хуками. Рассмотрим следующую служебную функцию fetchData(), которая используется для получения данных из API.
export default async function fetchData() {
  const response = fetch('https://jsonplaceholder.typicode.com/users/1').then(
    (res) => {
      if (res.ok) return res.json();
      return Promise.reject(res);
    }
  );
  return response;
}
Эту функцию можно использовать на уровне бизнес-логики всякий раз, когда вам нужно получить данные API без написания дублирующегося кода. Вы можете передавать URL-адрес через аргумент и изменять функцию по мере роста проекта. При тестировании вызовов API вы можете вызвать эту функцию с фиктивными данными, чтобы упростить процесс.

Уровень бизнес-логики

Этот слой обычно реализуется в виде набора пользовательских хуков, которые можно повторно использовать в разных компонентах. Рассмотрим следующий пользовательский хук seUserData(), который используется для получения данных о пользователе.
import React from "react";
import fetchData from "../util/fetchData";

const useUserData = () => {
  const [userData, setUserData] = useState([]);
  useEffect(() => {
    fetchData()
      .then((data) => setUserData(data))
      .catch((res) => console.error(res.status));
  }, []);
  return [userData];
};

export default useUserData;
Как видите, здесь вызывается функция fetchData() из слоя доступа к данным. Чтобы сделать этот хук более переиспользуемым, передайте путь URL-адреса в качестве аргумента кастомному хуку и передайте его в функцию fetchData().

Презентационный слой

Уровень представления должен содержать все компоненты пользовательского интерфейса, отвечающие за отрисовку данных и реагирование на действия пользователя в приложении React. В этих компонентах не должно быть бизнес-логики или кода запроса данных. Взглянем на пример компонента UserProfile ниже.
import React from "react";
import useUserData from "./customHooks/useUserData";

const UserProfile = () => {
  const [userData] = useUserData();
  return (
    <div>
      {userData.id ? (
        <div>
          <ul> {userData.name} </ul>
          <ul> {userData.email} </ul>
        </div>
      ) : (
        <p>Loading data...</p>
      )}
    </div>
  );
}

export default UserProfile;
Пользовательский хук useUserData() используется в компоненте для взаимодействия с уровнем бизнес-логики и получения пользовательских данных для отображения пользователю. Помимо функции return, единственное, что должно быть включено в UI компоненты, как показано в этом примере, — это вызовы функций для уровня бизнес-логики. Это дает вам четкие UI компоненты, что значительно упрощает поиск и исправление ошибок, связанных с пользовательским интерфейсом.

Ошибки, которых следует избегать при использовании многоуровневой архитектуры

  • Переусложнение — поддерживайте простую и масштабируемую архитектуру и отказывайтесь от использования подходов, которые не соответствуют шаблонам React, таких как подходы на основе наследования.
  • Сильная связанность — когда слои плотно связаны, то заменить один, не затрагивая другие, может быть стать сложной задачей. Уменьшите связанность, используя соответствующие шаблоны и методы, такие как внедрение зависимостей и интерфейсы.
  • Игнорирование производительности — при неправильной реализации многоуровневая архитектура может повлиять на производительность приложения. При оптимизации архитектуры для повышения производительности учитывайте такие факторы, как разделение кода, отложенная загрузка и кэширование.
  • Плохие соглашения об именах — используйте четкие и согласованные соглашения об именах для слоев, компонентов и функций. В противном случае разработчикам будет сложно понять и поддерживать код в долгосрочной перспективе.
  • Отсутствие тестирования — каждый слой должен быть тщательно протестирован, чтобы убедиться, что он работает должным образом. Неспособность протестировать каждый слой может привести к ошибкам и другим проблемам в приложении.
  • Отсутствие связности — каждый слой должен иметь высокую степень связности. Связность относится к тому, насколько тесно связаны функции и обязанности внутри слоя. Низкая связность может привести к тому, что код будет трудно понять и поддерживать.

Итоги

React не предлагает конкретную архитектуру. Следовательно, разработчики несут ответственность за выбор подходящей архитектуры, которая способствует сопровождению кода в долгосрочной перспективе. В этой статье мы рассмотрели использование многоуровневой архитектуры для создания React компонентов с высокой степенью сопровождения и распространенные ошибки, которых следует избегать.