为什么 Vue 3 需要 Pinia 和 Vuex？

Question

我是一名 Vue.js 开发人员，正在了解从 Vue 2 添加到 Vue 3 的新功能，即 Composition API（在 Vue 3 中添加）。

对于状态管理来说，随着 Vue 3 的发布，社区似乎正在从使用 Vuex 转向 Pinia。

Pinia 与 Vuex 之间有什么区别？从概念上讲，Vue 2 到 Vue 3 发生了什么变化，使得 Pinia 更适合 Vue 3？

谢谢。

Answer 1

简而言之，Pinia 的 API 更加简单和直观。即使对于初级开发人员来说，它也使得使用商店变得轻而易举。

它带来了 Composition API 的优点，但其结构与您可能熟悉的 Options API 非常相似：

• 在选项 API 中具有响应式state、等效的功能data
• has getters，相当于computedOptions API 中的
• has actions，相当于methodsOptions API 中的
• 没有mutations，因为对statenow 的任何更改都会注册隐式突变，无论在何处执行

此外，在皮尼亚：

• 行动不再是必然的async，它们可以是
• 操作不需要（也没有）第一个参数（操作上下文），因为您不再需要commit, dispatch, rootGetters,rootState
• 现在可以在任何操作/获取器中直接调用其他存储，甚至允许循环依赖；这减少了嵌套存储的需要，尽管仍然有可能
• 所有商店现在都在运行时动态注册（当它们第一次被调用时；商店开始为空）
• insideactions和gettersFunctionsthis是当前存储，提供对所有状态道具、操作和 getter 的直接访问
• 您还可以直接访问由 ; 返回的函数（例如：useSomeStore）返回的对象上的所有操作、获取器和状态属性defineStore()。这都是 TypeScript 友好的，不需要解决方法或类型转换。

在专用页面上对两个插件之间的差异进行了更深入的解释和推理。

根据插件作者的声明，Vuex 5 将具有与 Pinia 类似的 API，并且它们可能会在某个时候合并。

正如 Tony 在评论中所述，Pinia 现在是 Vue 团队官方推荐的状态管理解决方案。

Vuex 现在处于维护模式。它仍然有效，但将不再接收新功能。对于新应用，建议使用 Pinia。-- [由Evan You于 2021 年 12 月添加]。

参考：

“从 Vue 2 到 Vue 3 发生了什么变化，使得 Pinia 更适合 Vue 3？”

Pinia 被设计用于在setup(). 如此之多，以至于它有一个专门的页面介绍如何在setup().

更重要的是，您暗示 Vuex 更适合 Vue2 项目。
从技术上讲，这是错误的。

这两个插件都提供相同的功能，但 Vuex 有更多的样板文件，总体而言，语法不太直观。因此，它需要训练有素的工程师，工作时间更长。

如果您选择 Vuex，您的项目成本将随着项目的复杂性成比例增长，但没有任何好处。

Answer 2

在做了一些研究并在 Vuejs LA Meetup（洛杉矶）上就此发表演讲之后，我想花点时间回答我自己的问题。还要感谢其他已经回答的人，以帮助做出此答复。

\n

TLDR：在 Vue 2 中，您无法使用“仅 Vue”轻松控制共享全局状态，因此您需要 Vuex 来管理整个应用程序中共享的全局状态。（您可以管理组件的本地状态，但不能管理“全局状态”，即跨应用程序的 共享状态，而无需使用 Vuex 之类的东西。）在 Vue 3 中，使用 Composition API，您可以创建一个位置管理全局状态，因此您可以非常轻松地“推出自己的”状态管理系统。所以现在，在 Vue 3 中，是的，您基本上可以自己完成此操作，但您不妨使用每个人都在使用的标准 Pinia。

\n

完整说明：对于那些正在快速了解 Vue 3 的人来说，最大的新增功能是 Composition API。对于 Vue 3，Vue 2 基本上被重新命名为“Options API”，现在还有一个额外的“Composition API”。请不要将“新”与“更好”混淆。Composition API 并没有更好。只是不同而已。Options API（又名，Vue2 的做事方式仍然很棒——你应该继续使用它）。

\n

选项 API 和组合 API 之间的主要区别在于组织。Options API（又名 Vue 2 Way）帮助您以某种标准方式组织代码——基本上，Vue 的最佳功能之一就是每个组件的清晰组织。每个 .vue 组件中的这 3 个<template>/<script>/<styles>块让使用 Vue 变得很愉快。

\n

Composition API 基本上是为了您需要打破这种范式的场合而创建的。<script>想象一下，您的代码部分需要具有相同的逻辑，例如搜索。但您在 3 个地方需要搜索功能。您现在可以将该搜索代码提取到一个新文件中，将其命名为my-search.js，然后通过将其功能导入到每个组件中来从一个位置访问该搜索代码，而不是使用三次相同的冗余代码，从而保持DRY。此外，使用 Composition API，您可以在保持反应性的同时做到这一点（在 Vue 2 中，您可以有一个外部文件，但您基本上是“离开 Vue”，这是一个问题）。现在，使用 Vue 3 中的 Composition API，您可以创建一个单独的区域来专注于共享逻辑，例如my-search.js，并且 Vue 会继续意识到它，因此您不会破坏反应性。

\n

在 Vue 2 中，社区通过创建 Vuex 解决了这个全局状态管理问题。它是一个插件，允许您控制组件外部的状态，即控制全局状态，同时保持反应性（即，它不会破坏状态）。

\n

让我们将 Composition API 赋予我们的这一新功能应用于管理全局状态。如果您可以创建一个external.js在 Vue 应用程序中保持功能并保留状态的新文件，您可以轻松编写自己的全局状态管理器（复制 Vuex 的功能）。想象一下创建一个名为 的文件global-state.js并在其中更新所有全局状态。Composition API 使这一切变得非常容易。

\n

所以现在，由于 Vue 3 中的 Composition API，我们基本上不需要任何外部状态管理工具。这就是为什么当 Vue 3 推出时，每个论坛帖子都在问这样的问题：“为什么我们还需要 Vuex？” 在 Vue 3 中，我们不再需要 Vuex，因为我们可以使用 Composition API 自行管理全局状态。

\n

最后，为什么是皮尼亚？嗯，基本上，标准。我们都可以自己开发，但我们也可以使用标准化的轻量级插件（我敢打赌 Pinia 是使用 Composition API \xe2\x80\x94 编写的，如果我在这里错了，请纠正我） 。此外，因为它是一个标准化流程，以及处理全局状态管理的新社区支持方式，所以它具有很好地集成到 Vue 工具生态系统的其他部分（例如 Vue DevTools）的好处，并且有自己的插件系统。

\n

希望这有助于回答我最初提出的问题，重点关注这个概念：“从概念上讲，从 Vue 2 到 Vue 3 发生了什么变化，这使得 Pinia 更适合 Vue 3。”

\n