引用官方的一句话：Pinia是一个符合直觉的 Vue.js 状态管理库
简单说几点它的特性：
- 它支持Vue3，同时也支持Vue2，是Vuex的完美过渡替代者
- 它极致轻量化，只有 1kb 左右大小
- 它类型安全，支持TypeScript，类型可自动推断，即使在 JavaScript 中亦可为你提供自动补全功能！(划重点)
Pinia支持两种写法，跟Vue3一样，既支持选项式（options）写法，也支持组合式（setup）写法
举个例子
选项式写法
export const useCounterStore = defineStore('main', {
state: () => ({
count: 0,
}),
getters: {
double() {
return this.count * 2
}
},
actions: {
increment() {
this.count
}
},
})
组合式写法
import { ref, computed } from 'vue'
export const useCounterStore = defineStore('main', () => {
const count = ref(0)
const double = computed(() => {
return count.value * 2
})
function increment() {
count.value
}
return { count, double, increment }
})
确实，跟Vue3的两种写法不能说很像，基本是一模一样
由于例子比较简单，所以两种写法看着都挺简洁的，但是既然有两种写法，自然就有了比较，如果是你，你更倾向于哪种写法呢
起初我是使用 options 写法的，不是说我喜欢 optioons 写法，而是因为我用得比较早，那时还不支持 setup 写法，后面 setup 写法出来了我也是第一时间去尝试，由于 Vue3 我是一直在使用 setup 写法，所以我也是比较热衷于这种写法
但是当我慢慢切换到 setup 写法，我发现有几点弊端，或者说用着不爽的地方
setup写法的弊端- 必须将定义的 ref、计算属性 和 function 在末尾通过 return 的方式暴露出去（用不到的可不暴露）
准确的说这点不能叫做弊端，它其实就是 hooks 的写法，写习惯了也还好，但就是因为这一点，它就做不到跟 <script setup> </script> 一致的写法，这不能说是弊端，因为完整的 setup 的写法其实就是这样的，只不过是 Vue 对开发者太友好了，提供了 <script setup> </script> 这样的语法糖进一步减少开发者的负担
- 无法使用store实例的 $reset 方法重置状态，需要重置状态时需自行定义方法一个个重置，相对麻烦一点
- 在 JavaScript 中会丢失类型推断，无法提供自动补全功能，也无法通过 F12 跳转定义
还记得开头的划重点吗，没错，使用 setup 写法会丢失这一非常重要的特性，还毫无疑问会极大的降低开发效率，这也是我最无法忍受的一点。当然，在 ts 中可以通过类型定义解决代码提示，但这就不是 Pinia 的类型推断了
基于以上几点弊端，我又渐渐的从 setup 写法转回 options 写法了，毕竟 options 写法最大的问题就是当代码量非常多的时候需要上下代码反复横跳查看，有点影响代码阅读和理解，但其实如果注意模块拆分的话时很难出现这种情况的，毕竟一般不会在 store 里面写大量的业务逻辑代码
什么时候用setup写法说了这么多, 难道 setup 没有一点可取之处吗，不，我觉得存在即合理，还是有一定场景用 setup 更合适的
- 当需要在 store 中写大量的逻辑代码时（很少有这种情况，但不排除个别业务确实有这个需要），那么多少行叫大量呢，这是一个主观的词，个人觉得超过150行就可以考虑使用 setup 写法了。当然，没人一开始就知道会有多少行代码，但是应该有个大概的预判
- 使用 ts 时，两种方式都可以使用，看个人喜好，没有太大的区别
- 如果你极其反感 options 写法，并且熟悉 hooks 写法的话，别犹豫，用 setup 就对了，毕竟无论哪种写法都可以实现需求，自己喜欢最重要
作者：大脸怪
链接：https://juejin.cn/post/7271076750351548457
