Как передать компонент в качестве пропса в React

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

Существует множество способов передать компонент в качестве пропса

Существует множество способов передать компонент в качестве пропса, например, специальный проп children, и паттерн render prop. О них вы можете узнать в видео “Паттерн Render Props в ReactJS”. В случае с render props мы передаем функцию, которая возвращает компонент. В этой статье рассмотрим как передать просто компонент в качестве пропса. В этой статье мы увидим простую технику, которая позволяет писать удобные настраиваемые компоненты с помощью простых API, просто используя основные строительные блоки React - компоненты. Опытный React разработчик использует эту технику естественным образом, но новичку сложно понять этот механизм.

Переизбыток пропсов

Иногда в компонент приходится передавать огромное количество пропсов для того чтобы настроить более мелкие вложенные компоненты, из которых состоит ваш компонент. Возникает переизбыток пропсов. Давайте посмотрим на это на примере. Предположим, есть компонент Alert с Button внутри.
const Button = ({ onClick, children }) => <button onClick={onClick}>{children}</button>;

const Alert = ({ children, onAccept }) => (
  <div className="alert">
    <div className="alert-header">
      <h1>Alert!</h1>
    </div>
    <div className="alert-content">{children}</div>
    <div className="alert-footer">
      <Button onClick={onAccept}>Ok</Button>
    </div>
  </div>
);

<Alert onAccept={() => {}}>Attention!</Alert>
Что вы можете сделать, чтобы настроить внутренний Button? Если вы новичок в React вы, вероятно, думаете, что правильный способ - это передать проп.
const Alert = ({ children, acceptMessage = "Ok", onAccept }) => (
  <div className="alert">
    <div className="alert-header">
      <h1>Alert!</h1>
    </div>
    <div className="alert-content">{children}</div>
    <div className="alert-footer">
      <Button onClick={onAccept}>{acceptMessage}</Button>
    </div>
  </div>
);


<Alert acceptMessage="Understood!" onAccept={() => {}}>
  Attention!
</Alert>
Все верно, но что произойдет, если мы будем иметь дело с компонентом Confirm с двумя кнопками? Вам нужно дублировать пропсы и иметь некоторые префиксы, чтобы избежать конфликтов имен пропсов.
const Confirm = ({ children, acceptMessage = "Ok", rejectMessage = "Cancel", onAccept, onReject }) => (
  <div className="confirm">
    <div className="confirm-header">
      <h1>Confirm</h1>
    </div>
    <div className="confirm-content">{children}</div>
    <div className="confirm-footer">
      <Button onClick={onAccept}>{acceptMessage}</Button>
      <Button onClick={onReject}>{rejectMessage}</Button>
    </div>
  </div>
);


<Confirm acceptMessage="Yep" rejectMessage="Nope" onAccept={() => {}} onReject={() => {}}>
  You sure?
</Confirm>
Как вы можете себе представить, это будет только ухудшаться по мере роста вашего компонента. Это то, что я имел в виду под переизбытком пропсов.

Улучшение. Вложенные пропсы

Один из способов немного привести код в порядок — вложить пропсы: по одному пропсу для каждого внутреннего компонента с необходимыми ключами.
const Confirm = ({
  children,
  onAccept,
  onReject,
  acceptButton = {
    message: "Ok",
    className: "accept-btn",
  },
  rejectButton = {
    message: "Cancel",
    className: "cancel-btn",
  },
}) => (
  <div className="confirm">
    <div className="confirm-header">
      <h1>Confirm</h1>
    </div>
    <div className="confirm-content">{children}</div>
    <div className="confirm-footer">
      <Button className={acceptButton.className} onClick={onAccept}>
        {acceptButton.message}
      </Button>
      <Button className={rejectButton.className} onClick={onReject}>
        {rejectButton.message}
      </Button>
    </div>
  </div>
);

<Confirm
  acceptButton={{ message: "Yep", className: "accept-btn" }}
  rejectButton={{ message: "Nope", className: "reject-btn" }}
  onAccept={() => {}}
  onReject={() => {}}
>
  You sure?
</Confirm>
Это исправляет конфликты, но все становится сложнее. Что произойдет, если я захочу переопределить только один вложенный проп? Чтобы сделать это, нам нужно вручную объединить пропсы со значениями по умолчанию. И что произойдет, если Button также содержит Icon? Следует ли использовать пару новых пропсов (acceptButtonIcon, rejectButtonIcon)? Должны ли вы вкладывать их в существующие пропсы (acceptButton.icon)? Типы или prop types будет очень сложно читать.

Другой подход. Render props

Render props это один из способов сделать ваши компоненты действительно настраиваемыми, вместо того, чтобы добавлять массу пропсов. Давайте попробуем. Напишем три разные версии компонента Confirm, который принимает рендер пропсы.

Версия 1. По одному рендер пропсу для каждой кнопки

