Связывание контейнеров с их проблемами

Обзор

Цель

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

Композиты

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

Композиты состоят из трех основных типов компонентов: соединителей, компонентов и блоков / элементов. Их различия основаны на их обязанностях:

  • Коннекторы - отвечают за состояние приложения
  • Компоненты - отвечают за логику пользовательского интерфейса и структуру разметки.
  • Блоки и элементы - отвечают за стили и форматирование

Пример

Примечание. Я не являюсь одним из семи последователей г-на Голдблюма, но мне нужно было использовать значок в качестве примера для этого сообщения. На самом деле это макет, который я создал в Sketch. 👩‍🎨

Композитный ProfileCard извлекает данные для Джеффа Голдблюма и текущего пользователя через соединитель, которые он передает компоненту. Компонент определяет, следуют ли текущий пользователь и Джефф друг за другом и визуализируют компоненты и разметку на основе этой логики. Блоки и элементы форматируют информацию г-на Голдблюма и применяют стиль.

Файловая структура

Разъемы

Обзор

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

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

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

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

Обязанности

  • Получение состояния приложения для клиентских компонентов
  • Формовочные данные для компонентов
  • Предоставление обработчиков для действий диспетчеризации

Пример использования

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

Рекомендации по тестированию

Хотя модульный тест для коннектора может подтвердить, что он предоставляет ожидаемые свойства изолированно, вероятно, более выгодно вместо этого написать интеграционные тесты для всей композиции. Поскольку основная цель коннектора - предоставить данные для компонентов в составе, интеграционный тест будет более эффективным для проверки этого поведения.

Компоненты

Обзор

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

ПРИМЕЧАНИЕ. Поскольку логика стилей обрабатывается блоками и элементами, компоненты не должны иметь связанных стилей. Их единственная работа - логика рендеринга. Для компонента может быть Storybook, но он не должен думать о самих стилях.

Обязанности

  • Обработка логики пользовательского интерфейса
  • Структура разметки
  • Передача реквизита детям

Пример использования

ProfileCard необходимо определить, отображать ли значок «Следит за вами» на карточке пользователя Джеффа ГолдБлума, а также текст «Подписка» для кнопки с призывом к действию. Получив необходимую информацию от коннектора, он отвечает за логику, которая принимает эти решения и передает информацию своим дочерним компонентам.

Рекомендации по тестированию

Поскольку компоненты отвечают только за логику рендеринга, вы можете сосредоточить свои тесты на этом поведении. Достаточно поверхностного рендеринга и внедрения реквизита для имитации различных состояний компонента.

Блоки и элементы

Обзор

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

Обязанности

  • Применение стилей
  • Информация о форматировании (даты, валюта, числа и т. Д.)

Пример использования

ProfileCard необходимо отформатировать числа, отображаемые в разделе информации о пользователе. Для чисел больше 10 000 следует использовать формат «10.1K», в противном случае следует использовать значения, разделенные запятыми. Также необходимо стилизовать блок Card и содержащиеся в нем элементы. Блоки и элементы отвечают за управление этим поведением.

Рекомендации по тестированию

Поскольку в этих компонентах практически нет логики, их не следует тестировать. Регрессионных тестов со снимками достаточно, но они не требуются, если они записаны в снимке более высокого уровня.

Спасибо за прочтение!

Если вам это понравилось, вы можете найти меня в Twitter и GitHub!