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

Мы собираемся сравнить хуки реакции, пропсы рендеринга и Hoc, решая одну и ту же, но простую задачу.

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

Компоненты высшего порядка (HOC)

Так выглядит counterHOC

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

Вот как вы называете Hoc:

Когда мы передаем CompTwo в CounterHoc в качестве аргумента, CompOne может получить доступ к трем параметрам — счету, увеличению и уменьшению. Вы можете создать CompTwo, CompThree, CompFour и т. д. и использовать методы увеличения и уменьшения из CounterHoc. Полный код вы видите здесь:



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

withRouter(withCounter(AnotherHoc))

Стало сложно отлаживать, потому что вы не можете сказать, из какого компонента или Hoc находятся реквизиты. После выпуска React 16.8 команда реагирования посоветовала не использовать шаблон Hoc.

Рендер реквизит

Подобно Hoc, но шаблон render props не принимает компонент в качестве аргумента, вместо этого он использует this.props.children в качестве функции обратного вызова, поэтому он намного чище.

Вот как вы используете компонент рендеринга:

Полный исходный код находится здесь:



render-props-counter — CodeSandbox
CodeSandbox — это онлайн-редактор, специально предназначенный для веб-приложений.codesandbox.io



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

Реагировать на крючки

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

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

Использование хуков React похоже на использование функции:

Полный код здесь



Поскольку он такой чистый и гибкий в использовании, вы можете сократить время разработки, взяв готовые хуки из npm. Это похоже на импорт и использование некоторых утилит. Вы также можете написать свои собственные хуки. В отличие от пакетов, написанных с помощью render props и Hoc, он не загрязняет ваш код различными библиотеками и разными способами написания повторно используемых решений.