All right, so if I haven’t met you either at this conference or a conference in the past, my name is Adam Jahr. I am the founder of Vue Mastery. We are a comprehensive learning platform dedicated to Vue developers. So we have a library of content that includes courses on topics across the Vue ecosystem. We have a blog, we have conference talks. So all the talks from this conference and Vue conferences and other conferences in the past are accessible on our platform. So you can re-watch anything if you miss it or you wanna reabsorb the information a little more deeply. And really our goal is to give those resources and guide people so that they can master their craft and elevate their code.

So today we’re gonna be taking a trip through the Vue universe. Where are we headed? We’re going into the island of Pinia in order to understand a little nuances between the different patterns of how we can access mutate state and get a little more comfortable using it. So as we know, Pinia is the next evolution of state management in Vue beyond the Vuex. So it’s lighter weight, it is less prescriptive, more modular and more freeing. But as the old adage goes, with great freedom comes great responsibility. So when we have that added responsibility, it’s because we are able to now get creative about how we implement state management in our apps. And of course as we, kind of a common thread here, sometimes that creativity can lead to antipatterns and surprising expectations. So the purpose of this talk is to show some kind of parameters within which we can get creative because done well, this can lead to excellence where we avoid those antipatterns and elegantly architect our app to serve us for years to come. And that is what we’re focusing on today.

And if you know this guy here, Posva, he created Pinia. He also created Vue Router, excellent mind in the Vue core team. And he reviewed all of this so you can feel confident that this is Posva approved content. All right, so what exactly are we gonna be covering? We’re gonna look at organizing our Pinia stores and some ways to do that. We’re going to look at options versus setup stores. We’re gonna look at different ways to access and update our state. And we’re gonna look at some unique Pinia features such as Patch and Reset. We will be using this demo app to kind of apply these concepts against. So as you can see, it is a restaurant finder. You can type in the city here and a search term to find restaurants within a certain area. And it’s gonna pull up these and show, you can essentially log in and it’s gonna show the information pulled from Google Maps such as ratings, reviews. And we’re using Pinia to track global state, organizing that state within topic central logical concerns. So we’ll kind of uncover what that looks like.

But before we dive deeper into the Pinia patterns themselves let’s get clear on why you’d actually want to use Pinia. In the first place, especially considering that Vue 3 with the composition API, it already has a powerful built-in reactivity system that we could theoretically use for a more simple state management solution. So when we look at just using the composition API, we could theoretically create a reactive object and this could serve as a store. Need import reactive, set up your own little store as such. Then we just import that store into whichever component needs the state. And because of how Vue’s reactivity system works any component that imports this store could then directly mutate its global state. And then each component that depends on that state would then update its Vue automatically when those state changes would occur because of that reactivity system. So it essentially fed reactively that new value.

So again, when exactly is a state management library like Pinia even necessary? Well it comes in handy when you have, when you maybe have a team and you want consistent patterns for a collaborative organization, this is especially important, you know, large scale team, large scale apps. One of these patterns is how Pinia allows us to use predictable actions to mutate our state. And of course with Pinia we get transparency into the state of things in our app using the dev tools, helping with debugging. Here’s kind of a stream cast of peek into those dev tools so we can see how the different states of our app and timestamped and all that so we can get clear on what happened, why and maybe where our bugs are originating from. Also with Pinia, we get first class TypeScript support which is obviously increasingly important for JavaScript developers these days. And yeah, really all of these reasons combined result in a smooth, intuitive, collaborative developer experience for Vue developers.

So put simply, Pinia powers us with a robust and refined way to architect our app’s infrastructure so that our state management solution can scale as our app scales and not give us problems. So now that we’re clear on when exactly we would want to implement a solution like Pinia, we can explore its features. There are two ways to compose stores within Pinia. Just like with you know, Vue 3, you could use the options API or the composition API with or without the script setup. We can also in Pinia use options stores or setup stores. So when we look at defining a Pinia store, whether it’s an option store or a setup store, we must first import define store from Pinia then we pass in a string name. And this is gonna have to be unique. And the reason for that is Pinia’s gonna use that to track the state and it’s gonna give the dev tool something to latch onto. And also as you maybe extend the functionality of Pinia with plugins, either your own or someone else’s, that’s what the plugins are gonna use as well that unique name there. All right, so now let’s take a look at the structure of an options store first, this kind of store, it’s going to take in an object as its second parameter and you can imagine the state and the options and the getters within an option store as analogous to the data methods and computer properties of a component built with the options API. So it’s a very kind of one-to-one ratio, very similar analog there.

