大家好，我是Kason。我们知道，React发布Hooks之后，在业界掀起了一股Hooks热潮。许多框架（如VueCompositionAPI、Solid.js）都借鉴了Hooks模型。不过，尽管这些框架都借鉴了Hooks，但由于框架作者的思路不同，发展方向也逐渐不同。例如，在VueCompositionAPI中，watchEffect是ReactuseEffectAPI的基准。在Vue文档中，有一个简短的部分介绍了它的用法：而在Reactbeta文档中，有6个完整的部分介绍了useEffect：为什么会有这样的差异？我们从useEffect来看React和Vue设计理念的区别。欢迎加入人类优质前端框架群，带来Vue和React的区别。当Hooks刚问世时，它被视为类组件的替代品。文档中介绍Hooks时，也将其与类组件进行了对比。useEffect的执行时机包括以下三个生命周期函数：componentDidMountcomponentDidUpdatecomponentWillUnmount相比之下，Hooks的VueCompositionAPI是借鉴，同时提供了不同场景的watchEffectAPI和生命周期函数。两者在设计理念上的差异在这里已经体现出来了：React作为Facebook探索UI开发最佳实践的框架，一直都是这样做的——保持API的稳定（比如this.setState从诞生之日起就存在反应）。另一方面，Vue借鉴了各种框架的最佳实践（例如虚拟DOM、响应式更新……）。因此，在易用性方面，VueCompositionAPI肯定优于ReactHooks，例如：Hooks不能在条件语句中声明Hooks必须显式指示依赖关系，这种易用性差异将与框架迭代，更多和更明显。useEffect会变得越来越复杂。基于保持API稳定性的原则，目前useEffect主要与以上三个生命周期函数相关。不过以后useEffect关联的触发机会会更多。因此，React团队试图做一件事——淡化useEffect和生命周期的关系，甚至淡化useEffect和组件的关系（因为说到组件，自然会想到组件生命周期）。怎么稀释呢？答案是——严格模式下，DEV环境会触发多次useEffect回调。如果你使用useEffect作为componentDidMount/WillUnmount，这个特性很可能会让你的代码出现bug。React团队之所以这样做，是为了教育开发者——useEffect与生命周期无关。开发人员应该将useEffect视为数据源的同步过程。例如，在下面的聊天室组件中，useEffect可以看作是聊天室连接的同步过程：constserverUrl='https://localhost:1234';functionChatRoom({roomId}){useEffect(()=>{constconnection=createConnection(serverUrl,roomId);connection.connect();return()=>{connection.disconnect();};},[roomId]);//...}当聊天室组件挂载、更新和卸载时，都需要进行相应的同步处理。当roomId发生变化时，需要进行相应的同步处理。同样，如果React在Vue中原生支持KeepAlive，那么当聊天室组件从可见变为不可见，从不可见变为可见时，应该执行同步过程。因此，当我们从同步过程应该在什么时候执行的角度来看useEffect时，上述useEffect的触发时机是合理的。但是，如果从生命周期函数的角度来看useEffect，等以后（可能是v18的某个版本），OffscreenComponent特性就会落地（相对于Vue中的KeepAlive），当组件从visible变为无形中，useEffect会破坏函数回调函数和useEffect会依次执行，会让人很疑惑。这就是为什么，就像我上面说的，React团队一直在淡化useEffect和生命周期的关系，甚至淡化useEffect和组件的关系。一切都是为以后用useEffect挂钩其他特性打下理论基础。而这些特性从组件或生命周期函数的角度来看是没有意义的。这就是为什么新文档中有6个部分与useEffect相关。相比之下，Vue遇到新的场景怎么办？显然是在设计新的API。总结一下，是提供一个API更好，但是可以覆盖更多的场景（文档有6段介绍他），还是每个场景都提供一个API更好？不同的开发商有自己的答案。但是有一点很明确，对于前端新手来说，React的上手难度会越来越难，而Vue的上手难度会越顺越好。这里的前端小白，可能是想进前端的新人，也可能是认为自己可以做前端的后端。那么，这对现在的从业者来说是好事还是坏事呢？
