不要再用 Vue2 的思维写 Vue3 了

Posted 2021-07-22 小生方勤

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了不要再用 Vue2 的思维写 Vue3 了相关的知识，希望对你有一定的参考价值。

点击上方“小生方勤”，选择“设为星标”
第一时间关注技术干货！

升级Vue3后，让人最脑壳疼的应该是新的Compostion API语法，他的难点不是语法，而是他提供了全新的组织代码的思维方式。

我刚从Vue2转到Vue3时，代码都严格的遵循Compostion API写法，但是发现比Option API写法维护性更差。

踩过的坑

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 )
      if (!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%时间都是在维护的，而维护性体现在代码是否符合单一职责原则，单一职责就是把相同的业务代码内聚到一个地方。

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

如果你的代码真的具有很高的复用性，那可以提升到项目外层目录，封装到独立的hook文件。

尤雨溪的看法

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

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

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

有很多逻辑的大型组件（数百行）
在多个组件可复用的逻辑

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

问题二：使用新API导致逻辑分散到不同地方，违背"关注点分离"

尤雨溪： 这个问题和项目文件组织方式问题类似。我们很多人都同意按文件类型组织（布局放html，样式CSS，逻辑JS）并不是正确的方式，因为强制把相关代码分割到三个文件，只是给人一种“关注点分离”的错觉。这里的关键是“关注点”不是由文件类型定义。相反，我们大多数选择以功能或者职责来组织文件，这正是人们喜欢Vue单文件组件的原因。SFC就是按功能组织代码的方法，但讽刺的是当首次引入SFC时，许多人也是拒绝的，认为它违反了关注点分离。