Alternatively, in a setup store, instead of the second option being a object in defined store, the second option is a function. So this kind of sort of will feel familiar to you if you’re composing your components with the composition API. So we create a state with ref or reactive, our action is gonna simply be a function. And… Yep, and then our getters, like a getter property. And then I wanted to point out here, note and it’s very important that we need to return and anything we want to be exposed and accessible outside of the component. So don’t forget to do that because it’s gonna make it accessible to other files and trackable by the dev tools and all that. So ultimately the answer to the question which should I use, the options or setup versions of the stores is, as our British friend said yesterday, “It depends,” but it depends on what? In this case it would depend on your team’s preferences, demands, code base, are you fully composition API, are you options API, are you a little bit of both? And we’ll also look at some nuances around the ways in which these two have some advantages over the other.

Specifically with the setup store, it allows us to use composables within them such as the VueUse library. We can also use Watchers as well. And we actually use both Composables and Watchers in that example app I was showing you. So if you notice this behavior here where if the user does not type anything into the city input, their current location will be found automatically. So if we look at the code for that inside of this store called Geolocation, we can see that it is indeed a setup store and it’s functionality relies on the useGeolLocation composable from VueUse to get the coordinates of our user. And then meanwhile the Watcher is keeping an eye on those coordinates to trigger an action to fetch location data from the Google Maps API. And when we talk about Pinia, it’s important to understand that Pinia is modular and it’s modular by design so we are encouraged by its very API to split up our state into manageable domains. This compares against Vuex where with Vuex, we had one route store file and then modules that broke off from that. With Pinia, we create stores devoted to each major logical concern in our app and then we can import those stores wherever they are needed within our app. And this modularity is gonna give us some added benefits.

So it’s gonna help bundlers with code splitting, it’s going to provide us with better type inferences, if y’all using TypeScript, it’s going to help boost our team collaboration and it adds some clarity for debugging as well. But when we talk about, you know, these domain specific organization of stores the question is how do we, what kind of mental model do we approach our app with in order to and elegantly categorize these stores appropriately? 'Cause it’s not always straightforward. So we’re gonna first, yeah, so basically I call this store organization or store-ganization. So the question is how do we store-ganize in an elegant way? So we’re gonna look at a more straightforward example and then we’ll look at a little more nuanced complex example. So back in our example project, we see that a user can register an account and the user interface is gonna change depending on whether a user is logged in showing their name and their favorites in the app bar. And to achieve this authentication behavior we’re gonna be tracking the user state, we’re gonna be having some actions related to authentication, login, log out, registration. So it’s pretty obvious and intuitive that this could all be grouped together into its own store where we might call it auth or authentication. So it’s pretty simple, straightforward, but let’s look at a little more less obvious case of store-ganization.

So remember how in our restaurants app we have these two inputs, the first input takes in a city and then the second takes in a search term to find relevant local restaurants. So the code for this, both inputs have event listeners that are triggering a function when the user types in texts and each of those functions is gonna make a call to the Google Maps API. So the city calls for latitude and longitude at the location typed in by the user. The search calls for relevant restaurants within a certain distance of that city. So in other words, both the city and search inputs are using geolocation data from the Google Maps API. So you might assume that you should then combine this logic into the same store and we would create maybe a Google Maps store. However, when we look at our project holistically, we might determine that there are actually quite a few actions that rely on the Google Map store. So that might become too much bulk in that one store. Lot of code for that one domain. And more importantly, the actions might not all be related to the same logical concerns. So to get clear on how this should specifically be store-ganized, we could break down the focus more on what is the Google maps API actually being used for and what state specifically are we needing to track? And when we ask those questions, we are clear that the first input is being used to make geolocation requests while the second is dealing with restaurants that match that search term.

