Хорошие практики и шаблоны проектирования для Vue Composables

Эти соглашения важны для того, чтобы компоненты были удобными в обслуживании, легко тестируемыми и действительно полезными.

Общие шаблоны проектирования

На мой взгляд, лучшим источником информации о шаблонах для создания composables на самом деле является документация Vue.js, с которой вы можете ознакомиться здесь.

Базовый composable

В документации Vue показан следующий пример компонуемого useMouse:

// mouse.js
import { ref, onMounted, onUnmounted } from 'vue'

// по соглашению имена composable функций начинаются с "use"
export function useMouse() {
  // состояние инкапсулировано и управляется самим composable
  const x = ref(0)
  const y = ref(0)

  // composable может обновлять состоянием
  function update(event) {
    x.value = event.pageX
    y.value = event.pageY
  }

  // composable также может иметь доступ к жизненному циклу родительского компонента
  // для установки и очистки эффектов
  onMounted(() => window.addEventListener('mousemove', update))
  onUnmounted(() => window.removeEventListener('mousemove', update))

  // отдаем состояние наружу как возвращаемое значение
  return { x, y }
}

Позже это можно использовать в компоненте следующим образом:

<script setup>
import { useMouse } from './mouse.js'

const { x, y } = useMouse()
</script>

<template>Mouse position is at: {{ x }}, {{ y }}</template>

Асинхронные composables

Для получения данных Vue рекомендует следующую компонуемую структуру:

import { ref, watchEffect, toValue } from 'vue'

export function useFetch(url) {
  const data = ref(null)
  const error = ref(null)

  watchEffect(() => {
    // обнуляем состояние перед запросом
    data.value = null
    error.value = null

    // toValue() разворачивает потенциальные рефы или геттеры
    fetch(toValue(url))
      .then((res) => res.json())
      .then((json) => (data.value = json))
      .catch((err) => (error.value = err))
  })

  return { data, error }
}

Затем это можно использовать в компоненте следующим образом:

<script setup>
import { useFetch } from './fetch.js'

const { data, error } = useFetch('...')
</script>

Соглашения composable

Основываясь на приведенных выше примерах, вот контракт, которому должны следовать все composables:

1. Имена composable файлов должны начинаться с use, например useSomeAmazingFeature.ts
2. Он может принимать входные аргументы, которые могут быть примитивными типами, такими как строки, или может принимать ссылки и геттеры, но для этого требуется использовать вспомогательное средство toValue
3. Composable должен возвращать значение ref, к которому можно получить доступ после деструктурирования composable, например const { x, y } = useMouse()
4. Composables могут содержать глобальное состояние, к которому можно получить доступ и изменить в приложении.
5. Composable может вызвать побочные эффекты, такие как добавление прослушивателей событий окна, но их следует очищать при отключении компонента.
6. Composables следует вызывать только в <script setup> или в хуке setup(). В этих контекстах их также следует называть синхронно. В некоторых случаях их также можно вызывать в обработчиках жизненного цикла, таких как onMounted()
7. Composables могут вызывать другие composables внутри
8. Composables должны заключать в себе определенную логику, а когда они слишком сложны, их следует извлекать в отдельные composables для облегчения тестирования.

Рекомендации

Composables с состоянием и/или чистые функции

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

Модульные тесты (unit тесты) для компонуемых компонентов

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

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

Проблема с передачей пропсов в React

Передача пропсов - отличный способ явно передать данные через UI дерево компонентам, которые его используют. Но передача пропса может стать многословным и неудобным, когда вам нужно передать какой-то проп глубоко через дерево, или если многим компонентам нужен один и тот же проп. Ближайший общий предок может быть далек от компонентов, которые нуждаются в данных, и поднятие состояния вверх может привести к ситуации, иногда называемой “prop drilling”. Было бы здорово, просто «телепортировать» данные к компонентам дерева, которые в них нуждаются.

Контекст: альтернатива передаче пропсов

Контекст позволяет родительскому компоненту предоставлять данные всему дереву под ним. Есть много применений для контекста. Вот один из примеров. Рассмотрим компонент Heading, который принимает level для своего размера:

