React useHooks 以及高阶函数 是不是某种程度上和传统的面向对象类这些类同

就是 js 用不了代数效应，所作的一个拙劣模仿而已（

面向对象的写法问题主要在于会把同一个业务逻辑的代码分散到多个 lifecycle ，而 hook 刚好解决了这个问题
至于 useState 这种内置 hook 只是因为 function 的写法没办法调用 this.setState 而创立的
Java 这些传统面向对象编程语言其实有用 annotation+AOP 的方式来解决业务逻辑必须要分散到多个生命周期的问题，而 JavaScript 这边的 decorator 好像迟迟没有纳入 ECMAScript 标准，除了 nest.js 和 mobx 以外比较少有框架在用“非标准”的 decorator 特性

@changwei 我只是突然感觉 类本身也可以实现非 lifecycle ？ 其实就是类似后端容器 bean 的概念, 做一组静态方法,和容器类 一样可以实现非 lifecycle? 或者是因为有了 useState 这些的 api ,所以就自然而且的往 hook 发展了

@changwei 虽然 hooks 已经写了好几年了，但还是理解不了为啥 [把同一个业务逻辑的代码分散到多个 lifecycle] 是一个问题，从 mfc 开始就这么写，各种插件化开发其实也就是暴露不同生命周期时点，甚至写业务代码中经常会写一个 init 方法和 distory 方法放到一个单独的 effect 里面，可能是我道行太浅。。。

@nulIptr 我是感觉能一定程度上减少意大利面条代码, 相关逻辑的状态和副作用,方法可以放在一个 hooks 里,但是其实类本身也能做到这一点 可以定义切片 和分发处理。。。 就是突然陷入了 '先有鸡还是先有鸡蛋的问题', 是不是因为搞了 useState 这类 api 然后顺势就产生了 hooks

usehooks 就是函数式编程的组合，完全践行了组合大于继承，基本上你永远都无需使用继承

其实不论是组合 compose ，管道 pipe ，还是高阶函数，都是 fp 的基础知识，不要拿 oop 去套

@chenliangngng 我知道组合大于继承,只是比较困惑 oop 那套一样能实现组合,useHooks 函数式的写法更像是对类的概念本身做裁剪,和约束,反过来指导程序编程,但是感觉 react fp 这种本身又引入了新的复杂度,和调试困难。

@nulIptr #4

https://cn.vuejs.org/guide/extras/composition-api-faq.html#more-flexible-code-organization

@ZGame 你想写好 react hooks ，就要把类这个概念忘掉，没有类

oo 和 hooks ，
---
组合优于继承