Нет, это не очередной блог про рендеринг.
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
Вы увидите, что это все еще можно проверить, но только сложнее. Вопрос в том, почему мы должны идти так далеко.
Все эти пункты на самом деле сводятся к одной простой вещи: используйте вещи только тогда, когда они нужны. Это поможет снизить сложность и зависимость вашего приложения.
Я смотрю на тебя, редукс.