In short, Pinia's API is much simpler and intuitive. It makes using stores a breeze, even for junior devs.
It brings the benefits of Composition API, but has a structure which greatly resembles the Options API, which you're probably familiar with:
has a reactive state, equivalent of data function in Options API
has getters, equivalent of computed in Options API
has actions, equivalent of methods in Options API
does not have mutations, as any change to state now registers an implicit mutation, regardless of where it's performed
Additionally, in Pinia:
actions are no longer necessarily async, they can be either
actions don't need (and don't have) the first param (action context) as you no longer need commit, dispatch, rootGetters, rootState
other stores can now be invoked directly in any actions/getters, even allowing cyclic dependencies; this reduces the need to nest stores, although still possible
all stores are now dynamically registered at runtime (when they are invoked for the first time; the store starts empty)
inside actions and getters functions, this is the current store and provides direct access to all state props, actions and getters
you also have typed direct access to all actions, getters and state props on the object returned by the function (e.g: useSomeStore) returned by defineStore(); it's all TypeScript friendly, no workarounds or type casting required.
More in-depth explanations and reasoning on the dedicated page to differences between the two plugins.
According to declarations by plugin authors, Vuex 5 will have a similar API to Pinia's and they are likely to merge at some point.
As outlined in comments by Tony, Pinia is now the officially recommended state management solution by Vue team.
Vuex is now in maintenance mode. It still works, but will no longer receive new features. It is recommended to use Pinia for new applications. -- [added by Evan You in dec 2021].
Ref:
"what has changed from Vue 2 to Vue 3, that makes Pinia a better fit for Vue 3?"
Pinia was designed for usage in setup(). So much so, that it has a dedicated page on how to use it outside of setup().
More importantly, you are implying Vuex is a better fit for Vue2 projects. Technically, that is false.
Both plugins offer the same functionality but Vuex has more boilerplate and, overall, a less intuitive syntax. Therefore it requires better trained engineers, for longer periods of time.
If you choose Vuex, your project costs will grow proportionally with your project's complexity, without any benefits.
I want to take a moment to answer my own question, after doing some research and giving a talk on this at the Vuejs LA Meetup (Los Angeles). Thanks also to the others who already answered to help with this response.
TLDR: In Vue 2 you -could not- easily control the shared Global State using "just Vue," so you needed Vuex to manage Global State shared throughout your app. (You can manage a component's local state, but not "Global State" that is the shared state across your app, without using something like Vuex.) In Vue 3, using the Composition API, you -can- create a place to manage Global State, so you can very easily just "roll your own" State Management system. So now, in Vue 3, yes, you basically can do this on your own, but you might as well use a standard one everyone is using, Pinia.
Full Explanation: For those who are coming up to speed with Vue 3, the big addition is the Composition API. For Vue 3, Vue 2 basically got re-branded the "Options API" and now there is an additional "Composition API." Please don't confuse "new" with "better." The Composition API is not better. It's just different. The Options API (aka, the Vue2 way of doing things is still fantastic -- and you should continue to use it).
The main difference between with Options API and the Composition API is organizational. The Options API (again, aka The Vue 2 Way) helps you organize your code a certain standard way -- basically one of the best features of Vue is the clean organization of each component. Those 3 <template>/<script>/<styles> blocks in each .vue component make it a pleasure to use Vue.
The Composition API was basically created for the occasion that you need to break out of that paradigm. Imagine you need to have the same logic, like Search, in the <script> section of your code. But you need the Search ability in 3 places. Instead of having the same redundant code three times, you can now extract that Search code to a new file, call it something like my-search.js, and access that search code from one place by importing its functionality into each of your components, staying DRY. Moreso, using the Composition API you can do this while maintaining reactivity (in Vue 2, you could have an external file, but you were basically "leaving Vue" and that was a problem). Now, using the Composition API in Vue 3, you can create a separate area to focus on shared logic, like my-search.js, and Vue continues to be aware of it, so you don't break reactivity.
In Vue 2, the community solved this Global State Management issue by creating Vuex. It was a plugin that allowed you to control state outside of the components, i.e., control Global State while remaining reactive (i.e., it did not break state).
Let's apply this new ability given to us by the Composition API to Managing Global State. If you can create a new external.js file that remains functional within your Vue app, that retains state, you can easily write your own Global State Manager (replicating what Vuex does). Imagine creating a file called global-state.js and making all of your Global State updates there. The Composition API makes this super easy to do.
So now, because of the Composition API in Vue 3, we basically do not need any external state management tool. That is why, when Vue 3 launched, every forum post was asking questions like, "Why do we even need Vuex anymore?" In Vue 3, we don't need Vuex anymore because we can Manage Global State on our own using the Composition API.
So last, why Pinia? Well, basically, standards. We could all roll our own, but we might as well use a light-weight plugin that is standardized (I would bet that Pinia is written using the Composition API — please correct me if I'm wrong here). Moreso, because it's a standardized process, and the new community-backed way of handling Global State Management, it comes with the bonus of integrating well into the rest of the Vue ecosystem of tools, like Vue DevTools, and has its own plugin system.
Hope that helps answer the original questions I was asking, focused on the concept: "Conceptually, what has changed from Vue 2 to Vue 3, that makes Pinia a better fit for Vue 3."
发布评论
评论（2）
简而言之，Pinia 的 API 更加简单和直观。即使对于初级开发人员来说，它也使得使用商店变得轻而易举。
它带来了 Composition API 的优点，但其结构与您可能熟悉的 Options API 非常相似：
state，相当于data函数在Options API中getters，相当于Options API中的compulatedactions，相当于Options API中的methods突变，因为任何改变state现在注册一个隐式突变，无论它在哪里执行此外，在 Pinia 中：
异步，它们可以是commit、dispatch、rootGetters、rootStateactions和getters 函数，this是当前存储，提供对所有状态道具、操作和 getter 的直接访问，useSomeStore）由defineStore()返回；这都是 TypeScript 友好的，不需要解决方法或类型转换。在 专用页面上有更深入的解释和推理 两个插件之间的差异。
根据插件作者的声明，Vuex 5 将具有与 Pinia 类似的 API，并且它们可能会在某个时候合并。正如 Tony 的评论中所述，Pinia 现在是官方推荐的状态管理解决方案Vue 团队。
参考：
Pinia 是为在
setup()中使用而设计的。如此之多，它有一个专门的页面介绍如何在设置之外使用它()。更重要的是，您暗示 Vuex 更适合 Vue2 项目。
从技术上讲，这是错误的。
这两个插件都提供相同的功能，但 Vuex 有更多的样板文件，总体而言，语法不太直观。因此，它需要训练有素的工程师，工作时间更长。
如果您选择 Vuex，您的项目成本将随着项目的复杂性成比例增长，但没有任何好处。
In short, Pinia's API is much simpler and intuitive. It makes using stores a breeze, even for junior devs.
It brings the benefits of Composition API, but has a structure which greatly resembles the Options API, which you're probably familiar with:
state, equivalent ofdatafunction in Options APIgetters, equivalent ofcomputedin Options APIactions, equivalent ofmethodsin Options APImutations, as any change tostatenow registers an implicit mutation, regardless of where it's performedAdditionally, in Pinia:
async, they can be eithercommit,dispatch,rootGetters,rootStateactionsandgettersfunctions,thisis the current store and provides direct access to all state props, actions and gettersuseSomeStore) returned bydefineStore(); it's all TypeScript friendly, no workarounds or type casting required.More in-depth explanations and reasoning on the dedicated page to differences between the two plugins.
According to declarations by plugin authors, Vuex 5 will have a similar API to Pinia's and they are likely to merge at some point.As outlined in comments by Tony, Pinia is now the officially recommended state management solution by Vue team.
Ref:
Pinia was designed for usage in
setup(). So much so, that it has a dedicated page on how to use it outside ofsetup().More importantly, you are implying Vuex is a better fit for Vue2 projects.
Technically, that is false.
Both plugins offer the same functionality but Vuex has more boilerplate and, overall, a less intuitive syntax. Therefore it requires better trained engineers, for longer periods of time.
If you choose Vuex, your project costs will grow proportionally with your project's complexity, without any benefits.
在做了一些研究并在 Vuejs LA Meetup（洛杉矶）上就此发表演讲之后，我想花点时间回答我自己的问题。也感谢其他已经回答并帮助做出此回应的人。
TLDR：在 Vue 2 中，您无法使用“仅 Vue”轻松控制共享的全局状态，因此您需要 Vuex 来管理在整个应用程序中共享的全局状态。 （您可以管理组件的本地状态，但不能管理“全局状态”，即跨应用程序的共享状态，而无需使用 Vuex 之类的东西。）在 Vue 3 中，使用通过 Composition API，您可以创建一个地方来管理全局状态，这样您就可以非常轻松地“推出自己的”状态管理系统。所以现在，在 Vue 3 中，是的，您基本上可以自己完成此操作，但您不妨使用每个人都在使用的标准 Pinia。
完整说明：对于那些想要快速了解 Vue 3 的人来说，最大的新增内容是 Composition API。对于 Vue 3，Vue 2 基本上被重新命名为“选项 API”，现在有一个“附加 API”。请不要将“新”与“更好”混淆。 Composition API 并没有更好。只是不同而已。 Options API（又名，Vue2 的做事方式仍然很棒——你应该继续使用它）。
选项 API 和组合 API 之间的主要区别在于组织。 Options API（又名 Vue 2 Way）帮助您以某种标准方式组织代码——基本上，Vue 的最佳功能之一就是每个组件的清晰组织。每个 .vue 组件中的这 3 个
/Composition API 基本上是为了您需要打破这种范式的场合而创建的。想象一下，您需要在代码的
在 Vue 2 中，社区通过创建 Vuex 解决了这个全局状态管理问题。它是一个插件，允许您控制组件外部的状态，即控制全局状态，同时保持反应性（即，它不会破坏状态）。
让我们将 Composition API 赋予我们的这一新功能应用于管理全局状态。如果您可以创建一个新的
external.js文件，该文件在您的 Vue 应用程序中保持功能并保留状态，那么您可以轻松编写自己的全局状态管理器（复制 Vuex 的功能）。想象一下创建一个名为global-state.js的文件并在其中更新所有全局状态。 Composition API 使这一切变得非常容易。所以现在，由于 Vue 3 中的 Composition API，我们基本上不需要任何外部状态管理工具。这就是为什么当 Vue 3 推出时，每个论坛帖子都在问这样的问题：“为什么我们还需要 Vuex？” 在 Vue 3 中，我们不再需要 Vuex，因为我们可以使用 Composition API 自行管理全局状态。
最后，为什么是 Pinia？嗯，基本上，标准。我们都可以自己开发，但我们也可以使用标准化的轻量级插件（我敢打赌 Pinia 是使用 Composition API 编写的 - 如果我错了，请纠正我）。此外，因为它是一个标准化的流程，以及处理全局状态管理的新社区支持的方式，所以它具有很好地集成到 Vue 生态系统的其他工具（如 Vue DevTools）中的好处，并且拥有自己的插件系统。
希望这有助于回答我最初提出的问题，重点关注这个概念：“从概念上讲，从 Vue 2 到 Vue 3 发生了什么变化，这使得 Pinia 更适合 Vue 3。”
I want to take a moment to answer my own question, after doing some research and giving a talk on this at the Vuejs LA Meetup (Los Angeles). Thanks also to the others who already answered to help with this response.
TLDR: In Vue 2 you -could not- easily control the shared Global State using "just Vue," so you needed Vuex to manage Global State shared throughout your app. (You can manage a component's local state, but not "Global State" that is the shared state across your app, without using something like Vuex.) In Vue 3, using the Composition API, you -can- create a place to manage Global State, so you can very easily just "roll your own" State Management system. So now, in Vue 3, yes, you basically can do this on your own, but you might as well use a standard one everyone is using, Pinia.
Full Explanation: For those who are coming up to speed with Vue 3, the big addition is the Composition API. For Vue 3, Vue 2 basically got re-branded the "Options API" and now there is an additional "Composition API." Please don't confuse "new" with "better." The Composition API is not better. It's just different. The Options API (aka, the Vue2 way of doing things is still fantastic -- and you should continue to use it).
The main difference between with Options API and the Composition API is organizational. The Options API (again, aka The Vue 2 Way) helps you organize your code a certain standard way -- basically one of the best features of Vue is the clean organization of each component. Those 3
<template>/<script>/<styles>blocks in each .vue component make it a pleasure to use Vue.The Composition API was basically created for the occasion that you need to break out of that paradigm. Imagine you need to have the same logic, like Search, in the
<script>section of your code. But you need the Search ability in 3 places. Instead of having the same redundant code three times, you can now extract that Search code to a new file, call it something likemy-search.js, and access that search code from one place by importing its functionality into each of your components, staying DRY. Moreso, using the Composition API you can do this while maintaining reactivity (in Vue 2, you could have an external file, but you were basically "leaving Vue" and that was a problem). Now, using the Composition API in Vue 3, you can create a separate area to focus on shared logic, likemy-search.js, and Vue continues to be aware of it, so you don't break reactivity.In Vue 2, the community solved this Global State Management issue by creating Vuex. It was a plugin that allowed you to control state outside of the components, i.e., control Global State while remaining reactive (i.e., it did not break state).
Let's apply this new ability given to us by the Composition API to Managing Global State. If you can create a new
external.jsfile that remains functional within your Vue app, that retains state, you can easily write your own Global State Manager (replicating what Vuex does). Imagine creating a file calledglobal-state.jsand making all of your Global State updates there. The Composition API makes this super easy to do.So now, because of the Composition API in Vue 3, we basically do not need any external state management tool. That is why, when Vue 3 launched, every forum post was asking questions like, "Why do we even need Vuex anymore?" In Vue 3, we don't need Vuex anymore because we can Manage Global State on our own using the Composition API.
So last, why Pinia? Well, basically, standards. We could all roll our own, but we might as well use a light-weight plugin that is standardized (I would bet that Pinia is written using the Composition API — please correct me if I'm wrong here). Moreso, because it's a standardized process, and the new community-backed way of handling Global State Management, it comes with the bonus of integrating well into the rest of the Vue ecosystem of tools, like Vue DevTools, and has its own plugin system.
Hope that helps answer the original questions I was asking, focused on the concept: "Conceptually, what has changed from Vue 2 to Vue 3, that makes Pinia a better fit for Vue 3."