Где должна быть бизнес-логика в React приложении

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

• Структура React приложения
• Архитектура современного React приложения

В этой статье мы подробно рассмотрим работу с бизнес-логикой. Во многих случаях разработчики пишут бизнес логику прямо в компонентах. Даже опытные разработчики ограничиваются вынесением этих вычислений в кастомные хуки или какие-либо вспомогательные функции. Но все еще это оставляет проблему нерешенной. Дело в том, что даже если у нас есть более мелкие компоненты и логика перемещена в хуки или хэлперы, они буквально разбросаны повсюду неорганизованно. Возьмем, к примеру, приложение онлайн магазина, если мы хотим изменить логику в cart, скорее всего, нам также придется изменить модули product и validation. И нам обычно приходится менять как хэлперы, так и представления (не говоря уже о связанных с ними тестах).

Как обстоят дела в React

Рассмотрим проблему на более высоком уровне. Если вы внимательно посмотрите на React и согласитесь, что он отвечает только за визуальную часть нашего приложения, многие проблемы будут решены автоматически. Независимо от того, используем ли мы традиционные шаблоны MVC/MVP или их вариант MVVM, если React — это V, очевидно, нам нужно что-то еще, чтобы заполнить роль M или VM в приложении. Среди многих проектов я также обнаружил, что многие хорошие практики, которые мы используем в бэкенде, не признаны в мире фронтенда, такие как слоеная структура, паттерны проектирования и т. д. Одна из возможных причин заключается в том, что фронтенд относительно молодой и ему нужно некоторое время, чтобы наверстать упущенное. Например, в типичном приложении Spring MVC у нас были бы controller, service и repository, и каждый разработчик принимает причину такого разделения: controller не содержит бизнес-логики, service не знает, как модель отображается или сериализуется для пользователей, а repository работает только о доступом к данным. Однако во фронтенд-приложениях на React из-за отсутствия встроенной поддержки (например, отсутствия контроллеров или слоя репозитория) мы вместо этого пишем этот код в компоненты. И это приведет к тому, что бизнес-логика будет повсюду. Итерации станут медленными, а качество кода низким.

Утечка бизнес-логики

Мы можем назвать эту ситуацию утечкой бизнес-логики, имея в виду, что бизнес-логика должна была быть размещена в правильное место, и по какой-то причине была размещена неправильно. Хотя у нас нет подходящего механизма для правильного размещения, в результате бизнес логика написана везде где удобно (в компонентах, хуках и вспомогательных функциях). Сложно уловить такую утечку в коде. Вы должны уделять больше внимания, чтобы увидеть такие ситуации. Вот несколько распространенных симптомов, которые я обнаружил:

• Использование преобразователей данных
• x.y.z
• Защитное программирование

Использование преобразователей данных

Эту паттерн легко обнаружить: если вы делаете map для преобразования данных, вы, вероятно, пересекаете два ограниченных контекста (что может привести к утечке логики). Мы все видели или, возможно, писали такой код, как:

fetch(`https://example.com/api/addresses`)
.then((r) => r.json())
.then((data) => {
    const addresses = data.map((item: RemoteAddress) => ({
        street: item.streetName,
        address: item.streetAddress,
        postcode: item.postCode
    }))
    setAddresses(addresses)
});

В приведенном выше фрагменте то, что возвращает бэкэнд, не совсем соответствует тому, что потребляет UI, поэтому нам нужно преобразовать полученные данные. Мы можем использовать сервис, разработанный другой командой, или использовать сторонний сервис (например, Google Search API). Таким образом, казалось бы, безобидный код нарушил здесь несколько принципов:

• Компонент должен знать тип RemoteAddress
• Компоненту необходимо определить новый тип Address (setAddresses)
• data.map выполняет низкоуровневое сопоставление

Симптом x.y.z (нарушение закона Деметры)

Если вы используете более одного оператора точки ., вероятно, это означает, что отсутствуют некоторые концепции. person.deliveryAddress лучше, чем person.primaryAddress.street.streetNumber + person.primaryAddress.suburb так как первый вариант правильно скрывает детали. Приведенный ниже код показывает, что ProductDialog слишком много знает о product, и как только структура product изменится, нам придется менять множество мест (тесты и компоненты)

