What makes Pinia the new default?

Let’s quickly jump to Vuex docs, you’ll see the below message snacked upfront.

Well, why this new addition? Does it make any difference? Let’s find out!

What is Pinia?

Pinia, a lightweight state management library for Vue.js, allows you to share a state across components/pages & gained a lot of traction recently. It uses the new reactivity system in Vue 3 to build an intuitive and fully typed state management system. It’s now the new default state management library for vue 3. It is maintained by the Vue core team and works with both Vue 2 and Vue 3 seamlessly.

Follow up fact

Pinia started out as an exploration of what the next iteration of Vuex could look like, incorporating many ideas from core team discussions for Vuex 5. Eventually, they realized that Pinia already implements most of what we wanted in Vuex 5, and decided to make it the new recommendation instead.

Why Pinia?

• Default state management solution

While vuex was the recommended state management solution for vue for quite a while, now pinia has taken its spot in the vue3 official docs.

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.

• Compared to Vuex, Pinia provides a simpler API with less ceremony, offers Composition-API-style APIs, and most importantly, has solid type inference support when used with TypeScript.

Overall Pinia looks lightweight, simple, and easy to learn. It’s more like working with components and comes with everything that can make development in Vue 3 flexible. Thus there couldn’t be a better time to experiment with Pinia.

Pinia vs Composition API?

With gaining popularity on composition API, you could potentially ask isn’t it feasible enough. We might be thinking we can already share a global state with a simple export const state = reactive({}). This is true for single-page applications but exposes our application to security vulnerabilities if it is server-side rendered.

If the scope is limited & we know it’s not going to grow anytime soon, then it makes sense to go with hand-rolled state management solutions like composition API from Vue. But, if the scope of the application is kind of futuristic it’s good to adapt some powerful state management solution like Pinia, helping to stay organized & scalable.

Additionally, Pinia provides us with more powerful features like,

• Devtools support
• A timeline to track actions, mutations
• Stores appear in components where they are used
• Time travel and easier debugging
• Hot module replacement
• Modify your stores without reloading your page
• Keep any existing state while developing
• Plugins: extend Pinia features with plugins
• Proper TypeScript support or autocompletion for JS users
• Server-Side Rendering Support

Pros of adapting Pinia for state management

📦 Extremely light

Pinia is extremely lightweight by design, clocking at only about 1KB. This makes it trivial to add to any project and is absolutely a no-brainer for performance.

⚙️ Devtools support

Pinia hooks into Vue devtools to give you an enhanced development experience in both Vue 2 and Vue 3.

💡 Intuitive

Pinia’s simple and well-thought-out API makes writing your stores as familiar as creating components. This also means there is less boilerplate code and fewer concepts to learn compared to solutions like vuex.

🔑 Type Safe

With pinia, all your datatypes are inferred which means the store provides you with comprehensive and accurate auto completion even in javascript

Also, unlike home-rolled solutions, Pinia comes with devtools support to view & alter your states directly from devtools as well as use of the timeline to view mutations to the store over time.

🔌 Extensible

It provides a comprehensive plugin system to extend its default behavior like transactions, local storage synchronization, etc

🏗 Modular by design

Another great thing about Pinia is that it’s modular by default. This means better code organization for your stores and more performant applications as your code bundlers would be able to code split automatically in those stores.

Cons/Challenges in adapting Pinia for state management

• There is no support for debugging features like time traveling and editing

Although Pinia is built with Vue dev tools support, some features like time traveling and editing are still not supported because Vue dev tools don’t expose the necessary APIs. This is worth noting when developmental speed and debugging are of more preference for your project.

• Community support for vuex is huge compared to Pinia.

We might get more references & support from StackOverflow for vuex than Pinia. But, since now Pinia has become the default and the community is growing really fast this shouldn’t be a major concern in the coming days. Given that it was originally released in 2019 and is relatively new, it is undoubtedly one of the fastest-growing state management libraries in the Vue.js ecosystem.

Well, let’s quickly tabulate the exact difference for better understanding.

Pinia API is very different from Vuex ≤4, namely:

• mutations no longer exist. They were very often perceived as extremely verbose. They initially brought dev tools integration but that is no longer an issue.
• No need to create custom complex wrappers to support TypeScript, everything is typed and the API is designed in a way to leverage TS type inference as much as possible.
• No more magic strings to inject, import the functions, call them, enjoy autocompletion!
• No need to dynamically add stores, they are all dynamic by default and we won’t even notice. Note we can still manually use a store to register it whenever we want but because it is automatic we don’t need to worry about it.
• No more nested structuring of modules. We can still nest stores implicitly by importing and using a store inside another but Pinia offers a flat structuring by design while still enabling ways of cross composition among stores. We can even have circular dependencies of stores.
• No namespaced modules. Given the flat architecture of stores, “namespacing” stores are inherent to how they are defined and you could say all stores are namespaced.

Cool, I wish I could continue covering the working with Pinia APIs & come up with code samples. But Pinia docs is one of my recent favorites & I’m sure you’ll never regret checking it. And, it deserves a separate article on its own even if I’m eager in covering it. I’m promising to link it here if I manage to craft one soon.

References:

• https://pinia.vuejs.org/
• https://pinia.vuejs.org/ssr/nuxt.html
• https://blog.logrocket.com/pinia-vs-vuex/
• https://vuejs.org/guide/scaling-up/state-management.html#pinia
• https://vueschool.io/lessons/introduction-to-pinia?friend=vuerouter&utm_source=pinia&utm_medium=link&utm_campaign=homepage

Until then, If you have any suggestions (as I’m new to this) or wish to discuss more on this topic please write to me at mariappangameo@gmail.com. I’d also love to connect with you all on Linkedin.