Нет, это не очередной блог про рендеринг.

TL;DR Используйте только при необходимости

Отказ от ответственности: это ни в коем случае не факт. просто мое скромное мнение об использовании HOC

Давайте сначала начнем с пользы от сочинения.

Основное преимущество компоновки заключается в том, что она позволяет нам повторно использовать компонент, изменяя его поведение (путем передачи реквизитов основному компоненту поверх него) вместо того, чтобы требовать его в самом компоненте.

Некоторые говорят, что другим преимуществом является отделение части рендеринга от логической части. Хотя я не совсем уверен, что это большая победа, на которую стоит торговать, или даже законная, поскольку react уже выделила render function для рендеринга. Кроме того, в этом случае часть рендеринга и часть логики всегда работают вместе. Вы пишете функцию/жизненный цикл/обработчик только для этого компонента. ИМО, это красота модульного компонента, который реагирует. Разделение их (скажем, на другой файл с именем hoc.js ) может не иметь смысла, требует переключения контекста при чтении кода и может привести к запаху сгустка данных.

В крайнем случае представьте, что каждый компонент теперь функционирует.

|-hocs
|  |- withX
|  |- withY
|  |- withZ
|  |- withSomethingElse
|
|
|-components
  |- compA
  |- compB
  |- compC

Теперь они будут зависеть от hoc, чтобы внедрить в них поведение, управление зависимостями будет более сложным и потеряет преимущества модульного компонента.

Теперь давайте посмотрим на недостатки написания компонентов в стиле перекомпоновки.

1. На самом деле это запах кода, если его не использовать

Итак, главное преимущество перекомпоновки — это повторное использование компонента. Теперь вы должны быть честными и ответить Сколько раз ваш компонент повторно используется по сравнению с тем, когда он не используется? Если вы говорите, что дизайн вашего приложения настолько общий, что ›70–80% вашего компонента повторно используется в другие места. Тогда хорошо, создайте основной компонент, составьте его поведение. Однако часто я вижу, что повторно используется менее 10% компонентов. Я предлагаю сначала написать его в реагирующем компоненте, а затем сделать его составным компонентом, когда вы увидите место, где его можно будет использовать повторно
Написание кода, который не используется, — это запах кода, который называетсяУмозрительная общность.

2. Это (излишне) усложняет модульное тестирование

Составляя поведение за поведением поверх основного компонента, мы фактически создали несколько слоев компонента. Теперь, с ферментом shallow, он будет отображать только компонент верхнего слоя. Теперь у вас, вероятно, есть 3–4 варианта.

  • несколько shallow чтобы добраться до компонента, который вы хотите протестировать
  • используйте фермент mount — чего не следует делать — для рендеринга всего дерева компонентов.
  • иметь несколько экспортов для разных слоев компонента — например, Car и PCar для декорированного компонента, используемого в приложении, и чистый компонент для тестирования (это возвращает меня к тому времени, когда мы использовали префикс интерфейса java с I, например Car.java и ICar.java.
  • не тестируй :D

Вы увидите, что это все еще можно проверить, но только сложнее. Вопрос в том, почему мы должны идти так далеко.

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

Я смотрю на тебя, редукс.