const ProductDialog = (props) => {
  const { product } = props;
  if(product.item.type === 'Portion') {
    //do something
  }
}

Здесь мы имеем дело с данными, а не с моделью. Таким образом, product.isPortion() будет более значимым, чем проверка необработанных данных.

Защитное программирование

Во многих проектах люди склонны делать слишком много в компоненте, и это создает много шума в коде. Например:

const ProductDetails = (props) => {
  const { product } = props
  const { item } = product
  const { media } = item as MenuItem
  
  const title = (media && media.name) || ''
  const description = (media && media.description) || ''
  return (
    <div>
      {/* product details */}
    </div>
  )
}

Обратите внимание, что мы проверяем на null и предоставляем запасное значение в компоненте. Однако мы должны выполнять этот тип логики в специально отведенном месте.

Как решить проблему?

На практике мы можем попробовать двухэтапный подход к решению проблемы.

1. Регулярный рефакторинг
2. Создание моделей

Регулярный рефакторинг

Во-первых, мы можем выполнить рефакторинг, как обычно в других случаях, когда мы видим некоторую логику в компонентах React. Например, переместив логику/вычисления из:

• Использования преобразователей данных
• x.y.z
• Защитного программирования

во вспомогательные функции. Возьмем, к примеру, преобразователь данных выше. Мы можем извлечь анонимную функцию в именованную функцию и переместить ее в отдельный файл:

const transformAddress: Address = (address: RemoteAddress) => {
    return ({
        street: datum.streetName,
        address: datum.streetAddress,
        postcode: datum.postCode
    })
}
//...
const addresses = data.map(transformAddress)

Также иногда бывает нужно преобразовать аббревиатуры в текст такие как VIC или NSW, но нам нужно показать их в полном тексте на странице как Victoria или New South Wales.

const states = {
  vic: "Victoria",
  nsw: "New South Wales",
  //...
};

const transformAddress: Address = (address: RemoteAddress) => {
  return {
    street: address.streetName,
    address: address.streetAddress,
    postcode: address.postCode,
    state: states[address.state.toLowerCase()]
  };
};

Точно так же мы можем использовать функцию, для проверки title и description и вывода запасного значения:

const getTitle = (media) => (media && media.name) || ''
const getDescription = (media) => (media && media.description) || ''

По мере добавления все больше и больше логики, такой transformAddress и getTitle, они будут перемещаться в helpers.ts, в конечном итоге у нас будет огромный файл. Это означает, что он станет нечитаемым и будет иметь высокие затраты на обслуживание. Мы можем разделить файл на модули, но связи между этими функциями могут затруднить их понимание. Это похоже на проблему, с которой мы сталкивались до объектно-ориентированного программирования - у нас слишком много модулей и функций в каждом модуле, и слишком сложно ориентироваться в них. Другими словами, нам нужен лучший способ организации этих вспомогательных функций. К счастью, нам не нужно изобретать велосипеды. Нам может помочь объектно-ориентированное программирование. Просто используя классы и инкапсуляцию в ООП, мы можем легко сгруппировать эти функции и сделать код намного более читабельным. Чтобы сгруппировать код создадим модели.

Создание моделей

Короче говоря, создание моделей — это объединение данных и поведения, сокрытие деталей и обеспечение общего API для потребителей. Например, мы не должны использовать product.item.type === 'Portion', вместо этого мы должны создать класс Product, и у него есть isPortion для их потребителей. Это очень распространено в бэкенд-сервисах, но не получило широкого распространения в мире фронтенда. Причина в том, что, как упоминалось выше, люди упускают из виду, что React отвечает только за визуализацию. И здоровое фронтенд-приложение должно иметь и другие части. Ему нужны модели и логика для взаимодействия с серверной частью, даже для ведения логирования. Возвращаясь к приведенному выше примеру, определив класс Address для замены анонимной функции внутри data.map, мы получим:

