残缺高频题库仓库地址:https://github.com/hzfe/aweso...
残缺高频题库浏览地址:https://febook.hzfe.org/
相干问题
- 什么是 HOC / Render Props / Hooks
- 为什么须要 HOC / Render Props / Hooks
- 如何进步代码复用性
- Hooks 的实现原理
- Hooks 相比其余计划有什么劣势
答复关键点
复用性
HOC / Render Props / Hooks 三种写法都能够进步代码的复用性,但实现办法不同:HOC 是对传入的组件进行加强后,返回新的组件给开发者;Render Props 是指将一个返回 React 组件的函数,作为 prop 传给另一个 React 组件的共享代码的技术;Hooks 是 React 提供的一组 API,使开发者能够在不编写 class 的状况下应用 state 和其余 React 个性。
知识点深刻
1. HOC (Higher Order Component,即高阶组件)
HOC 是 React 中复用代码的编程模式。具体来说,高阶组件是一个纯函数,它接管一个组件并返回一个新的组件。常见例子:React Redux 的 connect,将 Redux Store 和 React 组件分割起来。
// react-redux connect 例子const ConnectedMyComponent = connect(mapState)(MyComponent);``````// 实现一个简略的 HOC 例子function logProps(WrappedComponent) { return class extends React.Component { componentDidUpdate(prevProps) { console.log("Current props: ", this.props); console.log("Previous props: ", prevProps); } render() { return <WrappedComponent {...this.props} />; } };}
2. Render Props
Render Props 是 React 中复用代码的编程模式。次要解决组件逻辑雷同而渲染规定不同的复用问题。常见例子:React Router 中,自定义 render 函数,按需应用 routeProps 来渲染业务组件。
ReactDOM.render( <Router> <Route path="/home" render={(routeProps) => ( <div>Customize HZFE's {routeProps.location.pathname}</div> )} /> </Router>, node);
3. React Hooks
React Hooks 是 React 16.8 引入的一组 API。开发者能够在不应用 class 写法的状况下,借助 Hooks 在纯函数组件中应用状态和其余 React 性能。
function Example() { const [count, setCount] = useState(0); return ( <div> <p>You clicked {count} times</p> <button onClick={() => setCount(count + 1)}>Click me</button> </div> );}
4. HOC vs Render Props vs Hooks
痛点
在理论业务疾速迭代过程中,组件常呈现大量重复性工作,大量个性化定制的需要,如果不遵循 DRY(Don't Repeat Yourself)的规定,会造成我的项目臃肿和难以保护的问题。但在许多状况下,无奈对含有状态逻辑的组件进一步拆分。因而在没有 React Hooks 前,存在应用 HOC / Render Props 进行重构的计划。
计划优劣
为辅助了解,可参考以下图片。图中所示为下拉列表性能的三种不同实现,相比于应用一个 Class 来书写下拉列表的所有性能,这三种计划都对组件进行了性能拆解,进步了代码的复用性。(代码起源)
复用性
HOC、Render Props、Hooks 都有进步代码复用性的能力,但依据其设计模式上的差异,适用范围也会有所差别:HOC 基于繁多性能准则,对传入组件进行加强;Render Props 复用数据源,按需渲染 UI;Hooks 对于不同场景的复用都有较好的普适性。
可读性 / 易用性
HOC 可读性差,易用性差。
HOC 写法看似简洁,但开发者无奈通过浏览 HOC 的调用分别出办法的作用:看不到接管和返回的构造,减少调试和修复问题的老本;进行多个 HOC 组合应用时,不能确定应用程序且有命名空间抵触危险,须要理解每个 HOC 的具体实现,难以保护。不倡议适度应用 HOC,但比拟适宜不须要个性化开发定制时应用:常见于第三方库提供 HOC 类型的 API 给开发者进行性能加强。
Render Props 可读性较好,易用性强。
代码绝对简短,但能清晰看到组件接管的 props 以及传递的性能等,能够对 props 属性重命名,不会有命名抵触。但难以在 render 函数外应用数据源,且容易造成嵌套天堂。
Hooks 可读性强,易用性较好。
应用 Hooks 时,能清晰看到组件接管的 props 以及传递的性能等,能够对 props 属性重命名,不会有命名抵触,不存在嵌套天堂,且没有数据源获取及应用范畴的限度。但 Hooks 编程应遵循函数式编程的实际,否则 Hooks 所需的依赖数组的解决会造成较大的心智累赘。
参考资料
- Introducing Hooks
- Comparison: HOCs vs Render Props vs Hooks