• Pinia tries to be as close to Vuex as possible. It was designed to test the proposal for the next iteration of Vuex and was successful as we currently have an open RFC for Vuex 5 with an API very similar to the one used by Pinia. Pinia’s author I (Eduardo) is a member of the vue.js core team and is actively involved in the design of apis such as Router and Vuex. My personal intention with this project was to redesign the experience of using the Global Store while maintaining Vue’s approachable philosophy. I made Pania’s API as close to Vuex as it keeps moving forward, making it easy for people to migrate to Vuex and even merge the two projects (under Vuex) in the future.
  • While Vuex collects as much feedback as possible from the community via RFC, Pania does not. I test ideas based on my experience developing applications, reading other people’s code, and answering questions on Discord. This allows me to provide a solution that works, releases it often, and improves it when people use it by making major changes in the major release (which is unlikely to happen after the first stable release) if necessary.

Compare with Vuex 3.x/4.x#

  • Vuex 3.x is the Vuex of Vue 2 and Vuex 4.x is Vue 3
  • The Pinia API is very different from Vuex ≤4, namely:
    • Mutations no longer exist. They are often considered very verbose. They initially brought DevTools integration, but that’s no longer an issue.
    • There’s no need to create complex custom wrappers to support TypeScript, everything is typed, and the API is designed to take advantage of TS type inference as much as possible.
    • No more need to inject, import functions, call them, and enjoy autocomplete!
    • There is no need to add stores dynamically; by default they are all dynamic and you won’t even notice. Note that you can still use the store manually to register it at any time, but because it’s automatic, you don’t have to worry.
    • There is no more nested structure of modules. You can still implicitly nest stores by importing and using stores in another store, but Pinia provides a flat structure by design while still supporting a cross-composition approach between stores.
    • No namespace module. Given the flat architecture of stores, “namespace” stores are inherent in the way they are defined, and you could say that all stores are namespace.

Install and use

  • yarn add pinia@next
  • npm install pinia@next
  • This version is compatible with Vue 3. If you are looking for a Vue 2.x compatible version, check out the V1 branch

use

Mian. Ts/mian. Js

  • import { createPinia } from’pinia’
  • app.use(createPinia())
  • SRC folder to create a repository folder

Use in files

  • Before delving into the core concepts, we need to know that store uses defineStore() and that it needs a unique name, passed as the first argument:
  • Once instantiated, you can access any property state, getters and actions defined directly in the store
  • This name, also known as ID, is necessary and Pinia uses it to connect the store to development tools. Name the returned function use… Is a cross-composable convention to make use of idioms.

state

Create the state

The use of state

  • Just import the defined file and execute the thrown method
  • Pinia fully supports typescript, there is no need to create complex custom wrappers to support typescript, everything is typed, and the API is designed to take advantage of TS type inference as much as possible.
Note that store is a wrapped object reactive, which means. Value does not need to be written after the getter, but, like props in setup, we cannot deconstruct it

StoreToRefs deconstruction state ()

  • To extract properties from storage while maintaining their reactivity, you need to use storeToRefs(). It creates references for any reactive properties. When you just use the state in the store but do not invoke any operations

Direct reading and writing

  • By default, you can read and write state directly from the Store instance access state without affecting the repository pre-existing values
  • Does not affect the original value in the warehouse

$reset() resets the status

  • The state can be reset to its initial value $reset() by calling a method on the store:
  • An action is needed to change the value in state, but only the usage is shown here

The state response type

  • Try to use computed packages when using state in components, because setup only executes once, and if you go straight to const counter = store.counter, you only get the value that was initialized the first time, and it doesn’t update if the data changes
  • With computed, the data changes as soon as it changes, and computed has its own data cache

Change the state directly

  • I will directly introduce the instructions on the official website here, because I find it difficult to maintain the data in state directly

Change the state

  • You can replace the entire state of the store by setting its $state property to the new object
  • store.$state = { counter: 666, name: ‘Paimon’ }

getters

  • The Getter is exactly the same as the computed value of the Store state. They can define defineStore() with the getters property in. They receive state as the first argument to encourage the use of the arrow function

Getter using this

  • In most cases, getters depend only on state, but they may need to use other getters.
  • Because of this, we can access the entire Store instance by defining a regular function, but we need to define the type of the return type (in TypeScript).
  • This is due to a known limitation in TypeScript and does not affect getters defined with or without arrow functions:
  • To use this directly, you need to define a return type. If you do not define a return type, an error will be reported

Visit gettes

  • You can access the getter directly on the Store instance
  • You can use computed packages

Accessing other getters

  • As with evaluating properties, you can combine multiple getters. By accessing any other getter this. Even if you don’t use TypeScript, you can use JSDoc to indicate your IDE type:
  • Define a user repository file
  • Introduce the user repository into the index file
  • use

actions

  • Unlike Vuex, Pinia only provides a way to define how to change the rules of the state, abandoning mutations and relying solely on Actions, which is a major change.
  • Pinia makes Actions more flexible
  • It can be called from a component or other action
  • Can be called from an action in another store
  • Called directly on the store instance
  • Support synchronous or asynchronous
  • There are any number of parameters
  • Can include logic on how to change the state (which is what Vuex’s mutations do)
  • You can change the status properties directly with the $patch method
  • use