// App.js

import Heading from './Heading.js';
import Section from './Section.js';

export default function Page() {
  return (
    <Section>
      <Heading level={1}>Title</Heading>
      <Heading level={2}>Heading</Heading>
      <Heading level={3}>Sub-heading</Heading>
      <Heading level={4}>Sub-sub-heading</Heading>
      <Heading level={5}>Sub-sub-sub-heading</Heading>
      <Heading level={6}>Sub-sub-sub-sub-heading</Heading>
    </Section>
  );
}

// Section.js

export default function Section({ children }) {
  return (
    <section className="section">
      {children}
    </section>
  );
}

// Heading.js

export default function Heading({ level, children }) {
  switch (level) {
    case 1:
      return <h1>{children}</h1>;
    case 2:
      return <h2>{children}</h2>;
    case 3:
      return <h3>{children}</h3>;
    case 4:
      return <h4>{children}</h4>;
    case 5:
      return <h5>{children}</h5>;
    case 6:
      return <h6>{children}</h6>;
    default:
      throw Error('Unknown level: ' + level);
  }
}

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

// App.js

import Heading from './Heading.js';
import Section from './Section.js';

export default function Page() {
  return (
    <Section>
      <Heading level={1}>Title</Heading>
      <Section>
        <Heading level={2}>Heading</Heading>
        <Heading level={2}>Heading</Heading>
        <Heading level={2}>Heading</Heading>
        <Section>
          <Heading level={3}>Sub-heading</Heading>
          <Heading level={3}>Sub-heading</Heading>
          <Heading level={3}>Sub-heading</Heading>
          <Section>
            <Heading level={4}>Sub-sub-heading</Heading>
            <Heading level={4}>Sub-sub-heading</Heading>
            <Heading level={4}>Sub-sub-heading</Heading>
          </Section>
        </Section>
      </Section>
    </Section>
  );
}

В настоящее время вы передаете проп level каждому <Heading> отдельно:

<Section>
  <Heading level={3}>About</Heading>
  <Heading level={3}>Photos</Heading>
  <Heading level={3}>Videos</Heading>
</Section>

Было бы неплохо, если бы вы могли передать проп level в <Section> и удалить его из <Heading>. Таким образом, вы можете добиться того, чтобы все заголовки в одном разделе имели одинаковый размер:

<Section level={3}>
  <Heading>About</Heading>
  <Heading>Photos</Heading>
  <Heading>Videos</Heading>
</Section>

Но как <Heading> может узнать уровень своего ближайшего <Section>? Для этого дочернему компоненту потребуется какой-то способ «попросить» данные откуда-то сверху на дереве. Вы не можете сделать это только с пропсами. Именно здесь в игру вступает контекст. Вы можете сделать это в три шага:

1. Создайте контекст. (Вы можете назвать его LevelContext, так как он предназначен для уровня заголовка)
2. Используйте этот контекст из компонента, которому требуются данные. (Heading будет использовать LevelContext)
3. Укажите этот контекст из компонента, задающего данные. (Section будет содержать LevelContext.)

Контекст позволяет родителю предоставить некоторые данные всему дереву внутри него.

Шаг 1: Создайте контекст

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

// LevelContext.js

import { createContext } from 'react';

export const LevelContext = createContext(1);

Единственным аргументом createContext является значение по умолчанию. Здесь 1 относится к самому большому уровню заголовка, но вы можете передать любое значение (даже объект). Вы увидите значение значения по умолчанию на следующем шаге.

Шаг 2: Используйте контекст

Импортируйте хук useContext из React и импортируйте контекст, созданный на первом шаге:

// Heading.js

import { useContext } from 'react';
import { LevelContext } from './LevelContext.js';

Как вы помните компонент Heading считывает level из пропса:

export default function Heading({ level, children }) {
  // ...
}

Вместо этого удалите пропlevel и прочитайте значение из только что импортированного контекста LevelContext:

export default function Heading({ children }) {
 const level = useContext(LevelContext);
 // ...
}

