Pinia 中 storeToRefs 处理 null 值的正确方式

问题背景

在使用 Pinia 状态管理库时，开发者可能会遇到 storeToRefs 方法在处理某些值为 null 的状态时抛出错误的情况。这通常是由于不正确的状态定义方式导致的，而非 Pinia 本身的缺陷。

错误场景分析

在组合式 API 风格的 Pinia store 中，开发者可能会这样定义状态：

export const useStore = defineStore('counter', () => {
  let thing = null // 直接赋值为 null

  return { thing }
})

当使用 storeToRefs 解构这样的 store 时，就会出现问题。这是因为：

1. 直接赋值的 null 不是响应式的
2. store 内部使用的 thing 变量与通过 useStore().thing 暴露的变量实际上是两个不同的引用

正确解决方案

组合式 API 的正确写法

对于组合式 API 风格的 store，应该使用 ref 包装所有状态：

export const useStore = defineStore('counter', () => {
  const thing = ref(null) // 使用 ref 包装

  return { thing }
})

这种写法确保了：

• 状态是响应式的
• store 内部和外部访问的是同一个引用
• storeToRefs 可以正常工作

选项式 API 的正确写法

对于选项式 API 风格的 store，需要注意完整定义所有状态属性：

interface UserStore {
  userList: string[]
  user: string | undefined // 明确类型定义
}

export const useUserStore = defineStore('user', {
  state: (): UserStore => ({
    userList: [],
    user: undefined // 显式初始化
  }),
})

关键点：

• 在接口中明确定义所有属性的类型
• 即使属性是可选的，也应该在 state 中显式初始化
• 可以使用 undefined 或 null 作为初始值，但不能省略属性

最佳实践建议

1. 始终使用响应式包装：在组合式 API 中，对所有状态使用 ref 或 reactive 包装
2. 完整类型定义：为 store 定义完整的 TypeScript 接口
3. 显式初始化：即使属性是可选的，也应该赋予初始值 undefined 或 null
4. 考虑使用 ESLint 规则：可以配置规则来检查是否所有状态都正确使用了响应式包装

总结

Pinia 的 storeToRefs 方法要求 store 的状态必须是响应式的。通过遵循上述模式定义 store，可以避免 null 值相关的问题，同时也能获得更好的类型支持和开发体验。记住，在 Vue 的响应式系统中，显式和明确的定义总是优于隐式行为。