Why Pinia vs Vuex for Vue 3? [closed]

Question

I am a Vue.js developer who is coming up to speed with the the new features added to Vue 3, from Vue 2, namely the Composition API (added in Vue 3).

For State Management, it appears that along with the release of Vue 3, the community is shifting from using Vuex to Pinia.

What is the difference between Pinia vs Vuex? Conceptually, what has changed from Vue 2 to Vue 3, that makes Pinia a better fit for Vue 3?

Thank you.

Wanwand

it's literally on the docs page pinia.vuejs.org/introduction.html#comparison-with-vuex. – Crabb

The focus on TS and composition API, easy multiple stores, throwing away mutations and modules as useless abstractions – Kirov

Answer 1

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.

Sweetmeat

There won't be a Vuex 5. Vuex is in maintenance mode, and Pinia is officially recommended for state management instead. – Muscadine

@tony, there are several videos available in vue confs material for last year in which both posva and kiaking discuss this rfc and they seem to agree that's the direction Vuex is moving into. – Sweetmeat

Those videos and RFC predate the decision to deprecate Vuex. The Vue docs I linked states Existing users may be familiar with Vuex, the previous official state management library for Vue. With Pinia serving the same role in the ecosystem, 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.. This was added by Evan You himself on 21-Dec-2021. – Muscadine

@Tony, good to know, thanks. – Sweetmeat

Answer 2

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."

Wanwand

Thank you. I was not trying to negate anything in the previous answer. Just wanted to add some understanding around concept. – Wanwand

@bernie, here are the reasons why I downvoted, for whoever is interested. I initially tried to fit them into comments, but it got way too long, so I deleted them and put it all into one fiddle. Cheers! – Dentilabial