Mixin的缺陷:
组件与Mixin之间存在隐式依赖(Mixin经常依赖组件的特定⽅法,但在定义组件时并不知道这种依赖关系)多个Mixin之间可能产⽣冲突(⽐如定义了相同的state字段)Mixin倾向于增加更多状态,这降低了应⽤的可预测性(The more state in your application, the harder it is to reason about it.),导致复杂度剧增隐式依赖导致依赖关系不透明,维护成本和理解成本迅速攀升:
难以快速理解组件⾏为,需要全盘了解所有依赖Mixin的扩展⾏为,及其之间的相互影响组价⾃身的⽅法和state字段不敢轻易删改,因为难以确定有没有Mixin依赖它Mixin也难以维护,因为Mixin逻辑最后会被打平合并到⼀起,很难搞清楚⼀个Mixin的输⼊输出
HOC相⽐Mixin的优势:
HOC通过外层组件通过Props影响内层组件的状态,⽽不是直接改变其State不存在冲突和互相⼲扰,这就降低了 耦合度不同于Mixin的打平+合并,HOC具有天然的层级结构(组件树结构),这⼜降低了复杂度
HOC的缺陷:
扩展性限制: HOC⽆法从外部访问⼦组件的State因此⽆法通过shouldComponentUpdate滤掉不必要的更新,React在⽀持ES6 Class之后提供了React.PureComponent来解决这个问题Ref传递问题: Ref被隔断,后来的React.forwardRef来解决这个问题Wrapper Hell:HOC可能出现多层包裹组件的情况,多层抽象同样增加了复杂度和理解成本命名冲突: 如果⾼阶组件多次嵌套,没有使⽤命名空间的话会产⽣冲突,然后覆盖⽼属性不可⻅性: HOC相当于在原有组件外层再包装⼀个组件,你压根不知道外层的包装是啥,对于你是⿊盒
Render Props优点:
上述HOC的缺点Render Props都可以解决
Render Props缺陷:
使⽤繁琐: HOC使⽤只需要借助装饰器语法通常⼀⾏代码就可以进⾏复⽤,Render Props⽆法做到如此简单嵌套过深: Render Props虽然摆脱了组件多层嵌套的问题,但是转化为了函数回调的嵌套
React Hooks优点:
简洁: React Hooks解决了HOC和Render Props的嵌套问题,更加简洁解耦: React Hooks可以更⽅便地把 UI 和状态分离,做到更彻底的解耦组合: Hooks 中可以引⽤另外的 Hooks形成新的Hooks,组合变化万千函数友好: React Hooks为函数组件⽽⽣,从⽽解决了类组件的⼏⼤问题:
this指向容易错误分割在不同声明周期中的逻辑使得代码难以理解和维护代码复⽤成本⾼(⾼阶组件容易使代码量剧增)
React Hooks缺陷:
额外的学习成本(Functional Component 与Class Component之间的困惑)写法上有限制(不能出现在条件、循环中),并且写法限制增加了重构成本破坏了PureComponent、React.memo浅⽐较的性能优化效果(为了取最新的props和state,每次render()都要重新创建事件处函数)在闭包场景可能会引⽤到旧的state、props值内部实现上不直观(依赖⼀份可变的全局状态,不再那么“纯”)React.memo并不能完全替代shouldComponentUpdate(因为拿不到state change,只针对 props change)