useContext — это хук. Так же, как useState и useReducer, вы можете вызвать хук только на верхнем уровне компонента React. useContext сообщает React, что компонент Heading хочет прочитать LevelContext. Теперь, когда компонент Heading не имеет пропса level, вам больше не нужно передавать проп level в Heading в вашем JSX. Обновите JSX так, чтобы его получал Section:

<Section level={4}>
  <Heading>Sub-sub-heading</Heading>
  <Heading>Sub-sub-heading</Heading>
  <Heading>Sub-sub-heading</Heading>
</Section>

Обратите внимание, что этот пример еще не совсем работает. Все заголовки имеют одинаковый размер, потому что хоть мы и вызвали контекст, но еще не предоставили его. React не знает, где его взять. Если контекст не указан, React будет использовать значение по умолчанию, указанное на предыдущем шаге. В этом примере в качестве аргумента createContext мы передали 1, поэтому useContext(LevelContext) возвращает 1, установив для всех этих заголовков <h1>. Давайте исправим эту проблему, предоставив каждому Section свой собственный контекст.

Шаг 3: Предоставьте контекст

Компонент Section в настоящее время рендерит дочерние компоненты. Оберните их поставщиком контекста (context provider), чтобы предоставить им LevelContext:

import { LevelContext } from './LevelContext.js';

export default function Section({ level, children }) {
  return (
    <section className="section">
      <LevelContext.Provider value={level}>
        {children}
      </LevelContext.Provider>
    </section>
  );
}

Это говорит React: «Если какой-либо компонент внутри этого <Section> просит LevelContext, дайте им этот level». Компонент будет использовать значение ближайшего <LevelContext.Provider> в UI дереве над ним. Этот код будет работать так же как и в самой первой реализации. Но вам не нужно было передавать проп level каждому компоненту Heading. Вместо этого он «выясняет» свой уровень заголовка, спрашивая ближайший Section выше:

1. Вы передаете проп level в <Section>.
2. Section оборачивает свои дочерние элементы в <LevelContext.Provider value={level}>.
3. Heading запрашивает ближайшее значение LevelContext выше с useContext(LevelContext).

Типичные варианты использования контекста

• Темы: Если ваше приложение позволяет пользователю изменять его внешний вид (например, в темном режиме), вы можете поместить поставщика контекста в верхнюю часть приложения и использовать этот контекст в компонентах, которые должны настроить свой визуальный вид.
• Текущий пользователь приложения: Многим компонентам может потребоваться знать текущего вошедшего в систему пользователя. Помещение его в контекст позволяет удобно читать его в любом месте дерева. Некоторые приложения также позволяют управлять несколькими учетными записями одновременно (например, оставлять комментарий как другой пользователь). В этих случаях может быть удобно обернуть часть пользовательского интерфейса во вложенного поставщика с другим значением текущего счета.
• Маршрутизация: Большинство решений маршрутизации используют внутренний контекст для хранения текущего маршрута. Таким образом, каждая ссылка «знает», активна она или нет. Если вы создаете свой собственный маршрутизатор, вы тоже можете это сделать.
• Управление состоянием: По мере роста вашего приложения вы можете получить большое состояние ближе к верхней части вашего приложения. Многие отдаленные компоненты ниже могут захотеть изменить его. Обычно используется редьюсер вместе с контекстом для управления сложным состоянием и передачи его удаленным компонентам без особых хлопот.

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

Итоги

• Контекст позволяет компоненту предоставлять некоторую информацию всему дереву под ним.
• Чтобы передать контекст:
  1. Создайте и экспортируйте его с export const MyContext = createContext(defaultValue).
  2. Передайте его в хук useContext(MyContext) чтобы прочитать его в любом дочернем компоненте, независимо от глубины.
  3. Оберните дочерние комоненты в <MyContext.Provider value={...}> для представления контекста из родительского компонента.
• Контекст проходит через любые компоненты посередине.
• Контекст позволяет писать компоненты, которые «адаптируются к окружающей среде».
• Прежде чем использовать контекст, попробуйте передать проп или передать JSX как children.