一、背景
Vue 3.0
已经出到3.0.5
了,React Hooks
大家也用的如日中天。整天大家都在讨论Hooks
,Hooks
,那么Hooks式的编程到底有什么好处?
还记得当时Vue3.0 beta
版本发布的时候,社区多少的反对声音:
- 意大利面代码结构吐槽:
“太失望了。杂七杂八一堆丢在 setup 里,我还不如直接用 react”
我的天,3.0 这么搞的话,代码结构不清晰,语义不明确,无异于把 vue 自身优点都扔了
怎么感觉代码结构上没有 2.0 清晰了呢 这要是代码量上去了是不是不好维护啊
- 抄袭 React 吐槽:
抄来抄去没自己的个性
有 react 香吗?越来越像 react 了
在我看来,Vue 黑暗的一天还远远没有过去,很多人其实并没有认真的去看Vue-Composition-Api
文档中的 动机 章节,本文就以这个章节为线索,从 代码结构、底层原理 等方面来一一打消大家的一些顾虑。本篇文章与你使用Vue3.0或者React无关,因为在Hooks思想上,他们本质上是一致的。
一、Vue3.0的设计动机
大如Vue3
这种全球热门的框架,任何一个 breaking-change
的设计一定有它的深思熟虑和权衡,那么 composition-api
出现是为了解决什么问题呢?这是一个我们需要首先思考明白的问题。
首先抛出 Vue2
的代码模式下存在的几个问题。
- 随着功能的增长,复杂组件的代码变得越来越难以维护。 尤其发生你去新接手别人的代码时。 根本原因是 Vue 的现有 API 通过「选项」组织代码,但是在大部分情况下,通过逻辑考虑来组织代码更有意义。
- 缺少一种比较「干净」的在多个组件之间提取和复用逻辑的机制。
- 类型推断不够友好。
逻辑重用
相信很多接触过React Hook
的小伙伴已经对这种模式下组件间逻辑复用的简单性有了一定的认知,自从 React 16.7
发布以来,社区涌现出了海量的 Hook
轮子,以及主流的生态库react-router
,react-redux
等等全部拥抱 Hook
,都可以看出社区的同好们对于Hook
开发机制的赞同。
其实组件逻辑复用在 React 中是经历了很长的一段发展历程的, mixin -> HOC & render-props -> Hook
,mixin 是 React
中最早启用的一种逻辑复用方式,因为它的缺点实在是多到数不清,而后面的两种也有着自己的问题,比如增加组件嵌套啊、props
来源不明确啊等等。可以说到目前为止,Hook
是相对完美的一种方案。
当然,我的一贯风格就是上代码对比,我就拿 HOC
来说吧,Github
上的一个真实的开源项目里就出现了这样的场景:
HOC 对比 Hook
class MenuBar extends React.Component {
// props 里混合着来自各个HOC传入的属性,还有父组件传入的属性。
handleClickNew() {
const readyToReplaceProject = this.props.confirmReadyToReplaceProject(
this.props.intl.formatMessage(sharedMessages.replaceProjectWarning)
);
this.props.onRequestCloseFile();
if (readyToReplaceProject) {
this.props.onClickNew(this.props.canSave && this.props.canCreateNew);
}
this.props.onRequestCloseFile();
}
handleClickRemix() {
this.props.onClickRemix();
this.props.onRequestCloseFile();
}
handleClickSave() {
this