我发现我不喜欢用 react-hooks

可以用类似 react-use 这样的库，加上自定义 hooks 封装逻辑，也是可以很清晰的，甚至更简单，当然对开发人员的要求也更高了

什么叫关注点分离啊(战术后仰

主要是自定义 hooks 很强大 最近的感觉

正常, react-hook 心智负担 也很大, 很容易出错, 而且难调试

是有道理的，class 组件比较清晰，可以写的又臭又长。

如果你的 functional 组件写的大，useEffect 里长长一坨，那你该考虑提取功能了。例如上面朋友提到的，一些小功能封装成可重用的自定义 hooks

不谈逻辑拆封还写什么代码
相关的状态应该封装成对象
想要明确的生命周期自己封装 useMount 或者使用 react-use 之类的库
用 hook 整个思维方式都要改变，不要老想着生命周期，要想着 synchronization.
举了一个例子就出来怼了，你说没有明确的 API, 我还说这精简了一个 API 呢

类组件和胡克斯本身是两种思维方式，

但是 react 有个特殊之处，就是生命周期命名太尼玛长了，学 ios 那一套命名，前端又没有 idea 这么牛逼的 ide 帮你自动补全，相比之下 vue 就没那么多事，别人就是按类组件封装也打不了几个字。

所以说又回到老生常谈的问题了，代码长短和质量、运行效率有关么？

没觉得代码更混乱，反而能更好的抽出公共部分，不过 react hooks 有硬伤倒是真的，有些地方比较费脑子

我发现我喜欢用 react-hooks, 代码逻辑非常清晰。我再也不用 class 。

hooks 才是 react 函数式的精髓，class 组件还不如用 vue 。

记得 svelte 作者也说他不喜欢 hook

最近的项目完全使用 react-hook 开发，是真的舒服。
在 react-hook 里就不要想着声明周期那一套，原来生命周期那一堆反而写起来很乱。
拿 useEffect 和生命周期函数做对比，是为了让开发者能了解 useEffect，在 class 组件和 function 组件内如何实现相同的功能。

```Javascript

// class
class ClassComponent extends React.Component {
constructor() {
super();

this.state = {
data: this.props.data,
list: []
};
}

componentDidUpdate(prevProps, prevState) {
if (this.props.data !== prevProps.data) {
// do something
}

if (this.state.list !== prevState.list) {
// do something
}

if (this.props.data !== this.state.data) {
// do something
}
}

componentWillUnmount() {
// do something 1
// do something 2
}
}


// function hook
function FunctionComponent(props) {
const [list, setList] = React.useState([]);

React.useEffect(function() {
// do something

return function() {};
}, [props.data]);

React.useEffect(function() {
// do something
}, [list]);
}

```

class 组件的声明周期是渲染 /重新渲染 /组件卸载时，你需要自己来判断是哪些值变了，哪些值没变，所以在 class 组件的生命周期内可能会充斥着一堆的 if else 的判断。
function 组件的渲染 /重新渲染 /组件卸载，是由哪个值的变化引起的，然后执行这个值被依赖的 hook，即当这个值变化时，执行什么操作，反而更一目了然。

hooks 的优点就是代码量少，我个人还是喜欢用 class 因为组件结构可以看的很清晰 也容易维护

@lemon6 凌晨一点了

坚持一下，习惯就好了。我开始也不喜欢，现在两种写法都无感了，团队需要怎么写，我就怎么写。

我从开发者的角度感觉不出明显的好坏，但传说 hooks 的运行速度快 30%，所以新项目多用 hooks

@murmur #7
什么叫没有 idea 这么牛逼的 ide 帮你自动补全 VS Code + ES 7 React/Redux/GraphQL/React-Native snippets 打个 c 就可以选择 lifecycle function 了

是不是就是 class 的继承呀

要不你试试 mobx

hooks 确实是一种进步，class 继承复用是硬伤。但是 hooks 学习成本较高，如果没有透彻的理解，半路上车开发很容易掉进坑里。这一点不如 class 明朗。

我举一个常见的例子，你要如何在 usecallback 里面访问变化的 state ？也许初学者会觉得直接访问就可以了，但是实际上不行。你必须用 useref 再对 state 进行一次包装，不然取到的永远是 state 的初始值。特别麻烦。相比来说，class 就简洁明朗得多。有些人就是无理由地喜欢函数式组件，简直跟处女情结一样，我觉得大可不必，这事要辩证地看。

我写 hooks 写的很爽，class 组件完全被抛弃了。

使用自定义 hook 时候简直像魔法
魔法是个好东西，因为神奇
魔法不是个好东西，因为神奇

感觉是 class 跟 hooks 一起用的问题。建议项目单用 class 、单用 hooks 。

官方说是推荐新代码全部用 hooks，我个人的实际体验是用 hooks 要把 class component 的生命周期那套东西全都忘掉，就像张三丰学太极拳那样

react-hooks 这么好用的东西都变成心智负担了，你们开发者真难伺候

@wxsm 不用 ref，玩定时器总是会出错。

@murmur 确实是两种思维方式啊，这点无可厚非。
但要说生命周期名称太长不提供补全，楼下也说了 vs code 打上插件照样可以补全。经常忙 react 开发的都能记得常用的生命周期吧，命名挺规律的……

@Jirajine 我还在想我为什么比起 hooks 更能接受 class 组件，这么看来还真可能因为早期 vue 的熏陶(我个人是先接触的 vue 应付的毕设，然后面到公司让自学转 react 了)

lz 加油，共勉吧。
我自己也知道 hooks 是个好东西，加上楼上的大佬们也都分析了，早学会早升值奥

@duan602728596 这里又有一个老生常谈的问题，就是 useXXX 判断变量变化的比较标准是什么，新东西肯定会有新坑的

你不喜欢是因为你不懂函数式编程，并不是 class 的可维护性更好。实际上 class 的可维护性更差。

要完全融会贯通可以练一练 OCaml 。React 是用 SML 和 OCaml 写的原型，hooks 可以算是回归初心。

hooks 我喜欢，太多逻辑就自定义 hooks，只要排好版合理分拆其实两种写法区别不大。不过楼主贴的 vue 看起来也不错啊，可要我选还是用 hooks，一般我很排斥包含有属性之类的东西，觉得 hooks 和纯函数写起来少点心智负担。

@wxsm 可以考虑用 setState 用函数形式然后再把参数原封不动返回去，没必要用 useRef，官方文档本身也不推荐用 useRef