В первой версии в компоненте Confirm добавим по одному рендер пропсу для каждой кнопки:
const Confirm = ({
  children,
  onAccept,
  onReject,
  renderAcceptButton = onAccept => (
    <Button className="accept-btn" onClick={onAccept}>
      OK
    </Button>
  ),
  renderRejectButton = onReject => (
    <Button className="reject-btn" onClick={onReject}>
      Cancel
    </Button>
  ),
}) => (
  <div className="confirm">
    <div className="confirm-header">
      <h1>Confirm</h1>
    </div>
    <div className="confirm-content">{children}</div>
    <div className="confirm-footer">
      {renderAcceptButton(onAccept)}
      {renderRejectButton(onReject)}
    </div>
  </div>
);

<Confirm
  renderAcceptButton={onAccept => (
    <Button className="accept-btn" onClick={onAccept}>
      Yep
    </Button>
  )}
  renderRejectButton={onReject => (
    <Button className="cancel-btn" onClick={onReject}>
      Nope
    </Button>
  )}
>
  You sure?
</Confirm>

Версия 2. Один рендер проп для всех кнопок

Вторая версия - это один рендер проп для всех кнопок.
const Confirm = ({
  children,
  onAccept,
  onReject,
  renderButtons = (onAccept, onReject) => (
    <>
      <Button className="accept-btn" onClick={onAccept}>
        OK
      </Button>
      <Button className="reject-btn" onClick={onReject}>
        Cancel
      </Button>
    </>
  ),
}) => (
  <div className="confirm">
    <div className="confirm-header">
      <h1>Confirm</h1>
    </div>
    <div className="confirm-content">{children}</div>
    <div className="confirm-footer">{renderButtons(onAccept, onReject)}</div>
  </div>
);

<Confirm
  renderButtons={(onAccept, onReject) => (
    <>
      <Button className="accept-btn" onClick={onAccept}>
        Yep
      </Button>
      <Button className="cancel-btn" onClick={onReject}>
        Nope
      </Button>
    </>
  )}
>
  You sure?
</Confirm>

Версия 3. Один рендер проп для всех подкомпонентов

И, наконец, рендер проп для всего компонента:
const Confirm = ({
  children,
  onAccept,
  onReject,
  render = (onAccept, onReject, children) => (
    <div className="confirm">
      <div className="confirm-header">
        <h1>Confirm</h1>
      </div>
      <div className="confirm-content">{children}</div>
      <div className="confirm-footer">
        <Button className="accept-btn" onClick={onAccept}>
          OK
        </Button>
        <Button className="reject-btn" onClick={onReject}>
          Cancel
        </Button>
      </div>
    </div>
  ),
}) => render(onAccept, onReject, children);

<Confirm
  render={() => {
    // компонент, который появится внутри `Confirm`
  }}
>
 You sure?
</Confirm>
Последний вариант своего рода крайность. Рендер пропсы настолько мощный, насколько это возможно, но он также имеет свои нюансы. Они позволяют изменить способ рендеринга компонента, но повторно использовать «значения по умолчанию» непросто. Это зависит от того, что визуализирует ваш рендер проп. В предыдущих примерах мы видели три варианта, каждый из которых обеспечивает большую гибкость, но меньшую возможность повторного использования «значений по умолчанию». Однако этот подход может показаться излишним, когда мы просто хотим настроить текст кнопок Alert/Confirm.

Просто передать компонент

const Confirm = ({
  children,
  onAccept,
  onReject,
  acceptButton = <Button>Ok</Button>,
  rejectButton = <Button>Cancel</Button>,
}) => (
  <div className="confirm">
    <div className="confirm-header">
      <h1>Confirm</h1>
    </div>
    <div className="confirm-content">{children}</div>
    <div className="confirm-footer">
      {React.cloneElement(acceptButton, { className: "accept-btn", onClick: onAccept })}
      {React.cloneElement(rejectButton, { className: "reject-btn", onClick: onReject })}
    </div>
  </div>
);

<Confirm
  acceptButton={<Button>Yep</Button>}
  rejectButton={<Button>Nope</Button>}
  onAccept={() => {}}
  onReject={() => {}}
>
  You sure?
</Confirm>
Этот API гораздо более естественен. Это один из тех случаев, когда cloneElement является правильным инструментом. Если вам интересно, почему мы всегда передаем обработчики, когда в некоторых случаях имеет смысл просто использовать их напрямую, вы правы. В данном случае это не обязательно.
<Confirm
  acceptButton={<Button onAccept={() => {}}>Yep</Button>}
  rejectButton={<Button onReject={() => {}}>Nope</Button>}
>
  You sure?
</Confirm>

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

10 месяцев назад·1 мин. на чтение

Composables (composition API) можно использовать для хранения основной бизнес-логики (например, вычислений, действий, процессов), поэтому они являются важной частью приложения. К сожалению, в командах не всегда есть соглашения для написания 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, что позволяет нам также иметь более стабильную систему.