良心不限速 & 2T大容量！
|
在 hook-flow 的图中，我们可以了解到当父组件发生重新渲染时，其所有(状态、局部变量等)都是新的。一旦子组件依赖于父组件的某一个对象变量，那么无论对象是否发生变化，子组件拿到的都是新的对象，从而使子组件对应的 diff 失效，依旧会重新执行该部分逻辑。在下面的例子中，我们的副作用依赖项中包含了父组件传入的对象参数，每次父组件发生更新时，都会触发数据请求。 ooks 中， render 与 state 的关系更像闭包与局部变量。每次渲染时，都会生成新的 state 变量，React 会向其写入当次渲染的状态值，并在当次渲染过程中保持不变。也即每次渲染互相独立，都有自己的状态值。同理，组件内的函数、定时器、副作用等也是独立的，内部所访问的也是当次渲染的状态值，因此常常会遇到定时器/订阅器内无法读取到最新值的情况。 在这种主导下，开发者在编码过程中的思维模式也应随之改变，需要考虑数据与数据、数据与行为之间的同步关系。这种模式可以更简洁地将相关代码组合到一起，甚至抽象成自定义 hooks，实现逻辑的共享，似乎有了插拔式编程的味道。
虽然 Dan Abramov 在自己的博客中提到，从生命周期的角度思考并决定何时执行副作用是在逆势而为[2]，但是了解各个 hooks 在组件渲染过程中的执行时机，有助于我们与 React 保持理解的一致性，能够更加准确地专注于“做什么”。 Donavon 以图表形式梳理对比了 hooks 范式与生命周期范式[3]，能够帮助我们理解 hooks 在组件中的工作机制。每次组件发生更新时，都会重新调用组件函数，生成新的作用域，这种变化也对我们开发者提出了新的编码要求。 React 16.8 发布以来，Hooks 深入人心，带来最大的变化有三点：思维模式的转变，渲染过程中作用域的变化以及数据流的改变。 思维模式 从 React 官网可以了解到，Hooks 的设计动机在于简化组件间状态逻辑的复用，支持开发者将关联的逻辑抽象为更小的函数，并降低认知成本，不用去理解 JS Class 中令人窒息的 this。在这样的动机之下，hooks 中弱化了组件生命周期的概念，强化了状态与行为之间的依赖关系，这容易引导我们更多的关注“做什么”，而非“怎么做”[1]。
假设有这么一个场景：组件 Detail 中依赖父级组件传入的 query 参数进行数据请求，那么无论是基于类组件还是 Hooks，我们都需要定义一个异步请求方法 getData。不同的是，在类组件的开发模式中，我们要思考的更倾向于“怎么做”：在组件挂载完成时请求数据，并在组件发生更新时，比较新旧 query 值，必要时重新调用 getData 函数。 在使用 React 开发的这段时间里，我最大的感受就是 “这是 React 最好的时代，也是最坏的时代” !「好」在于 hooks 开启了不一样的开发模式，在思考方式上要求更关注于数据之间的依赖关系，同时书写方式更加简便，总体上提升了开发效率;「坏」在于项目中经常是类组件与函数组件共存，而类组件以类编程思想为主导，开发过程中更关注于整个组件的渲染周期，在维护项目时常常需要在两种思维模式中左右横跳，这还不是最坏的一点。 某日，老王问我：“你一直在「每周一瞥」搬运 hooks 的文章，你觉得 hooks 有哪些易造成内存泄露的点?” 引发了我的深思(因为我的脑子一片空白)。我们一直在讨论 hooks，到底在讨论什么?虽然社区内关于 hooks 的讨论很多，但更多的是科普 Hooks API 怎么使用，亦或是将其与类组件生命周期、redux 进行对比，而缺少关于 hooks 最佳实践的讨论与共识，我想这才是「最坏」的一点。今天，我们不妨讨论一下 hooks 所带来的变化以及我们如何去拥抱这些变化。
注「每周一瞥」是团队内翻译并分享外网新鲜货的一个专栏。 （编辑：怀化站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
