使用children
const Wrapper = ({children}) => (
<div>
<div>header</div>
<div>{children}</div>
<div>footer</div>
</div>
);
const App = ({name}) => <div>Hello {name}</div>;
const WrappedApp = ({name}) => (
<Wrapper>
<App name={name}/>
</Wrapper>
);
render(<WrappedApp name="toto"/>,node);
transclusion
这在 Angular中也被称为。
children
是 React 中的一个特殊道具,将包含组件标签内的内容(这里<App name={name}/>
是 inside Wrapper
,所以它是children
请注意,您不一定需要使用children
,这对于组件来说是唯一的,如果需要,您也可以使用普通道具,或者混合使用道具和孩子:
const AppLayout = ({header,footer,children}) => (
<div className="app">
<div className="header">{header}</div>
<div className="body">{children}</div>
<div className="footer">{footer}</div>
</div>
);
const appElement = (
<AppLayout
header={<div>header</div>}
footer={<div>footer</div>}
>
<div>body</div>
</AppLayout>
);
render(appElement,node);
这对于许多用例来说既简单又很好,我建议大多数消费者应用程序都这样做。
渲染道具
可以将渲染函数传递给组件,这种模式通常称为render prop
,并且children
prop 通常用于提供该回调。
这种模式并不是真正意义上的布局。包装器组件通常用于保存和管理某些状态并将其注入其渲染函数中。
反例:
const Counter = () => (
<State initial={0}>
{(val, set) => (
<div onClick={() => set(val + 1)}>
clicked {val} times
</div>
)}
</State>
);
你可以变得更花哨,甚至提供一个对象
<Promise promise={somePromise}>
{{
loading: () => <div>...</div>,
success: (data) => <div>{data.something}</div>,
error: (e) => <div>{e.message}</div>,
}}
</Promise>
请注意,您不一定需要使用children
,这是口味/API 的问题。
<Promise
promise={somePromise}
renderLoading={() => <div>...</div>}
renderSuccess={(data) => <div>{data.something}</div>}
renderError={(e) => <div>{e.message}</div>}
/>
时至今日,许多库都在使用渲染道具(React 上下文、React-motion、Apollo ......),因为人们倾向于发现这个 API 比 HOC 更容易。react-powerplug是一组简单的 render-prop 组件。react-adopt帮助你做组合。
高阶组件(HOC)。
const wrapHOC = (WrappedComponent) => {
class Wrapper extends React.PureComponent {
render() {
return (
<div>
<div>header</div>
<div><WrappedComponent {...this.props}/></div>
<div>footer</div>
</div>
);
}
}
return Wrapper;
}
const App = ({name}) => <div>Hello {name}</div>;
const WrappedApp = wrapHOC(App);
render(<WrappedApp name="toto"/>,node);
高阶组件/HOC通常是一个函数,它接受一个组件并返回一个新组件。
使用高阶组件可能比使用children
or性能更高render props
,因为包装器可以提前一步短路渲染shouldComponentUpdate
。
这里我们使用PureComponent
. 重新渲染应用程序时,如果WrappedApp
名称 prop 不随时间变化,包装器有能力说“我不需要渲染,因为 props(实际上是名称)与以前相同”。使用children
上面的基于解决方案,即使包装器是PureComponent
,情况并非如此,因为每次父渲染时都会重新创建子元素,这意味着即使包装的组件是纯的,包装器也可能总是重新渲染。有一个babel 插件可以帮助缓解这种情况并确保children
随着时间的推移保持不变。
结论
高阶组件可以为您提供更好的性能。它并没有那么复杂,但一开始它肯定看起来不友好。
阅读本文后,不要将整个代码库迁移到 HOC。请记住,在应用程序的关键路径上,出于性能原因,您可能希望使用 HOC 而不是运行时包装器,特别是如果多次使用相同的包装器,则值得考虑将其设为 HOC。
Redux 最初使用运行时包装器<Connect>
,后来connect(options)(Comp)
出于性能原因切换到 HOC(默认情况下,包装器是 pure 和 use shouldComponentUpdate
)。这是我想在这个答案中强调的完美例证。
请注意,如果一个组件有一个 render-prop API,通常很容易在它之上创建一个 HOC,所以如果你是一个 lib 作者,你应该先编写一个 render prop API,并最终提供一个 HOC 版本。这就是 Apollo 对<Query>
render-prop 组件以及graphql
使用它的 HOC 所做的。
就个人而言,我两者都用,但如果有疑问,我更喜欢 HOC,因为:
compose(hoc1,hoc2)(Comp)
与 render props 相比,组合它们 ( ) 更惯用
- 它可以给我更好的表现
- 我熟悉这种编程风格
我会毫不犹豫地使用/创建我最喜欢的工具的 HOC 版本:
- React 的
Context.Consumer
组合
- 未说明的
Subscribe
- 使用
graphql
Apollo 的 HOC 代替Query
渲染道具
在我看来,有时 render props 会使代码更具可读性,有时则更少……我尝试根据自己的限制使用最实用的解决方案。有时可读性比性能更重要,有时则不然。明智地选择,不要拘泥于 2018 年将所有东西都转换为渲染道具的趋势。