HOC，而不是继承

[nanyang24]

HOC，而不是继承

高阶组件的这种写法的诞生来自于社区的实践，目的是解决一些交叉问题(Cross-Cutting Concerns)

React官方推崇 HOC、组合 的方式来扩展组件功能，而不是继承的方式

高阶组件就是一个函数，且该函数接受一个组件作为参数，并返回一个新的组件

更加通俗的讲，高阶组件通过包裹（wrapped）被传入的React组件，经过一系列处理，最终返回一个相对增强（enhanced）的 React 组件，供其他组件调用。

关于 HOC 的资料： 参考1：React 高阶组件浅析 参考2：深入理解 React 高阶组件

React 推崇 组合/HOC 的原因

React 推崇 DRY 思想，组件是代码复用的主要单元，希望组件是按照最小可用的思想来进行封装的，理想的说，就是一个组件只做一件的事情，且把它做好。

其次React只是推荐使用HOC，但没限制使用继承的方式。在一些情形下使用继承是完全没有问题的，复用性和灵活性都有保证。

但过渡使用继承，容易导致代码失控，组件膨胀，降低组件的复用性。

比如需求有变，代码要从底层重新改，增加了不必要的工作量，减缓了迭代速度。

小项目的时候，组合也好，继承也罢，可维护就好，能够快速的响应需求迭代就好，选择实现的方式并不是那么重要。但如果是一个大项目，页面用到很多组件，或者是团队多人共同维护的话，就要考虑协作中可能存在的矛盾，然后通过一定约束来闭坑。组合的方式是可以保证组件具有充分的复用性，灵活度，遵守DRY原则的其中一种实践。

舍弃 Mixins 的 React

最早时候 React 官方给出的解决方案是使用 mixin 。而 React 也在官网中写道：

We previously recommended mixins as a way to handle cross-cutting concerns. We've since realized that mixins create more trouble than they are worth.

官方明显也意识到了使用 mixins 技术来解决此类问题所带来的困扰远高于其本身的价值。更多资料可以查阅官方的说明。

Mixins 的问题在于它太过于灵活，太依赖使用者，如果道行不够，很容易出现问题，容易导致覆盖代码不易维护