不要再用 Vue2 的思维写 Vue3 了 - 网站源码_资源分享

点选下方“花旦方勤”，优先选择“标为隆哥蒙”第三天数高度关注控制技术蔬果！

升级换代Vue3后，让人最颚骨疼的假如是捷伊Compostion API句法，他的症结并非句法，而要他提供更多了全捷伊组织机构标识符的观念形式。

我刚从Vue2转至Vue3时，标识符都严苛的遵从Compostion API读法，但辨认出比Option API读法FEA更差。

踩过的坑

1. 按控制技术类别分割标识符

在日常生活合作开发中，后端通常会接到可视化稿或结构设计稿后已经开始产业布局，接着撰写形式论标识符。在Vue2中，通常来说作法是积极响应统计数据放在 data、形式论形式放在methods，这种的作法十分方便快捷，也让他们很难组织机构标识符。

当采用vue3的Compostion API时，假如却是用Vue2的形式组织机构标识符，这不仅不能提高标识符产品质量，反倒即使缺少束缚而减少时效性。

我在github就行了找了几段标识符，你真的这段标识符比Vue2简约吗？

export default

{

setup () {

const

state = reactive({

message

: ,

msgList

: []

})

const

router = useRouter()

let

username =

onMounted(() =>

{

username = localStorage.getItem( username

)

(!username) {

router.push( /login

)

return

}

})

const onSendMessage = () =>

{

const

{ message } = state

if (!message.trim().length) return

state.msgList.push({

id: new Date

().getTime(),

user

: username,

dateTime: new Date

().getTime(),

message

: state.message

})

state.message =

}

return

{

…toRefs(state),

onSendMessage

}

实际上他们过于高度关注句法层面改变，而忽略官方文档提到一个词叫：形式论高度关注点！！！！！！, 形式论高度关注点是指表达同一个业务的标识符内聚到一起，这也是单一职责的指导思想，他们内聚的不假如控制技术类别，而要业务形式论，即使触发标识符变更的往往是业务需求，因此把相同变更理由的标识符放在一起，这才不能导致散弹式修改。

2.过于高度关注形式论复用

compostion API一个特点是提高形式论复用，这是没有错的，但当时我有一个错误观点，就是只有复用的形式论才假如封装到hook中。

他们却是回到Vue的官方例子，你会辨认出他把原来放在一个vue文件的形式论拆分到composables目录，目录下分别定义一个文件，表示不同的形式论高度关注点。

这个文件夹的标识符强调的并并非形式论复用，而要形式论高度关注点分离，这也是compostion API最核心要解决的问题，即使应用生命周期60%天数都是在维护的，而FEA体现在标识符是否符合单一职责原则，单一职责就是把相同的业务标识符内聚到一个地方。

所以你千万别过于纠结标识符是否需要复用，应用适当的冗余反倒增加应用的FEA，《架构整洁之道》书中提到：对于大多数应用，可维护性比可重用性更加重要。

假如你的标识符真的具有很高的复用性，那可以提高到项目外层目录，封装到独立的hook文件。

尤雨溪的看法

compostion API在提案的时候，就有很多人持有不同意见，有反对有支持，实际上都没有错，只是大家碰到的场景不同而导致不同观点。我通过阅读compostion API的RFC，找到了作者对一些问题的解答，整理了一些关键问题，内容并非完全翻译，完整内容建议查看原文。

问题一：compostion api根本没有解决任何问题，只是追逐新玩意的东西

尤雨溪：不同意这个观点。Vue最已经开始很小，但现在被广泛应用到不同级别复杂度的业务领域，有些可以基于option API很轻松处理，但有些不可以。例如下面的场景：

有很多形式论的大型组件（数百行）在多个组件可复用的形式论

对于问题1，你需要把每个形式论拆分到不同选项，例如，几段形式论需要一些积极响应统计数据，一个计算属性，一些监听属性还有形式。你去了解这段形式论时，需要不断上下移动阅读，虽然你知道一些属性是什么类别，但你并不知道他具体的作用。当一个组件包含多个形式论，情况就更糟糕了。假如用捷伊API，可以将统计数据和形式论组合在一起，最重要的是，你可以干净的把这些形式论提取到一个函数，甚至一个单独的文件中。

问题二：采用新API导致形式论分散到不同地方，违背”高度关注点分离”

尤雨溪：这个问题和项目文件组织机构形式问题类似。他们很多人都同意按文件类别组织机构（产业布局放HTML，样式CSS，形式论JS）并并非正确的形式，即使强制把相关标识符分割到三个文件，只是给人一种“高度关注点分离”的错觉。这里的关键是“高度关注点”并非由文件类别定义。相反，他们大多数优先选择以功能或者职责来组织机构文件，这正是人们喜欢Vue单文件组件的原因。SFC就是按功能组织机构标识符的形式，但讽刺的是当首次引入SFC时，许多人也是拒绝的，认为它违反了高度关注点分离。

问题三：捷伊句法让Vue失去简单性，导致”意大利面条式标识符”的出现，减少项目FEA。

尤雨溪： 正好相反，捷伊API就是为了提高项目长期FEA的。

假如他们查看任何javascript项目，都会从入口文件已经开始阅读，该文件的本质是你的应用启动时被隐式调用的”main”函数。假如只有一个函数入口，会导致意大利面条标识符，那所有的js项目都是意大利面条标识符。显然并非的，即使合作开发人员通过标识符模块化或者较小的函数来组织机构标识符。

另外，我同意捷伊API理论上会减少标识符产品质量的最低门槛。但他们可以采用以往防止标识符变成意大利面条的手段缓解这种情况。另一方面，捷伊API可以提高标识符产品质量的最高上限，相比option api，你可以重构为产品质量更高的标识符。而且，基于Option api 你还得解决类似mixins的问题。

很多人认为”Vue失去简单性”，实际上只是失去组件内标识符类别检查能力（就是你不知道一个变量时data、method、却是computed）。但用捷伊API，实现一个类别检测器也是十分难实现以前的特性的。也就是说，你不假如被option api限制观念，而更多高度关注形式论内聚问题。