Реакция: как подключить повторно используемые компоненты с обычными немыми компонентами

Question

Когда я разрабатываю веб-приложение на основе React, я часто разделяю компоненты на умные и немые, а также на многоразовые и пользовательские. Многоразовые компоненты могут быть самодостаточными, например, <RedButton> или <CustomSelect>, но они также могут быть промежуточными компонентами, такими как <FluxStoreBinder>. Компонент промежуточного программного обеспечения делает его children, добавляя к ним некоторые функции, такие как подписка на чтение в/из хранилища Flux или перенос некоторых других объектов с сохранением состояния. Тем не менее, требуется дополнительная работа для подключения повторно используемого интеллектуального промежуточного компонента к немому компоненту, потому что их реквизиты вряд ли совпадают. Например. a <FluxStoreReader> может «вернуть» свойство с именем data, а ребенок типа <ToDoList> ожидает toDoItems.

Вопрос, который я хочу задать, заключается в том, как указать компонент промежуточного программного обеспечения, контент которого будет отображаться в каком виде. Каков надлежащий и рекомендуемый подход? В настоящее время я видел 3 способа говорить компонент промежуточного слоя, как сделать свои ребенок:

1. Обеспечивая функцию через реквизит, такие как render={({arg1}) => <Child prop1={arg1}/>}. Эти функции: вы можете получить доступ к собственному состоянию/реквизитам/etc в этой функции; вы можете обрабатывать и повторно отображать реквизиты; вы можете указать, какой дочерний объект должен отображать в зависимости от состояния; вы можете установить необходимые реквизиты для ребенка без необходимости прокси-сервера через компонент промежуточного программного обеспечения.

2. Посредством ввода React.cloneElement(children, props), предоставляя функцию для переназначения props.

3. Отверткой React.cloneElement(children, props) и проксированием полученных реквизитов до ребенка. Чистый компонентный подход, никаких обратных вызовов. У этого нет функций/гибкости вышеприведенного 2, а также требуется дополнительная работа: вам понадобится другое промежуточное ПО между вашим промежуточным программным обеспечением и его дочерним элементом для повторной карты реквизита.

4. Четвертый вариант, предложенный Майком Троником, заключается в использовании компонентов более высокого порядка, которые являются, в основном, компонентами, где одним из необходимых аргументов является дочерний компонентный класс. Это почти то же самое, что и # 3, но вы не можете даже изменить тип ребенка после запуска фабрики.

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

Было бы здорово услышать мнение ребята.

Answer 1

check https://www.youtube.com/watch?v=ymJOm5jY1tQ 
 
http://rea.tech/reactjs-real-world-examples-of-higher-order-components/ and 
 
http://www.darul.io/post/2016-01-05_react-higher-order-components 
 
What are Higher Order Components? 
 
A Higher Order Component is just a React Component that wraps another one. 
 
This pattern is usually implemented as a function, which is basically a class factory (yes, a class factory!), that has the following signature in haskell inspired pseudocode 
 
hocFactory:: W: React.Component => E: React.Component 
 
Where W (WrappedComponent) is the React.Component being wrapped and E (Enhanced Component) is the new, HOC, React.Component being returned. 
 
The “wraps” part of the definition is intentionally vague because it can mean one of two things: 
 
Props Proxy: The HOC manipulates the props being passed to the WrappedComponent W, 
 
Inheritance Inversion: The HOC extends the WrappedComponent W. 
 
We will explore this two patterns in more detail. 
 
What can I do with HOCs? 
 
At a high level HOC enables you to: 
 
Code reuse, logic and bootstrap abstraction 
 
Render Highjacking 
 
State abstraction and manipulation 
 
Props manipulation 
 
We will see this items in more detail soon but first, we are going to study the ways of implementing HOCs because the implementation allows and restricts what you can actually do with an HOC.