class Address {
  constructor(private addr: RemoteAddress) {}
  get street() {
    return this.addr.streetAddress;
  }
  get postcode() {
    return this.addr.postcode;
  }
}

Нет никакой разницы в использовании:

const AddressLine = ({ address }: { address: Address }) => (
  <li>
    <div className="result">{address.street}</div>
  </li>
);

Единственное, что нужно изменить, это заменить transformAddress на new Address:

const addresses = data.map((addr: RemoteAddress) => new Address(addr))

И для частного члена/функции для перевода названия штата:

private readonly states = {
  vic: "Victoria",
  nsw: "New South Wales",
  //...
};

get state() {
  return this.states[this.addr.state.toLowerCase()];
}

Структура теперь намного точнее. states теперь является приватным членом класса Address. Класс хорош тем, что он объединяет всю связанную логику в одну часть, что делает его изолированным и простым в обслуживании. Размещение всей связанной логики в одном месте имеет и другие преимущества. Во-первых, такое разделение делает тестирование простым и надежным, поскольку компоненты зависят от модели (а не от исходных данных). Нам не нужно готовить данные с нулевым значением или значения вне границ предусмотренных значений для тестов компонентов. Точно так же модель тестирования больше фокусируется на данных и логике (пустое значение, проверка и запасное значение). Во-вторых, согласованность повышает вероятность его повторного использования в других сценариях. Наконец, если нам нужно переключиться на другую стороннюю службу, нам нужно только изменить модели, и представления могут остаться нетронутыми. По мере того, как создается все больше и больше моделей, нам может понадобиться целый слой для них. Эта часть кода не знает о существовании компонентов пользовательского интерфейса и связана исключительно с бизнес-логикой.

Итоги

Инкапсуляция бизнес-логики, даже в контексте тонких клиентов, является относительно большой темой. В этой статье мы рассмотрели несколько симптомов утечки бизнес-логики и то, как с ними бороться. Проводя регулярный рефакторинг, мы можем гарантировать, что компоненты отвечают только за рендеринг данных и не должны выполнять какие-либо вычисления или сопоставление данных. Мы должны разделить эту логику на чистые файлы JavaScript (а не jsx/tsx). И с помощью создания моделей мы можем использовать объекты только для того, чтобы скрыть детали доступа к данным. Преимущества этого подхода заключаются в том, что тестирование как модели, так и представлений значительно упрощается, легче отслеживать изменения бизнес-требований и гораздо более простой код в представлениях (поскольку большая часть этого делается в моделях).

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

Когда обычной переменной недостаточно

Вот компонент, который рендерит изображение скульптуры. Нажатие кнопки «Далее» должно отобразить следующую скульптуру, изменив индекс на 1, затем на 2 и так далее. Однако это не сработает:

// App.jsx

import { sculptureList } from './data.js';

export default function Gallery() {
  let index = 0;

  function handleClick() {
    index = index + 1;
  }

  let sculpture = sculptureList[index];
  return (
    <>
      <button onClick={handleClick}>Next</button>
      <h2>
        <i>{sculpture.name} </i>
        by {sculpture.artist}
      </h2>
      <h3>
        ({index + 1} of {sculptureList.length})
      </h3>
      <img src={sculpture.url} alt={sculpture.alt} />
      <p>{sculpture.description}</p>
    </>
  );
}

// data.js

export const sculptureList = [
  {
    name: 'Sculpture 1 Name',
    artist: 'Sculpture 1 Artist',
    description: 'Sculpture 1 Description',
    url: 'https://example.com/sculpture1.jpg',
    alt: 'Sculpture 1 Description',
  },
  {
    name: 'Sculpture 2 Name',
    artist: 'Sculpture 2 Artist',
    description: 'Sculpture 2 Description',
    url: 'https://example.com/sculpture2.jpg',
    alt: 'Sculpture 2 Description',
  },
];

Обработчик события handleClick обновляет локальную переменную index. Но две вещи препятствуют тому, чтобы это изменение было видимым:

