Welcome! Happy to see you in the second part of my Vuejs Amsterdam Conference 2022 summary series, in which I share a summary of all the talks with you. You can read my JSWorld Conference 2022 Summary 2022 series (in four parts) , where I summarized all the talks of the first day. You can also find the . here first Talk where Evan You talks about the State of Vue in 2022 here (Recurring) Introduction After two and a half years, JSWorld and Vue Amsterdam Conference were back in Theater Amsterdam between 1 and 3 June, and I had the chance to attend this conference for the first time. I learned many things, met many wonderful people, spoke with great developers, and had a great time. On the first day the JSWorld Conference was held, and on the second and third days, the Vue Amsterdam. The conference was full of information with great speakers, each of whom taught me something valuable. They all wanted to share their knowledge and information with other developers. So I thought it would be great if I could continue to share it and help others use it. At first, I tried to share a few notes or slides, but I felt it was not good enough, at least not as good as what the speaker shared with me. so I decided to re-watch each speech, dive deeper into them, search, take notes and combine them with their slides and even their exact words in their speech and then share it with you so that what I share with you is at least at the same level as what I learned from them. A very important point Everything you read during these few articles is the result of the effort and time of the speaker itself, and I have only tried to learn them so that I can turn them into these articles. Even many of the sentences written in these articles are exactly what they said or what they wrote in Slides. This means if you learn something new, it is because of their efforts. (So if you see some misinformation blame them, not me, right? xD) Last but not least, I may not dig into every technical detail or live codings in some of the speeches. But if you are interested and need more information, let me know and I’ll try to write a more detailed article separately. Also, don’t forget to check out their Twitter/Linkedin. you can find the program of the conference. Here Getting more out of your Pinia Stores Pinia might be a light library with a simple API but it takes advantage of many Vue Reactivity concepts like Effect Scopes, which are unknown by most. In this talk we will go through some of the internals of Pinia, understanding them and discovering how to enhance our usage of Pinia. During the time I was creating Pinia, I had a lot of experimenting going on with the and and the whole reactivity system of Vue, which gave me a lot of insights on how to keep that one single source of truth that we love so much in Vue. Refs Reactives State Alchemy with Pinia Pinia is the successor of Vuex, without compromising all the developer experience that comes with Vuex. It is compatible with Vue 2 and Vue 3, and it’s lighter and Vuex. One of the advantages of Pinia is that it’s Fully (automatically) type-safe. This library is based on the Composition API, but you don’t need to use the Composition API to use Pinia. It has a testing library and a Nuxt module as well. Vuex vs Pinia In Vuex you have some important rules: You can only change the state in mutations. You have to shout in action if you want to do it! (That’s why we write it in uppercase!) Mutations have to be synchronous and only actions can be asynchronous // Vuex import { createApp } from 'vue' import { createStore } from 'vuex' // Create the store instance const store = createStore({ state: () => ({ count: 0 }) mutations: { INCREMENT: state => { state.count++ } }, getters: { double: state => state.count * 2 }, actions: { async increment ({ commit }) { await someAsyncCall() commit('increment') } } }) // You have to use it as an Application plugin createApp(App).use(store).mount('#app') Now let’s take a look at Pinia: // Pinia import { createApp } from 'vue' import { defineStore, createPinia } from 'pinia' const useStore = defineStore({ state: () => ({ count: 0 }) getters: { double: state => state.count * 2 }, actions: { async increment () { await someAsyncCall() // There is no mutation, you can access the state with this keyword this.state++ } } }) createApp(App).use(createPinia()).mount('#app') There aren’t many changes, except you no longer have to shout to change the state, and there is a function that is not creating a store, it’s defining a store. The difference is, that function is going to return another function that we call to get the actual store. The reason is to handle all the different ways we use the store to have an out of the box dynamic module registrations. In the end, the function creates the Pinia instance. CreatePinia() What does the Pinia instance really do? If you look at the Pinia instance you’re going to notice two things. A function which is for Pinia plugins. use() A state is just a of an initially empty object which gets populated after you call some stores. ref That state is instantiated inside its own . EffectScope To explain we can talk about components. When you have a component that is mounted, it’s going to create its own , which is going to collect all the reactivity variables like watchers, computed, etc. under its umbrella, and when the component is unmounted, this is disposed and all the variables go away. EffectScope EffectScope EffectScope It’s the same for Pinia, except it never disappears and is always there. Pinia Holds State The stores are never going to hold the state by themselves, they're going to transfer that to the Pinia instance. So you can access the state at any time with . pinia.state.value The first time you call the in your application, it’s going to put the initial state into the store using the id of the store as the key. useSomeStore() const authStore = useAuthStore() // Here the id will be "auth" pinia.state.value.auth = { /* ... */ } // If we call another store, It will add another object const cartStore = useCartStore() pinia.state.value.cart = { /* ... */ } So as the user navigates through the application, the store keeps growing as needed. pinia.state.value = { auth: { /* ... */ }, cart: { /* ... */ }, // other stores' state } Pinia connects state You can access the whole state of a store through . This variable is just a getter to access the store in Pinia. $state There are three different ways of accessing a state in the store. Through the Pinia instance: pinia.state.value.auth.user.login Through on the store instance: $state authStore.$state.user.login Directly through the store instance: authStore.user.login Any of these variables is going to yield the same result, and also if you write to any of these variables you are also going to write to the three of them, in fact, you are only writing to the Pinia state, because there is only one source of Truth. In Vue composition API there is a function that gives you a to a reactive object. So if you have something that is reactive, you can get a to any part of the object and it will be connected and if one of them changes, the other one will change as well (and you have only one single source of truth). toRef ref ref When we define the store with : defineStore const useAuthStore = defineStore('auth', { state: () => ({ user: { login: 'alice', }, }), }), // pinia.state.value.auth and when we instantiate the store with the function and pass an object to the state, effectively what is happening is that we are getting a out of the state. useAuthStore ref useAuthStore() pinia.state.value.auth = { user: { login: 'alice', }, } authStore.user = toRef(pinia.state.value.auth, 'user') We don’t have to write , we just read the property or write to it using which is called ref unwrapping. authStore.user.value.login .value is a reactive object so any passed inside is going to get unwrapped. authStore ref Ref Unwrapping When you create a reactive object, any passed inside at any level of that object gets automatically unwrapped, so you don’t need anywhere and is gonna be type-safe. ref .value 💡 You can avoid this behavior with and shallowRef() shallowReactive() pinia.state = ref({}) // or reactive({}) pinia.state.value.auth = { user: { login: ref('alice'), // Don't do this! 🙅🏻♂️ }, } pinia.state.value.auth.user.login // alice You should never write a inside a reactive object because there is no point in doing so, writing in the code above is the same as writing the string . ref ref(’alice’) ‘alice’ But what is interesting is not refs themselves, but refs with all their behaviors attached to them. Composables Composables are functions that have a stateful return. One of the common composables is which is from a library called , and it gives you a that is going to read from and write to local storage. useLocalStorage VueUse ref pinia.state = ref({}) // or reactive({}) pinia.state.value.auth = { user: { login: useLocalStorage('pinia/user/login', 'alice'), }, } pinia.state.value.auth.user.login // alice This means that we can call that composable inside of the state function when we define a store: import { useLocalStorage } from '@vueuse/core' const useAuthStore = defineStore('auth', { state: () => ({ user: { login: useLocalStorage('pinia/user/login', 'alice'), }, }), }) So if you have composables that return a writable source of truth (like a ), you can put them inside state and they are going to get unwrapped. So the actual behavior that may be interesting for us becomes an implementation detail we don’t need to care about anymore because it is just going to work out of the box. For example or . ref useColorMode useRouteHash But if you have a read-only state — which is more like a computed property — or you have a function — which is more like an action — it’s going to be a little different and we will see later how to use them. When does this not work? If you are doing CSR it works fine. However, if you are doing SSR or SSG there will be some problems. The problem is the state function is only called once the first time we instantiate the store. In CSR, we start with an empty state, then we call the store with and that’s going to instantiate the state and become reactive, easy! useAuthStore() In SSR, we do the same, But the problem is when the page comes back to the client on the browser, although we have the Client Side Rendering again, on the server, the state was already executed and it was already instantiated once and we are not going to do that again on the client. That means we don’t get an empty object here and we get the object from the server. So when we call , is no longer called, and we no longer have that composable creating all the watchers, connecting all the event listeners to the window, it becomes just a string and probably the server is going to give us because there is no local storage. useAuthStore useLocalStorage ‘alice’ 💡 Fortunately VueUse is going to make the local storage function work on the server as well. 💡 Some composables require a little bit more work if you want to make them work on SSR. For example, you have to check your current instance or check if there is a window object that you can rely on. If you want to learn more, you can check the source code of VueUse. It’s very comfortable because in the documentation, at the very bottom of every function you see a link to the source in the Github repository. But what do we need to make this work on SSR? We need an extra function called that is going to create the watchers and event listeners on the client-side. This function is called if the initial state exists at store creation. hydrate() import { useLocalStorage } from '@vueuse/core' const useAuthStore = defineStore('auth', { state: () => ({ user: { login: useLocalStorage('pinia/user/login', 'alice'), }, }), hydrate(state, initialState) { state.user.login = useLocalStorage('pinia/user/login', 'alice') }, }) So that state is set by is going to be replaced by the hydrate function. To recap: UseAuthStore On SSR: We have an initial state: pinia.state.value: {} We call useAuthStore() useAuthStore() We have the new state: pinia.state.value: { auth: { /* ... */ }, } and that is going to be sent to the client. Then on CSR: We start with that state pinia.state.value: { auth: { /* ... */ }, } We call useAuthStore() useAuthStore() // does not call state() And then we have the function adding the little bit that we were missing from the state function again hydrate state.user.login = useLocalStorage('pinia/user/login', 'alice') Options Store vs Setup Store Options store which is pretty much like options API is what we talked about so far. Setup stores are stores that are defined with a function similar to the setup function in composition API. const useAuthStore = defineStore('auth', () => { const user = useLocalStorage(...) return { user } }) So in this case we don’t have multiple properties like state, getters, and actions, we just have one function and it has to create reactive objects if you want a state and return them, and it’s going to have computed for getters and functions for actions. const useAuthStore = defineStore('auth', () => { const user = useLocalStorage(...) const isLoggedIn = computed(() => /* ... */) function login(user, password) { /* ... */ } function logout() { /* ... */ } return { user, login, logout, isLoggedIn } }) In the end, you return anything you want to expose and you can keep anything you want to keep private. Because we have just one function that defines everything, we can just not call it! We have to call it both on the server and the client. We need to hint to Pinia that e.g. shouldn’t be hydrated. useLocalStorage import { defineStore, skipHydrate } from 'pinia' const useAuthStore = defineStore('auth', () => { const user = skipHydrate(useLocalStorage(...)) const isLoggedIn = computed(() => /* ... */) function login(user, password) { /* ... */ } function logout() { /* ... */ } return { user, login, logout, isLoggedIn } }) What happens behind the scene is that normally when we’re on the client after the server has rendered the application, the store goes through all the different properties that have been put into the initial state, takes the values from the initial state, and put them into the store state; more exactly into the ref that we return in the function: user.value = pinia.state.value.auth.user // alice That ref created by the store is then transferred into the Pinia state so that we have one single source of truth: pinia.state.value.auth.user = user // 1 source of truth The thing is with skipHydrate, we are skipping the first line, so the that’s no longer happening. user.value = … We should not use everywhere. If we look at the for example: skipHydrate useEyeDropper import { defineStore, skipHydrate } from 'pinia' import { useEyeDropper } from '@vueuse/core' const useColorStore = defineStore('colors', () => { const { isSupported, open, sRGBHex } = useEyeDropper() // ... return { lastColor: sRGBHex, // Ref<string> open, // Function isSupported, // Boolean } }) Among these three, only the is going to become a state. lastColor What is interesting is that we can stack these refs together. So we can pass the RGB hex ref to the local storage. import { defineStore, skipHydrate } from 'pinia' import { useEyeDropper, useLocalStorage } from '@vueuse/core' const useColorStore = defineStore('colors', () => { const { isSupported, open, sRGBHex } = useEyeDropper() const lastColor = useLocalStorage('lastColor', sRGBHex) // ... return { lastColor, // Ref<string> open, // Function isSupported, // Boolean } }) In this scenario, we want to use , because the relies on what the browser is seeing and doesn’t care at all about the server response on the initial value for the . skipHydrate useLocalStorage lastColor If we were using only the , wouldn’t need the because most of the time we don’t care if we hydrate from the server-side response or not, because there is not a new value in the browser context that is interesting for us and that could get overwritten by what the server sent. useEyeDropper skipHydrate But if we use the local storage then we need to make sure that the one in the browser prevails and the server one is just ignored. So what you need is not to use on every single ref, just on the ones that you want to avoid setting the value from the initial state, and only on SSR of course. skipHydrate Summary Options Store Can use basic Composition API inside state() Can only return writable state Use for composables hydrate() Setup Store Use any Composable (like in ) setup() Automatically tells apart state from actions from getters Use to ignore values from the server skipHydrate() End of the second Talk I hope you enjoyed this part and it can be as valuable to you as it was to me. You can find the next talk about Histoire . here Also published . here
