用 Vue3 就该有不用 pinia 的自信

文摘 2024-07-14 09:19 广东

遇到一个朋友提的问题，写一篇文章解答一下。

首先说一下观点。

不管是用 React，还是用 Vue3，实际上大多数项目完全都可以不用全局状态管理库。不过在 React 中，要做到这样的事情，需要非常强的综合能力，在 Vue3 中，要做到这个事情更为简单。

但是毕竟也是需要一点点技术含量的，全局状态管理是一个非常好的解决问题的思路，他足够的简单粗暴，能够解决几乎所有的状态问题。因此，这至少是一个在功能上不会出纰漏的方案。

但是，我想说的是，用 Vue3 就应该有不用 pinia 的自信。 当然我也知道，部分 Vue3 的使用者，并不能快速接受这个事情。

全局状态管理的弊端

全局状态管理是一种非常好的架构思路，他足够简单粗暴。你只需要把数据放在全局状态中，就可以不用担心任何组件拆分的问题。哪怕你的组件拆得再烂再不合理，也对功能的实现没有任何影响。最终的结果就是，大多数的项目，耦合严重。

当然，如果你对项目解耦的标准并不是那么看重，那么我们可能观念很难达成一致。毕竟几千行几万行一个组件的代码，也大行其道，观念不一也很正常。

有的时候，项目写久了之后，你甚至都不知道自己在这个页面定义的状态，到底别的页面用了没用。一旦涉及到 bug 修复、旧功能维护、项目迁移、重构，就极有可能会出现很多意料之外的困难。因此，我觉得，在不用或者尽量少用全局状态管理的基础之下，如何把自己的项目的理顺，实际上是一名优秀前端架构师应该追求的一个方向。

大多数时候，我们都应该遵循单一原则，每个页面，只维护自己相关的状态，并且也应该尽量想办法让这些状态变成页面私有状态，避免共享。

当然，我只是提一个建议往这个方向去思考，并不是说，你就应该马上要这样做，毕竟每个人的项目都有各自的历史背景，难度和工作量各不相同。我只是告诉你一个结论，无全局状态管理完全足够应对大型的、复杂的项目，因为，我一直在项目中践行这个事情，这是长期实践之后的结论。

!
事实上，全局状态管理方案在有的复杂 B 端项目中还会带来内存占用过大的隐患，我们需要单独的去思考内存释放的问题。但是这一般是在客户是医院、国企、政府单位时才会经常遇到的情况

✓
我的原则就是：能不用就不用

Vue3 中，更容易做到弃用全局状态管理

在 React 中，状态私有这个事情要做得更好一些。我们无法把一个 state 定义到函数组件外部去。因此，从我个人的观点来看，这其实是一个优点。但是很多人却因为这样的限制感觉不自在，把他当成一个缺点。

✓
甚至有的新型框架还会把 React 不支持状态定义在组件之外去特地贬低 React，并以此为卖点来抬高自己 ...

和 React 不同的是，在 Vue3 中，我们可以很轻易的把状态定义到组件之外去。并且还能在此基础之上，保持数据与 UI 的响应关系。

我们只需要单独起一个 ts 文件就可以做到这个事情

import {ref} from 'vue'

export const count = ref(20)

export function increment() {
  count.value++
}

这其实是利用了闭包的特性做到了状态共享。它和全局状态管理的作用几乎是一模一样的。因此，在每个人的个人能力范围以内，大家可以在不得不用全局状态时，小范围的使用这种方式。

而 React 则还需要做一层额外的封装。

不使用 pinia，你损失了什么

首先，我们必要明确的是，我们应该优先把数据和状态，管理到函数组件之中，让他保持私有性。

全局状态管理应该作为一个兜底的方案，让它成为最后的选择。

因此，在这种小概率的范围之内，如果不使用 pinia，可能会存在的风险包括

1、ssr 时利用闭包共享状态可能会出现意外的情况
2、调试时无法追踪状态的变化
3、调试时无法获得热更新的能力
4、编写测试代码变得困难

首先，从大的范围来说，本身我们在全局状态管理中要存储的数据就应该非常非常少。这些影响就算一点都不解决，他其实也已经被降到了最低。因此这些损失也并不是不能接受。

我们再来一条一条的解读一下这些损失。

针对第一条，服务端渲染的理解。首先我们应该明确一个标准，那就是与客户端相比，服务端渲染的页面之间，更应该尽量避免共享可变状态。每一个服务端渲染出来的页面应该是单独的页面实例。在这个理念的基础之上去编写代码，你会发现你很难出问题。

第二条，我们要考虑的一个问题就是，我们在 debug 的时候，真的有很依赖状态追踪吗？console.log 才是调试方案中的最佳实践！

第三条，由于在函数组件之外声明响应式数据，因此这些数据在初始化时就被执行了，因此很难在更新时得到执行的时机，所以无法获得热更新的能力。但是由于我们只应该把小部分逻辑存放于此，因此这基本上不会对页面调试造成任何困扰。况且，当数据变得复杂时，hot reload 机制也并不那么好用，有的时候还不如重新刷新页面执行一次。结合 console.log 更容易发现问题所在

第四条，我的观点是，极小部分固定的共享状态，完全可以不需要编写测试代码，他们更多的只是基础的写入和读取的逻辑。例如登录状态，我们可以给登录逻辑单独编写测试用例即可。当然，大多数的团队，连一行测试代码也不行

很多团队确实也没太大的必要

总结

思考如何在项目中去全局状态管理，有利于帮助我们思考页面和组件的解耦问题，对我们的抽象能力是一个很好的训练机会。并且在思考这个问题的过程中，我们明确了自己可能会得到什么，以及会承担什么代价，并在这个充分的考虑过程后做出的决定。

我一直比较提倡的是不要在项目中使用全局状态管理工具。而 vue3 由于可以方便的把响应式状态声明在函数组件之外，用这种方式来兜底，他能够更容易平滑的做到这个事情。

一个区别

当我们使用自定义 hook 的方式来创建响应式状态时，和直接把状态声明在函数组件之外是有很大区别的。

// 自定义hook
function useCounter() {
  const count = ref(20)

  function increment() {
    count.value++
  }
  return {count, useCounter}
}

// 单独的模块
export const count = ref(20)

export function increment() {
  count.value++
}

这里的区别就是在于，每次我们在不同的组件中执行自定义 hook useCounter，函数的上下文都是不同的。因此，在函数中执行 useCounter() 所得到的状态都是函数组件内部私有的。

但是第二种单独的模块的方式，这是一个公有的方案。当我们在别的模块中引入他们并使用时，实际上两个模块此时会构成一个闭包环境，从而让数据得到共享。

import {count, increment} from './useCounter'

我们在思考这个方案时，要注意区分这两种场景。

用 Vue3 就该有不用 pinia 的自信

全局状态管理的弊端

Vue3 中，更容易做到弃用全局状态管理

不使用 pinia，你损失了什么

总结

一个区别

推荐阅读