So yes, those restaurants are nearby so there’s location involved, but that’s not their primary focus, like the first search input. So to, based on that reasoning it sounds like we could make two separate stores, one for geolocation and one for restaurants, each with their own shared logical concerns. But you might be thinking that there’s some nuance here because in the restaurant store when we request that list of relevant restaurants it requires us to use the geolocation data. So this means that we need to use the data from the geolocation store inside of the restaurant store. So does this completely ruin the approach that we just looked at of separating our stores out like that? Not necessarily because this leads us to another theme in Pinia called nested stores where we can simply import the store, in this case the geolocation store where we need it into the restaurant store and we’re able to access the bits of it that we need in here.

So some key takeaways for this section are we want to group related data into their own stores by logical concern. We can also organize stores by features within our app. We don’t wanna assume that a store should just necessarily be created around one API or library. And we can cross-share state actions and getters via those nested stores that we just saw. So if you’ve used other state management libraries, you might know that they tend to be a little more prescriptive, forcing us to access and mutate our state in a very specific way. And this can lead to some limiting rigidity and it might have some unnecessary overhead there. So one of the ways Pinia provides flexibility is by allowing developers to really make their own choices about the patterns that they use. So let’s take a look at how we can access our Pinia state in a few different ways. Now if we’re in a store itself, we have access to state properties in our actions and getters but there are some considerations to keep in mind as there are different, basically things are different within options versus setup stores. So in the options store, which you can see that we’re in, our actions need to be using this when we’re accessing state and within a getter in an option store, we’re gonna be passing in the state to be able to access it. Comparatively in a setup store for both actions and getters, we just access the state property directly. So just as we would within the setup function and a component using composition API, we don’t need to use this. So in this example, this state property is a ref. So it’s written as a city.value. And again, remember we do need to return everything because we’re in a setup store. So to make it accessible outside of itself.

All right, so now what about accessing a store’s state from within a component? There are a few ways we can do this. The most common of which is to import the store into the Vue component and then we would invoke the use store function. And this is gonna let us read and write to the state and we can do that using dot notation to access the state property on the store. We could push to it, et cetera. However, this can get a little bit verbose using dot notation like this. And over time get maybe a little less readable, burdensome. So we’re using a lot of different state properties and a component instead of using dot notation like this, we can make our lives easier by actually destructuring properties from the store so that we don’t have to write the full store name every time. But we have to be careful about the way in which we do this. So our first instinct might be to do something like this but it’s going to actually break the reactivity. So in Vue 3, you probably know that you can’t destructure props unless we use the helper method called toRefs. And in Pinia similarly, we can’t destructure state properties unless we use a Pinia helper. And that helper is called storeToRefs. So doing it this way is gonna keep the reactivity intact. Yeah, and then now we could, once we have that stored to refs, we can make use of that destructured state, push new data onto it, et cetera. Another way we could look at this is using v-model.

So we could use it to bind to something like our input here in the Pinia State so that our template is always staying in sync with the store and then it just reacts accordingly. So some key takeaways for accessing state. Those would be in an option store, we can use this. In an options getter, we pass in the state. In the setup store, we access state properties directly. We don’t need to use this. In a component, we can destructure state with a storeToRefs helper and we can use v-model to bind a value in our component to our store’s state. All right, so beyond accessing state let’s look at how we can mutate state because again, this is also less prescriptive in Pinia and we have a couple options. So when we compare this and look back at how we used to do things in Vuex, from the component we might dispatch an action and that action would then commit our mutation by clicking us forward in time to that new state that we can, we want to get process version of that state we could use a getter to achieve that. And this was really the recommended model for state management in Vuex and this is how everyone was doing it unless maybe you were breaking patterns against those recommended best practices. However, as most of us know by now, Pinia has gotten rid of that mutation step. So we now have a leaner and also a more freeing version of how to update our state.

So the most common way that we’re going to be mutating state is to trigger an action in the store that causes the state to be changed. So in this example, clicking the add to favorites button triggers the add to favorites action within our favorite store. And some people are, because you know they’re familiar with the Vuex way of doing things, they’re surprised that this is not the only way that we can be updating our state in Pinia 'cause we could also change our state, for example directly by assigning a new value to the state property. So in this example, we have a Watcher on the city value and if the user deletes the city, we clear out those state properties directly so the user then can start a new search.

