不得不说，hooks 的提出对前端开发是一件非常有开创性思维的事，react 的虚拟 dom + jsx 亦是如此，函数式编程也喧嚣日上，但要说这就是前端最优解，我觉得倒是可以斟酌之事。
每一种方式都是一种解决问题的思路和探索，现在很多人容易非此即彼。一说到函数式，就说面向对象一无是处。一说到 react，就说 vue 或 angular 都是垃圾。每当有听到看到如此言论时，大可不必当真。一部分是工作时间短，还缺少一些实践经验，缺乏判断，可以理解。另一部分属于思维固化或随波逐流之辈，就更不必争论了。
比较好的做法是从react组件中彻底分离出业务逻辑。业务逻辑的代码是UI无关的，它就是一组纯粹简单的class或者函数，除了lodash之类的工具包（相当于扩展语言能力）之外，几乎不import任何其他东西。这就是所谓的数据模型，model。它仅描述核心的业务规则，和你用react还是vue还是ng都没有任何关系，可以对接各种框架，甚至还可以跑在后端node里。
这时候react或vue部分就剩下薄薄的一层，最多只需要负责三件事：
把model实例化并和dom联动：通过new或者工厂，构造出model数据，把这些数据响应式地映射到dom；根据dom事件，调用model里的函数或方法，来更新model数据。
（可选）集中维护model数据的缓存：以前大家用redux或mobx，大部分代码量都是在处理这个问题。现在有了react-query或swr这样的东西，这个工作已经大大简化了。
处理纯页面状态：dom上有些状态不是从model数据里来的，是纯粹的页面状态，比如主题颜色啊、数据正在加载的标志啊，抽屉或手风琴的展开折叠啊，等等。这些和model无关，可能从桌面浏览器变到手机浏览器，或者变到electron本地程序，这些页面状态的设计就完全不同了，甚至完全没有了。
一个常见的误区是在react、vue组件或redux、mobx里直接调用fetch、axios来存取数据，然后再把数据喂给model。这不是一个理想的架构。UI和数据持久化是两个独立的东西，最好是在UI里调用model提供的存取函数，然后在model的存取函数里调用fetch、axios、
[ui事件处理函数] --调用--> [user.save方法] --调用--> [fetch函数]
首先从圈复杂度来说，不管 class 还是 hooks 的方式，都不宜弄出太复杂的代码结构出来，如果是纯逻辑计算，最好既不在 class 里也不在 hooks 里，而 class / hooks 只是作为视图的控制层而已，这时候想用哪种就用哪种就好；
另一方面，hooks 越来越成为 React 业界的工业规范，甚至很多第三方库的新版本已经在完全抛弃 class 而拥抱 hooks, 更别说 HoC 这种其实可以针对 hooks 做简单包装就能实现了。真正冲突的不是 HoC, 而是 class 里不允许写 hooks 这种限制而已。
每一种方式都是一种解决问题的思路和探索，现在很多人容易非此即彼。一说到函数式，就说面向对象一无是处。一说到 react，就说 vue 或 angular 都是垃圾。每当有听到看到如此言论时，大可不必当真。一部分是工作时间短，还缺少一些实践经验，缺乏判断，可以理解。另一部分属于思维固化或随波逐流之辈，就更不必争论了。
框架、语言都是工具。就个人的一点浅见，如果作为一个技术负责人，当然要考虑团队成员的意见，还有招聘成本，培养成本等，这些均不可作为技术选型的参考。但如果仅因此就拾糟粕而弃珠玉，那你的作用在哪里？这时，我觉得更需要一个经验丰富，有远见的人来决策。记住，团队成员只对自己负责，而你要为团队负责，团队成员做得不开心，换一个坑，而你作为一个负责人，换坑就没那么简单，在大多数情况下，可能你会在这家公司工作多年TG：li9047