Anti Hook

你可能不需要Hook @Mark 2020.03.25

Hook 是什么？

https://zh-hans.reactjs.org/docs/hooks-reference.html

useState模型 • 官⽅⽤法： https://codesandbox.io/s/react-hooks- demo-1-7lw3p • 简单实现：https://codesandbox.io/s/react-hooks- demo-2-4c92p

Flow&内部

实现 • 内部链表（理解成列表） ——> 单独储存 • 按顺序读取值，按顺序执⾏ hook （不断地rerender，状态机）
• 触发更新，和 setState⼀样最后都进⼊ Fiber更新队列

优点 • 跨⽣命周期复⽤代码 • 你可以⾃定义Hook

本质：复⽤代码的尝试 PS:以函数为载体的复⽤

理论上

实际上

问题0：设计

违反单⼀，KISS原则

如果需要你学习很久，那其实是很是失败的设计。每个⼈理解的不⼀样。

问题1：可视化阅读

1.Class的⽣命周期，字⾯量划分被打破。视觉阅读结束。你需要去看每个函数式组件。 2.他并没有明显区分。

问题2：⼼智负担

1.Hook⾃⼰⽐较难理解 2.useEffect的官⽅介绍就要 70min

1.以前的组件⼼智模型⼀致现在你需要知道Hook做了什么你必须熟悉每⼀个Hook。 2.他⽤了什么state，还是context，他⽤了 effect还是什么 3.还有他⾃⼰写的Hook——毕竟这是跨⽣命周期⾥⾯的复⽤。

问题3：滥⽤？闭包

1.你的代码会收获⼀⼤堆罗列在⼀起的函数。 2.看起来像极了C语⾔ 3.OO本身就是为了简化问题，这次反向倒⻋ 4.闭包是复杂的，潜在的内存泄漏

问题4：开发体验差

1.闭包，意味着你可能出现内存泄漏⽽不⾃制。轻轻松松写出有问题的代码。 2.⽆限循环之殇：写错了就要重启浏览器。体验极差

问题5：代码真的少了？

1.每⼀步都要追踪依赖，优化性能，真的很麻烦 2.碎⽚化的useState未必真的好

你的开悟瞬间

⼀苇渡江开悟时刻技术的平衡游戏平衡是编程⾥⾯的艺术

Hook也许不是为你准备的

可能适合组件库 • 纯粹，⼀致性的组件。可以极⼤地发挥其复⽤性。 • 因为纯粹所以写不复杂。每个组件是健壮⽽⾼效的。

也许不适合业务

1.⾸先他不纯粹 2.易变化 3.琐碎且容⻓的业务逻辑 4.相似⼜不相关——并不能很好被复⽤ 5.可读性是业务代码中最重要的

理性拥抱新技术新技术！==好技术好技术===经得起时间考验的技术

参考资料 • 《useEffect 完整指南》https://overreacted.io/zh-hans/a- complete-guide-to-useeffect/ • https://github.com/brickspert/blog/issues/26 • https://github.com/donavon/hook-flow

Anti Hook

Anti Hook

Mark24

More Decks by Mark24

Other Decks in Programming

Featured

Transcript

你可能不需要Hook @Mark 2020.03.25

Hook 是什么？

https://zh-hans.reactjs.org/docs/hooks-reference.html

useState模型 • 官⽅⽤法： https://codesandbox.io/s/react-hooks- demo-1-7lw3p • 简单实现：https://codesandbox.io/s/react-hooks- demo-2-4c92p

Flow&内部

实现 • 内部链表（理解成列表） ——> 单独储存 • 按顺序读取值，按顺序执⾏ hook （不断地rerender，状态机）

优点 • 跨⽣命周期复⽤代码 • 你可以⾃定义Hook

本质：复⽤代码的尝试 PS:以函数为载体的复⽤

理论上

实际上

问题0：设计

违反单⼀，KISS原则

如果需要你学习很久，那其实是很是失败的设计。每个⼈理解的不⼀样。

问题1：可视化阅读

1.Class的⽣命周期，字⾯量划分被打破。视觉阅读结束。你需要去看每个函数式组件。 2.他并没有明显区分。

问题2：⼼智负担

1.Hook⾃⼰⽐较难理解 2.useEffect的官⽅介绍就要 70min

1.以前的组件⼼智模型⼀致现在你需要知道Hook做了什么你必须熟悉每⼀个Hook。 2.他⽤了什么state，还是context，他⽤了 effect还是什么 3.还有他⾃⼰写的Hook——毕竟这是跨⽣命周期⾥⾯的复⽤。

问题3：滥⽤？闭包

1.你的代码会收获⼀⼤堆罗列在⼀起的函数。 2.看起来像极了C语⾔ 3.OO本身就是为了简化问题，这次反向倒⻋ 4.闭包是复杂的，潜在的内存泄漏

问题4：开发体验差

1.闭包，意味着你可能出现内存泄漏⽽不⾃制。轻轻松松写出有问题的代码。 2.⽆限循环之殇：写错了就要重启浏览器。体验极差

问题5：代码真的少了？

1.每⼀步都要追踪依赖，优化性能，真的很麻烦 2.碎⽚化的useState未必真的好

你的开悟瞬间

⼀苇渡江开悟时刻技术的平衡游戏平衡是编程⾥⾯的艺术

Hook也许不是为你准备的

可能适合组件库 • 纯粹，⼀致性的组件。可以极⼤地发挥其复⽤性。 • 因为纯粹所以写不复杂。每个组件是健壮⽽⾼效的。

也许不适合业务

1.⾸先他不纯粹 2.易变化 3.琐碎且容⻓的业务逻辑 4.相似⼜不相关——并不能很好被复⽤ 5.可读性是业务代码中最重要的

理性拥抱新技术新技术！==好技术好技术===经得起时间考验的技术

参考资料 • 《useEffect 完整指南》https://overreacted.io/zh-hans/a- complete-guide-to-useeffect/ • https://github.com/brickspert/blog/issues/26 • https://github.com/donavon/hook-flow