1. Локальные переменные не сохраняются между рендерами. Когда React рендерит этот компонент во второй раз, он рендерит его с нуля — он не учитывает никаких изменений в локальных переменных.
2. Изменения локальных переменных не вызовут рендеринга. React не понимает, что ему нужно снова визуализировать компонент с новыми данными.

Чтобы обновить компонент новыми данными, должны произойти две вещи:

1. Данные между рендерами должны сохраняться.
2. Нужно заставить React отрендерить компонент с новыми данными (повторный рендеринг).

Хук useState предоставляет две вещи:

1. Переменную состояния для сохранения данных между рендерами.
2. Функцию установки состояния для обновления переменной и запуска React для повторного рендеринга компонента.

Добавление переменной состояния

Чтобы добавить переменную состояния, импортируйте useState из React в начало файла:

import { useState } from 'react';

Затем замените эту строку:

let index = 0;

на эту:

const [index, setIndex] = useState(0);

index — это переменная состояния, а setIndex — функция установки состояния. Синтаксис [ и ] называется деструктурированием массива и позволяет считывать значения из массива. Массив, возвращаемый useState, всегда содержит ровно два элемента. Вот как они работают вместе в handleClick:

function handleClick() {
  setIndex(index + 1);
}

Теперь нажатие кнопки «Далее» переключает текущее изображение:

// App.jsx

import { useState } from 'react';
import { sculptureList } from './data.js';

export default function Gallery() {
  const [index, setIndex] = useState(0);

  function handleClick() {
    setIndex(index + 1);
  }

  let sculpture = sculptureList[index];
  return (
    <>
      <button onClick={handleClick}>Next</button>
      <h2>
        <i>{sculpture.name} </i>
        by {sculpture.artist}
      </h2>
      <h3>
        ({index + 1} of {sculptureList.length})
      </h3>
      <img src={sculpture.url} alt={sculpture.alt} />
      <p>{sculpture.description}</p>
    </>
  );
}

Встречайте свой первый хук

В React useState, как и любая другая функция, начинающаяся с «use», называется хуком. Хуки — это специальные функции, которые доступны только во время рендеринга React (о чем мы поговорим подробнее на следующей странице). Они позволяют вам «подключаться» к различным функциям React. Состояние — это только одна из этих функций, но позже вы познакомитесь с другими хуками. Хуки — функции, начинающиеся с use — могут вызываться только на верхнем уровне ваших компонентов или ваших собственных кастомных хуков. Вы не можете вызывать хуки внутри условий, циклов или других вложенных функций. Хуки — это функции, но полезно думать о них как о безусловных декларациях о потребностях вашего компонента. Вы используете (use) функции React в верхней части вашего компонента, подобно тому, как вы «импортируете» модули в верхней части вашего файла.

Как устроен useState?

Когда вы вызываете useState, вы сообщаете React, что хотите, чтобы этот компонент что-то запомнил:

const [index, setIndex] = useState(0);

В этом случае вы хотите, чтобы React запомнил index. По соглашению эта пара именуется как const [something, setSomething]. Вы можете назвать их как угодно, но соглашения облегчают понимание разных проектов. Единственный аргумент useState — это начальное значение вашей переменной состояния. В этом примере начальное значение индекса устанавливается равным 0 с помощью useState(0). Каждый раз, когда ваш компонент рендерится, useState предоставляет вам массив, содержащий два значения:

1. Переменная состояния (index) со значением, которое вы сохранили.
2. Функция установки состояния (setIndex), которая может обновлять переменную состояния и запускать React для повторного рендеринга компонента.

Вот как это происходит в действии:

const [index, setIndex] = useState(0);

1. Ваш компонент отображается в первый раз. Поскольку вы передали 0 в useState в качестве начального значения для index, он вернет [0, setIndex]. React помнит, что 0 — это последнее значение состояния.
2. Вы обновляете состояние. Когда пользователь нажимает кнопку, он вызывается setIndex(index + 1). index равен 0, поэтому это setIndex(1). Это говорит React запомнить, что index теперь равен 1, и запускается другой рендеринг.
3. Второй рендер вашего компонента. React по-прежнему видит useState(0), но поскольку React запомнил, что вы установили index равным 1, вместо этого он возвращает [1, setIndex].