Another way we can update state is to use the Pinia patch method. And so the patch method, this is gonna allow us to apply multiple changes at once to the store state. So here we’re passing in an object with the updated properties inside of it. And when we use patch, it comes with some added benefits because one of those benefits is gonna create a single entry in the dev tools, not like those multiple ones. And if we were to follow this convention throughout our application, we could maybe run a search for patch and then we would be able to locate everywhere we’re updating state in bulk like this.

Additionally, something useful to note about the patch function is that it can take in an object or a function as a parameter. So if we for example have state that is an array, we can use JavaScript array methods on it to update that state in a more nuanced way. In addition to the patch method, you also have the reset method. And this is going to allow us to reset our store’s entire state to its initial value. So in this example in our logout action, we’re resetting essentially the entire store, clearing out that state when the user logs out. And do note that we are in an option store here. So we’re saying this dot. We could also use reset within a component. So here we’ve got it on the button. So when we click, we’re accessing that off store and resetting it like so. And then take a look at this example which is interesting how we can use it in the router itself. So here we’re saying whenever the user navigates back to the homepage, we’re gonna then clear out that previous search. So we’re gonna have router based resets of state. So I talked about some benefits that the setup stores had over options stores. Unfortunately the setup store is only gonna work for options. That’s it’s kind of one tick in the pro column for the options stores. And this is actually because the reset method relies on the state function and in order to create a fresh state. And so that’s gonna replace the current store dot state with a new one. But we don’t have access to the store function in a setup store. So that’s why the reset is not gonna work in that setup kind of store. But there is a workaround. So you could actually create your own reset method for your store and you essentially write an action that resets it as such and call it like this. So you’re not saying you know, $reset, you’re saying reset and your store name, basically. Also when it comes to mutating state, Pinia is gonna offer us a helpful method and it’s the onAction.

And this is something we can use to get detailed info about our actions. So as you can see here, this method has a number of hooks and we can use these hooks to perform some logic when a certain action happens. And note how we also are able to pass in state optionally as a second argument in case we need it and wanna process it based on those different hooks. So here in this example, we’re using it to log information about which action was triggered in the authentication store. We look at that in the browser when we log in here, we should see that in the console. Cool, we got that from the onAction helper. Cool.

So there are definitely other ways to work with Pinia. We covered a number of them in this talk. In the full version of this talk, so this is kind of a concatenated version of the full Proven Pinia patterns course over at Vue Mastery. We talk about extending Pinia’s functionality and writing plugins and how that works. And this is part of an entire playlist of Pinia courses over on vuemastery.com. So if you need something maybe a little more fundamental you would wanna start with the Pinia fundamentals where we build a to-do app using the essence of Pinia. We have a Q&A with Eduardo asking some kind of common curiosities and questions about the Pinia Library. We also have a course by Eduardo and this is a little more advanced where he talks about some elegant ways to use Pinia from his perspective, you know, as the library author of it. In addition to the Pinia content, we have content across other relevant topics for Vue developers. So we have Nuxt content, a whole playlist, whether you wanna work with the Nuxt content module, Ben Hong teaches that course and shows us how we can use that to build a blog. We have some Nuxt 3 Server content in development right now and we just released the Nuxt 3 Middleware course as well. We also, if you are a fan of the VueUse library which just seems like a lot of us are here, we have a course taught by Gregg Pollack and in collaboration we worked with Michael Thiessen to create this course and this is basically referencing best practices and unpacking how the VueUse library approaches composables in order to use that as a frame of reference to create our own custom composables. We also have a class on Utility-First CSS using the popular Tailwind library. We’ve got a Vite course taught by Evan You himself and other content exclusively taught by Evan You for our platform and really have a full categorical kind of playlist that break down all the different topics that you might need to elevate your code and get where you want to be to be the best Vue developer you possibly can 'cause I feel like that’s why we’re all here, right?

Cool, I did wanna point out that we have Team Accounts if you want to elevate your team together, we bundle those together and we’re offering that at 55% off right now. So you can go to our website to reach out to us to get set up for those. And while you’re at the website, if you want to have kind of a easy Pinia reference, whether on your actual desktop or your digital desktop, we’ve got these to download these Pinia cheat sheets free for you guys over there. So that is my talk. I hope this gives you a little more clarity on the different ways that you can be using Pinia and using it in a way that is, you know, proven so that you can build your state management in a way that lasts for years to come. So thank you for your time and attention. I hope you enjoy the conference.