Какие преимущества/недостатки есть у HOC (Higher-order Components)?

Question

[strannik_k]

Мне интересно - какие преимущества/недостатки есть у HOC?
Особенно интересна информация о применении нескольких различных HOC к одному компоненту:
1) важна ли очередность в таком случае?
2) как обратиться из одного HOC к другому (опять же в случае применения нескольких HOC к одному компоненту) и нужно ли в данном случае беспокоиться об очередности?

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

Заранее спасибо за ответ!

Answer 1

[Максим]

Добрый вечер.
Обычно HOC делаются так, что "очередность" не важна.
Обратиться из одного HOC к другому ... укажите задачу конкретную, мне кажется тут есть более простой способ.

Преимущества (разберем это видео[EN]):
мы описали "функциональность" и добавили ее с легкостью двум нашим компонентам. Следовательно, как минимум два отличных преимущества получили:
+ нет дублирования кода
+ простота в добавлении "функционала"

Другой хороший пример - "Навигационная ссылка"[RU] (подраздел так и называется - Навигационная ссылка), опять же - мы дали функционал необходимый компоненту. Если этот функционал пригодится где-то еще - мы сможем это устроить.

Почему порядок, скорее всего не важен - потому что обычно props передаются в стиле "бери все свойства" (...this.props), где ... - spread operator.

Подытожим:
используя HOC вы "не изменяете" компонент, который он получает, но добавляете при этом функциональность. Разве уже не круто?)

Comments

[strannik_k]

Спасибо за развернутый ответ!
Не совсем правильно я вопрос задал. Под HOC я подразумевал, когда целевой компонент передается в другой как параметр функции: HOC_Component(Component).
Не знал, что без такой записи, компоненты-обертки тоже могут называться HOC компонентами.

Пример "Навигационная ссылка" вполне естественный. Я сам подобным пользуюсь. Но это не то, о чем я хотел узнать.
Меня интересовали более сложные случаи - вынесении какой-то общей логики работы в отдельный компонент, а не просто клонирование переданных props c добавкой/изменением. Вот миксины, например, позволяют работать с функциями жизненного цикла компонента и обработчиками событий.

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

Насчет очередности - у меня пока ощущение, что в сложных случаях будет сложно уследить, чтобы очередность не была важна, или вообще можно было применить несколько hoc к одному компоненту. У меня был случай, когда я в каком-то примере автора Redux поменял местами 2 HOC и пример перестал работать.

Насчет плюсов и минусов. Если сравнивать с миксинами (не будем учитывать, что они не поддерживаются в es6 классах), то я вижу следующее:
Минусы миксин:
* расширяют исходный объект;
* из-за расширения объекта есть вероятность пересечения имен свойств.
Плюсы миксин:
* легко написать дополнительный функционал для работы с жизненным циклом или обработчиками событий.

Минусы HOC:
* при написании в HOC обработчиков событий, нужно следить, чтобы в них вызывались обработчики событий, переданные через props.
Плюсы HOC:
не изменяется исходный компонент.

"Обратиться из одного HOC к другому ... укажите задачу конкретную, мне кажется тут есть более простой способ."
Я пока и сам с такой необходимостью не сталкивался. Даже придумать не просто. Давайте пропустим)

[Максим]

strannik_k: "Не знал, что без такой записи, компоненты-обертки тоже могут называться HOC компонентами." => так ведь компоненты обертки и есть HOC, то есть они подходят под запись: HOC_Component(Component). В остальном по тексту, я бы отметил главное - чем меньше логика "переплетается" в разных местах, чем меньше кода в файле А влияет на код в файле Б - тем лучше. Я потому и перешел на реакт, что очень удобно, даже если проект немного устарел, быстро въехать что откуда и куда. На примере Flux - это не так быстро, а с Redux - просто песня. Поэтому необходимости менять props компонента-аргумента в HOC компоненте - у меня вообще не возникало. Обогатить компонент-аргумент - это да, изменять - нет.