И т.д.

Несколько переменных состояния в компоненте

В одном компоненте вы можете иметь столько переменных состояния любого типа, сколько захотите. Этот компонент имеет две переменные состояния, числовой index и логическое значение showMore, которое переключается, когда вы нажимаете "Show details":

import { useState } from 'react';
import { sculptureList } from './data.js';

export default function Gallery() {
  const [index, setIndex] = useState(0);
  const [showMore, setShowMore] = useState(false);

  function handleNextClick() {
    setIndex(index + 1);
  }

  function handleMoreClick() {
    setShowMore(!showMore);
  }

  let sculpture = sculptureList[index];
  return (
    <>
      <button onClick={handleNextClick}>Next</button>
      <h2>
        <i>{sculpture.name} </i>
        by {sculpture.artist}
      </h2>
      <h3>
        ({index + 1} of {sculptureList.length})
      </h3>
      <button onClick={handleMoreClick}>
        {showMore ? 'Hide' : 'Show'} details
      </button>
      {showMore && <p>{sculpture.description}</p>}
      <img src={sculpture.url} alt={sculpture.alt} />
    </>
  );
}

Рекомендуется иметь несколько переменных состояния, если их состояние не связано, например index и showMore в этом примере. Но если вы обнаружите, что часто меняете две переменные состояния вместе, может быть лучше объединить их в одну. Например, если у вас есть форма с множеством полей, удобнее иметь одну переменную состояния, которая содержит объект, чем переменную состояния для каждого поля. В руководстве "Какую структуру состояния выбрать" содержится больше советов по этому вопросу.

Как React узнает, какое состояние вернуть?

Вы могли заметить, что вызов useState не получает никакой информации о том, на какую переменную состояния он ссылается. В useState не передается «идентификатор», так как же он узнает, какую из переменных состояния следует вернуть? Чтобы обеспечить лаконичный синтаксис, хуки полагаются на стабильный порядок вызовов при каждом рендеринге одного и того же компонента. Это хорошо работает на практике, потому что если вы будете следовать правилу выше («вызывать хуки только на верхнем уровне»), хуки всегда будут вызываться в одном и том же порядке. Кроме того, linter плагин отлавливает большинство ошибок. Внутри React хранит массив пар состояний для каждого компонента. Он также поддерживает индекс для текущуй пары, который перед рендерингом устанавливается в 0. Каждый раз, когда вы вызываете useState, React предоставляет вам следующую пару состояний и увеличивает индекс.

В следующем примере не используется React, но он дает представление о внутренней работе useState:

let componentHooks = [];
let currentHookIndex = 0;

// Как useState работает внутри React (упрощенно).
function useState(initialState) {
  let pair = componentHooks[currentHookIndex];
  if (pair) {
    // Это не первый рендер,
    // поэтому пара состояний уже существует.
    // Верните его и приготовьтесь к следующему хуку.
    currentHookIndex++;
    return pair;
  }

  // Это первый рендеринг,
  // поэтому создаем пару состояния и сохраняем ее.
  pair = [initialState, setState];

  function setState(nextState) {
    // Когда пользователь запрашивает изменение состояния,
    // помещаем новое значение в пару.
    pair[0] = nextState;
    updateDOM();
  }

  // Сохраняем пару для будущих рендеров
  // и подготовимся к следующему вызову хука.
  componentHooks[currentHookIndex] = pair;
  currentHookIndex++;
  return pair;
}

function Gallery() {
  // Каждый вызов useState() будет получать следующую пару.
  const [index, setIndex] = useState(0);
  const [showMore, setShowMore] = useState(false);

  function handleNextClick() {
    setIndex(index + 1);
  }

  function handleMoreClick() {
    setShowMore(!showMore);
  }

  let sculpture = sculptureList[index];
  // В этом примере не используется React,
  //поэтому вернем объект вместо JSX.
  return {
    onNextClick: handleNextClick,
    onMoreClick: handleMoreClick,
    header: `${sculpture.name} by ${sculpture.artist}`,
    counter: `${index + 1} of ${sculptureList.length}`,
    more: `${showMore ? 'Hide' : 'Show'} details`,
    description: showMore ? sculpture.description : null,
    imageSrc: sculpture.url,
    imageAlt: sculpture.alt,
  };
}

