Pinia is a state management library for Vue.js applications. It serves as a store for shared state, with a simple and straightforward API. It is often used as an alternative to Vuex and provides reactive data stores that can be accessed throughout a Vue application.
Defining a Store
This feature allows you to define a new store with a unique identifier, state, and actions. The state is reactive and can be accessed and manipulated across components.
import { defineStore } from 'pinia';
export const useCounterStore = defineStore('counter', {
state: () => ({
count: 0
}),
actions: {
increment() {
this.count++;
}
}
});Accessing Store State in Components
This code demonstrates how to access and use the store state within a Vue component. The store's reactive state is used in the template, and actions can be called to update the state.
<template>
<div>{{ counterStore.count }}</div>
<button @click="counterStore.increment">Increment</button>
</template>
<script setup>
import { useCounterStore } from './stores/counter';
const counterStore = useCounterStore();
</script>Persisting State
Pinia allows for easy integration with other libraries, such as VueUse, to persist state between page reloads using local storage or other methods.
import { defineStore } from 'pinia';
import { useLocalStorage } from '@vueuse/core';
export const useUserStore = defineStore('user', {
state: () => ({
name: useLocalStorage('user-name', '')
})
});Vuex is the official state management library for Vue.js. It is more complex and verbose than Pinia, with a strict set of rules and patterns such as mutations for state changes. Pinia offers a simpler and more flexible API compared to Vuex.
Redux is a state management library for JavaScript apps, not limited to Vue. It uses a single immutable state tree and pure reducer functions for state updates. Redux is known for its strict unidirectional data flow, which can be more complex than Pinia's more Vue-centric and straightforward approach.
MobX is a state management library that focuses on reactive programming. It uses observables to make state management simple and scalable. Unlike Pinia, which is designed specifically for Vue, MobX can be used with any framework, and it emphasizes transparent functional reactive programming (TFRP).
Pronounced like the fruit, in Spanish Piña
Piña is also an invalid package name...
🍍Type Safe Modular and lightweight (but Experimental) Store for Vue based on the composition api
Demo (TODO link)
⚠⚠⚠ This project is experimental, it's an exploration of whan a Store could be like using the composition api. It works for Vue 2 by using the official library.
What I want is to maybe inspire others to think about ways to improve Vuex.
There are the core principles that I try to achieve with this experiment:
state and getters 👐 patch is the new mutationA few notes about the project and possible questions:
Q: Does this replace Vuex, is it its successor?
A: No, or at least that's not the main intention
Q: What about dynamic modules?
A: Dynamic modules are not type safe, so instead we allow creating different stores that can be imported anywhere
yarn add pinia
# or with npm
npm install pinia
You can create as many stores as you want, and they should each exist in isolated files:
import { createStore } from 'pinia'
export const useMainStore = createStore(
// name of the store
// it is used in devtools and allows restoring state
'main',
// a function that returns a fresh state
() => ({
counter: 0,
name: 'Eduardo',
}),
// optional getters
{
doubleCount: state => state.counter * 2,
}
)
createStore returns a function that has to be called to get access to the store:
import { useMainStore } from '@/stores/main'
export default createComponent({
setup() {
const main = useMainStore()
return {
// gives access to the whole store
main,
// gives access to the state
state: main.state,
// gives access to specific getter,
}
},
})
There is one important rule for this to work: the useMainStore (or any other useStore function) must be called inside of deffered functions. This is to allow the Vue Composition API plugin to be installed. **Never, ever call useStore like this:
import { useMainStore } from '@/stores/main'
// ❌ Depending on where you do this it will fail
// so just don't do it
const main = useMainStore()
export default createComponent({
setup() {
return {}
},
})
Once you have access to the store, you can access the state through store.state and any getter directly on the store itself as a computed property (from @vue/composition-api) (meaning you need to use .value to read the actual value on the JavaScript but not in the template):
export default createComponent({
setup() {
const main = useMainStore()
const text = main.state.name
const doubleCount = main.doubleCount.value // notice the `.value` at the end
return {}
},
})
state is the result of a ref while every getter is the result of a computed. Both from @vue/composition-api.
stateTo mutate the state you can either directly change something:
main.state.counter++
or call the method patch that allows you apply multiple changes at the same time with a partial state object:
main.patch({
counter; -1,
name: 'Abalam',
})
The main difference here is that patch allows you to group multiple changes into one single entry in the devtools.
stateSimply set it to a new object;
main.state = { counter: 666, name: 'Paimon' }
The main part about SSR is not sharing state between requests. So we can pass true to useStore once when getting a new request on the server. If we follow the SSR guide, our createApp should look like this:
export function createApp() {
// Here there could also be a router
const store = useStore(true)
// we can change the state now!
store.state.counter++
// create the app instance
const app = new Vue({
render: h => h(App),
})
// expose the app and the store.
return { app, store }
}
Actions are simply function that contain business logic. As with components, they must call useStore to retrieve the store:
export async function login(user, password) {
const store = useUserStore()
const userData = await apiLogin(user, password)
store.patch({
name: user,
...userData,
})
}
Composing stores may look hard at first glance but there is only one rule to follow really:
If multiple stores use each other or you need to use multiple stores at the same time, you must create a separate file where you import all of them.
If one store uses an other store, there is no need to create a new file, you can directly import it. Think of it as nesting.
If you need to compute a value based on the state and/or getters of multiple stores, you may be able to import all the stores but one into the remaining store, but depending on how your stores are used across your application, this would hurt your code splitting as you importing the store that imports all others stores, would result in one single big chunk with all of your stores.
To prevent this, we follow the rule above and we create a new file:
import { computed } from '@vue/composition-api'
import { useUserStore } from './user'
import { useCartStore } from './cart'
export const summary = computed(() => {
const user = useUserStore()
const cart = useCartStore()
return `Hi ${user.state.name}, you have ${cart.state.list.length} items in your cart. It costs ${cart.price}.`
})
When an actions needs to use multiple stores, we do the same, we create a new file:
import { useUserStore } from './user'
import { useCartStore, emptyCart } from './cart'
export async function orderCart() {
const user = useUserStore()
const cart = useCartStore()
try {
await apiOrderCart(user.state.token, cart.state.items)
emptyCart()
} catch (err) {
displayError(err)
}
}
FAQs
Intuitive, type safe and flexible Store for Vue
The npm package pinia receives a total of 1,517,197 weekly downloads. As such, pinia popularity was classified as popular.
We found that pinia demonstrated a healthy version release cadence and project activity because the last version was released less than a year ago. It has 0 open source maintainers collaborating on the project.
Did you know?
Socket for GitHub automatically highlights issues in each pull request and monitors the health of all your open source dependencies. Discover the contents of your packages and block harmful activity before you install or update your dependencies.
Security News
Research
The Socket Research Team uncovered a malicious Python package typosquatting the popular 'fabric' SSH library, silently exfiltrating AWS credentials from unsuspecting developers.
Security News
At its inaugural meeting, the JSR Working Group outlined plans for an open governance model and a roadmap to enhance JavaScript package management.
Security News
Research
An advanced npm supply chain attack is leveraging Ethereum smart contracts for decentralized, persistent malware control, evading traditional defenses.