function updateDOM() {
  // Сбросить текущий индекс хука
  // перед рендерингом компонента.
  currentHookIndex = 0;
  let output = Gallery();

  // Обновить DOM, чтобы он соответствовал выходным данным.
  // Это та часть, которую React делает за вас.
  nextButton.onclick = output.onNextClick;
  header.textContent = output.header;
  moreButton.onclick = output.onMoreClick;
  moreButton.textContent = output.more;
  image.src = output.imageSrc;
  image.alt = output.imageAlt;
  if (output.description !== null) {
    description.textContent = output.description;
    description.style.display = '';
  } else {
    description.style.display = 'none';
  }
}

let nextButton = document.getElementById('nextButton');
let header = document.getElementById('header');
let moreButton = document.getElementById('moreButton');
let description = document.getElementById('description');
let image = document.getElementById('image');
let sculptureList = [
  {
    name: 'Sculpture 1 Name',
    artist: 'Sculpture 1 Artist',
    description: 'Sculpture 1 Description',
    url: 'https://example.com/sculpture1.jpg',
    alt: 'Sculpture 1 Description',
  },
  {
    name: 'Sculpture 2 Name',
    artist: 'Sculpture 2 Artist',
    description: 'Sculpture 2 Description',
    url: 'https://example.com/sculpture2.jpg',
    alt: 'Sculpture 2 Description',
  },
];

// Сделать интерфейс соответствующим начальному состоянию.
updateDOM();

Вам не нужно понимать это, чтобы использовать React, но вы можете найти полезную ментальную модель.

Состояние изолировано и приватно

Состояние является локальным для экземпляра компонента на экране. Другими словами, если вы рендерите один и тот же компонент дважды, каждая копия будет иметь полностью изолированное состояние. Изменение одного из них не повлияет на другой. В этом примере ранее компонент Gallery визуализируется дважды без каких-либо изменений в его логике.

import Gallery from './Gallery.js';

export default function Page() {
  return (
    <div className="Page">
      <Gallery />
      <Gallery />
    </div>
  );
}

Это то, что отличает состояние от обычных переменных, которые вы можете объявить в верхней части вашего модуля. Состояние не привязано к конкретному вызову функции или месту в коде, но оно «локально» для определенного места на экране. Мы отрендерили два компонента <Gallery />, поэтому их состояние сохраняется отдельно.

Также обратите внимание на то, что компонент Page ничего не «знает» о состоянии Gallery и даже о том, есть ли оно у него. В отличие от пропсов, состояние полностью приватно для компонента, объявляющего его. Родительский компонент не может его изменить. Это позволяет добавлять состояние к любому компоненту или удалять его, не затрагивая остальные компоненты. Что, если вы хотите, чтобы обе галереи синхронизировали свои состояния? Правильный способ сделать это в React — удалить состояние из дочерних компонентов и добавить его к их ближайшему общему родителю. Следующие несколько частей будут посвящены организации состояния одного компонента, но мы вернемся к этой теме в разделе "Обмен данными между компонентами".

Резюме

• Используйте переменную состояния, когда компоненту необходимо «запомнить» некоторую информацию между рендерами.
• Переменные состояния объявляются путем вызова хука useState.
• Хуки — это специальные функции, которые начинаются с use. Они позволяют вам «подключаться» к возможностям React, таким как состояние.
• Вызов хуков, включая useState, действителен только на верхнем уровне компонента или другого хука.
• Хук useState возвращает пару значений: текущее состояние и функцию для его обновления.
• Вы можете иметь более одной переменной состояния. Внутри React сопоставляет их по порядку.
• Состояние является приватным для компонента. Если вы рендерите его в двух местах, каждая копия получает свое состояние.