JS Nation

JSNation 2022

Managing state in Vue3 application

Mikhail Kuznetcov

Vue.js Live Conference

Vue.js London Live 2021

Modern State Management with Vue 3

Hi, now we are going to talk about modern state management with VUE 3. Hi, I'm Vanessa, you can find me online as Wanzel. I'm responsible for the frontend at SEVI. I'm co-host of two different podcasts, Expect Exception, where we talk about frontend testing and Working Draft, a German podcast about web development. And roughly a year ago, in September 2020, I can remember as I sat there watching Avenue on the VUE.js conference, finally saying, hey, VUE 3 is out there. And now I want you to go with me on the journey, how I installed VUE 3 and used alternative concepts to use VUE 3 completely without Options API and also without VUEx. I do not suggest that you should use VUE 3 without Options API or replace VUEx. I want to tell you that the Composition API is so powerful that we actually can use VUE without both of those tools. And it made sense for me in a state where I had a really small application, which I started with VUE 3 from scratch and did not have to migrate from a VUE 2 application. In the code examples I will show in the next couple of minutes, I will use the setup function. And I prefer to use ref over reactive. But everything I will show now, you of course can use the script setup syntactic sugar instead. And you can choose to use reactive instead of ref if you prefer to. And as my components of my very small VUE 3 application roughly a year ago started to grow because I had some more complex problems which needed some more complex solutions, I and therefore also this talk were mainly inspired by those three articles. Group extract share pattern, state management with Composition API, and should you use Composition API as a replacement for VUEx. Let's focus on three of the VUE's APIs for now. The options API, reactivity API, and composition API. The options API, we can think of this object structure that we know from VUE 2 single file applications, single file components, where we have our data, computed methods, watch mounted and many more. And the reactivity API is not that different of that. We have ref reactive for reactive data computed, watch, watch effect, unmounted, and many more. But the clue is that I can now import those functions directly from VUE. I don't have to use a VUE single file component or a mixin to use those tools. I can import them in any JavaScript or TypeScript file. And then the composition API is providing us with a setup function where I can bring all the magic together and use all of those powerful tools of the reactivity API in my VUE component. So let's have a recap of how to write a component in VUE 2 or in VUE 3 using the options. Here I have a template with a paragraph with greeting and full name. If I scroll down to my script block, I can see here that I have a data function, which is returning an object with greeting and hello. I have properties for first name and last name. And I have a computed property for the full name, which is returning me a first name with a space and the last name. So this is one component with just one purpose, which is doing its job quite well. Kind of a funny side note is that I initialized this greeting here as a reactive data attribute, although I actually don't ever change this and won't need this observers on it anyway. But I was never sure where to put this constants using the options API. The problem I now want to focus on is that logical units, if the component is growing and growing, are spread over the whole script block. So what do I mean with this? I've prepared this code sandbox here. And here we can see as well, we have our greeting and full name to say hello to the user. But then we also display the user's items where we loop over and also provide a delete item function to delete something. If I scroll down to the script block, I now want you to focus on the order of how things are happening. I have the data function, which is running an object with the greeting and items. The properties having stuff from the greeting, a computed property with the full name of the greeting, then a method with the function delete item of the items. So the categories bind to the way that the view skeleton, the view object here is structured. So everything in data is in data. Every computed property is in computed property. Every function is in the methods block. So now we have a point where we have now greeting items, greeting, greeting, greeting. So they are shattered over the whole file. And this is kind of grows and grows and grows looking like this. Of course, it can be a solution to split the component, but let's focus on it doesn't work anymore. We can't split any further and we still have this lines of code not really bind together. And what the composition API is providing us with is the possibility to group logical units together again so that everything is related to the greeting. We can imagine being in this light blue box on the top and everything related to the items, we can imagine to be bind together in this darkish blue, almost black box here. So the composition API enables developers to encapsulate logical units in one single file or in shared with others. What I mean with that, as I learned about the composition API a year ago, it always was sold to me as this is the go-to thing instead of mixing. Use the composition API to share functionality. It's really powerful. But then I started with Vue 3. I thought, but do I really need to share logic to use the composition API? Because I really like how it works, the composition API. And I actually like to use it also without sharing functionality. And this is exactly what we will do now. So I have created some Hello World files on this Vue single file component playground. And the first one is a reimplementation of just the greeting stuff we saw beforehand in Vue 3 composition API. So here we have our template with the greeting and full name. And we import computed from Vue. If I scroll down to the properties, I see the first name and the last name. And here below, I have the setup function, which is giving me a const greeting with hello and a full name as a computed property. And then I return everything to give it over to my template. What is kind of cool is that it's just JavaScript, right? It feels good to me. Actually, it felt a bit sweat the first time I saw it. So here we have the const greeting as just a pure const without wrapping it in a data object, not using a created lifecycle hook to initialize constance, just a const. And when we have a full name as computed property. But of course, also here, the functionality can grow a bit. We are switching to our Hello World 2 component, where I have also my items, which I also can delete. I loop over them in the template. And I have my method to delete them. I import computed and ref now from you. And if I now scroll down to the setup block, what we can see is the same implementation for greeting with a greeting and full name, and then a logical unit of the items and a method to delete the items. And as I started with U3, all of the time, my muscle memory was like, oh, yeah, I have to put everything data related in the beginning and then all of the computed properties and then all of the methods and then all of the lifecycle hooks until I remembered, no, no, I don't have to use this anymore. I can now bind the logical units. I can display them together. But then, of course, my component was growing a bit. And I was like, yeah, how do I actually say that these things belong together? Do we have a comment like start items block and items block? How do I achieve this? So I started to refactor this component a bit. The same template we saw before, but now on top, we have two different functions, the use greeting and the use items, which encapsulate all of the functionality in those function where I have everything related here and return the necessary properties to the outside. And if I scroll down to the setup block, I can now see that it's getting a bit more cleaner if it was getting a bit nasty. And I can outsource all of this logic to somewhere else. And here, I can clearly see, OK, I have the greeting and full name items and delete items coming from those two composables. But now the next step is, hey, it would be super amazing if I can use the use items also somewhere else because I really need this functionality also at another component, which leads us to Hello World 4, which is also refactoring a bit further. I only import computed now again from Vue and not ref anymore. But now I also import use items from use items. Switching to this file, I can see import ref from Vue on top in a plain JavaScript file. And the same function with the use items we saw just before is now an exported function in this file, bringing us all of the functionality as a composable in our Vue single file component. If I scroll down to the setup block, I can see here again I have my use greeting and the use item. I want to give you a small hint what I'm doing here. So what you can see here is that I first thought it is super cool to use ECMAScript destructuring to get everything related to the use items directly into the template. This is just one line of code. This looks super cool. But then a problem that occurred to me is that I don't have any IDE support here on this playground. So if I try to look for the delete item, I'm lost. I don't know where it's coming from. And therefore, what I tend to do is really to go the explicit way, to not use magic provided by a language by me, but really saying explicitly, OK, I import those things from there. And now I can see, OK, the delete item is coming from the use items, and the use items is coming from this file. So we already wrote our first composables. If you are looking for a bit more inspiration, check out this Vue Use Git repository where you can find already a lot of in TypeScript pre-written composables that you can use, Axios functions, and so on and so forth. I think it's also already Hektoberfest time. So also if you want to get engaged in open source, this could be a start point for you. OK, but now let's focus on state management. So how did I thought state was working when I started with Vue 2 in 2017 or something like that? First, I did the anti-pattern of props drilling. So I used props emit event handling to get something from a root component to its really like grand, grand, grand, grand, grand, grand, grand children to just emit, emit, emit, emit everything up again. This was not really maintainable. Then I thought I'm smart and I used the global root, the dollar root, to attach variables to this global root thing until I realized this is not working. This is not really reactive. I think I should really not use this. It was also not really discussed. It was just really hidden in the API documentation that there is something like a global root. And then I sat down and thought, OK, state management sounds important, sounds difficult, store sounds difficult, observables, VueX, I'm not sure, but I will install VueX now. And it was really just mind-blowing how simple this made it for me to create state management by only creating this index.js file. And already I had some state. It was a really powerful tool because it was so simple to use to then focus on the complex parts of writing code or finding solutions for bigger problems. But when I was starting with Vue 3, I thought, hey, give me a second. I think I can do achieve state management actually with composable. And it was really like, it was not because VueX wasn't ready for Vue 3 yet. They were pretty quick and there was a migration guide. But I was interested in what is everything I can actually achieve with composables. I want to get a step further here. And here I have another code sandbox, which will probably load soon. But I think I also have it preloaded here. Yes, I do. So here I want to focus first on the cart items, which we see here. And now I have a bit more of a realistic example. So if I reload this, you can see that there will actually be like three seconds of a loading time because usually I fetch the items from a server. So I have three seconds of loading. And then I see the items. And here I have a first item. So what I have to buy next are the eggs. And then I have my list of items. And here I really use now a state with if loading where I can set a loading state if it's still loading. And in the script part, I additionally use now the unmounted hook where I can fetch the data. So going to the setup function, we can now see the state with the items and the loading. And then I have the important function here are the load items where I set the if loading to true. Since I don't actually have a real endpoint that I can talk to, I use a use sleep function for three seconds. And then I set some dummy items, my eggs and my milk. And if everything works out, I can set if loading to false again. I also have my method to delete the item. And I have a computed property for the first item. And I use the unmounted lifecycle hook to load the items as soon as my component has mounted. OK, so far so good. We have something looking like a state, but it doesn't really feel like state management right away. So now I want to go to the app root component and switch to a different alternative of this application and use now two different components which are both providing us our items. So if I save this and reload, in the meanwhile, I will go to the cart items alternative, which is looking pretty similar to the favorites. So they are both just showing our items. So on the cart items alternative, I scroll down. And instead of the whole logic we saw beforehand, I can now see that I import the use items composable. And I get all of the necessary data from the state, load items, first item, delete item. And unmounted, I call the load items function. Now I can see here my three seconds loading. And I can see two times my list for my items. And here I want you to focus on the local state management. If I open the file, which I thought I had opened before, but I do it again for this composable, I can now see that the state here is outside of the component of this export function. And the rest of the implementation is the same one as before. It's just copied over with one important difference. So here I import additionally the read only keyword by view to have this store like of feeling of this composable, to have the single source of truth what we expect how a store should behave like. And now I want to put the state inside of this exported function. And if I'm doing this and wait for it to reload here, come on. And they are loading for three seconds. And I have my X, which I can delete in those local state. And here below, I can delete the fresh milk on those local state management as both the card items alternative and the favorites are both using this use items, which has the state initialized inside of this function. But if you think, hey, this is kind of weird, this is not what I expect from state management. I expect it to be global. This is achieved by just moving the state on top of the export. And I will reload this again. And then you can see that, therefore, I just created the state now once. It's no global. It doesn't change. We don't initialize it a couple of times. We just export this function a couple of times. So after I installed all of those dependencies, you will see that I can now delete the X and they will be deleted twice. So they are loading. And global state management. And the next point, if you think, hey, this is not looking like I would expect like a store really to look like, you can also use an alternative to this alternative. You can use the provide and checked pattern, which was already given to us at view two. And this is this code sandbox where I start with the app.vue root component. And you can see here that I import a store and I import a hello world. And I register the component hello world and I provide the store. What is the store? Let's have a look at the store at the index.js file here. So in here I have computed ref and read only where I have my state, a first item, a computed property, which is looking like a getter. And then I have functions that looks like a setter. And just out of fun, I called them set items in this uppercase syntax. And then I export for the state, which is read only my getters and my setters. So this should feel more like the view X way, the store way of doing things. And if I check out my components, I can go to hello world where I actually don't have any knowledge of the store at all, but I registered the child one. And in the child one, I import and checked from view, scroll down here and I in check the store and I can use the store in this child component using provide and check pattern and delete my data and my items here because I finally bought them. And this is also a global state management. So if I would inject the store in some other component, it would still work. So that's everything about the state management in view free using composables. Thank you very much. See you later.


Vanessa Otto

Structuring A Massive Vuex Store

Hello Vue.js London! I'm so glad for speaking here today. My name is Domagoj Widojk. Feel free to call me Dom because it's just way easier to pronounce. I work at Orbital Witness, a cool London tech startup somewhere between prop tech and legal tech, and I also live in London. Today I will be talking about structuring a massive massive UX store. How to create an architecture that is scalable, flexible and maintainable. Currently we're using this architecture at Orbital Witness. We have zero problems with it. Let's dive in. I will start with an example of a simple store. I will be expanding that store in every step and presenting you the challenges we need to solve and obviously sell them. We're going to start with the simplest store possible. We're using create store from UX and we're creating an empty store with empty state actions, mutations and getters. I won't be explaining those. I assume that you already know that. I will focus on how to create a store and make it scalable, make it appropriate for usage in huge apps. Let's add some properties here now. Usually in your huge apps you're going to have thousands of different properties. Right now only two of them are enough. Username and organization name and obviously some mutations to set both. What would happen if this file had thousands of properties? You can imagine just like adding adding adding things here and file will just become bigger and bigger and bigger. We don't want to do that. If we're going to do that, why don't we just keep all of our code in app.vue and forget about components? Jokes aside. Let's see how can we fix this problem. To do so, we're going to use a native UX feature called modules. Modules allow us to separate the concerns, to isolate different parts of the store and to make mini stores within our massive store. Take a look at user module for example. Here we took everything connected to the user. So name and its mutation to set that name. We are also passing actions and getters as an empty object because we don't have any right now. And what is really important here is that namespace attribute which is set to true. Namespace attribute allows us to register those properties for that mini store to local namespace of that module. In that way we can access those properties from any other module which is good because namespace set to true prevents us from accidentally accessing some of the local modules properties. You might think of that as a limitation, right? Because sometimes you actually need to trigger some methods from the different modules but you can't right now. Well, you can but you need to have an intent to do it. So it is possible but you just need to have an intent. But this is definitely good because we're preventing those accidental triggering. You can have same state properties with the same name or mutations, actions, getters with the same name. Namespace set to true allows us that and its default value is false. In that way all properties will be registered at the global namespace. Maybe you want to do that but just be careful about it. Organization module is literally the same. So we took everything connected to organization, set namespace to true and we're exporting default that object. If we take a look at index.js file, the things have changed a bit. So now we have user module and organization module. We need to import them and then we need to pass them to modules object for mapping those imported modules to a certain name. Right now it's user and organization. This is cool. So we've already separated our store in different modules. They are isolated. We can't access them by an accident but there's still something we need to solve. Let's see how can we use these mutations right now. We as developers hate hardcoded strings. They're not maintainable, they're not scalable. If you need to change something in your project you literally have to search the whole codebase and replace it. You can do search replace over the whole codebase and they make crazy mess. It's a recipe for bugs. Don't use hardcoded strings. Right now we don't have any other options because we can trigger mutations in two ways. First one, directly accessing the store object and triggering for example actions and mutations you would trigger commit and dispatch from methods from that store object. You still need to pass hardcoded strings there but I definitely don't recommend doing it that way. We have UX helpers, map mutations, map getters, map actions and map state for that. Why is that good? Well imagine massive apps with many many many components and files and massive massive store. If you're accessing that store, that global store which controls your core application directly it's just not clear. You're gonna have thousands and tens of thousands or even more references directly to this dot store object and it will just all be a mess. With map mutations and all the other helpers you literally see oh this component my random component is using this part of the store and it's clear you have it all in one place. You still have to use hardcoded strings right now but we're gonna solve that. Take a look at map mutations. Because our modules are namespaced we need to pass module name as a first argument. That's why we in the first scenario passed user. Second argument is an array of mutations so just one string here set username. Let's solve this. To do so we need to extract the strings. It's pretty pretty simple. You need to do three things. Create a const, export it and then set that const value as a mutation name. That's it. The same thing in organization model creating a const, exporting it so that you can import it in the other files and setting it as a mutation name. That's it for the modules. The other thing we need to add is module object which will just be a list of all of our module names. Then we need to import that object to our index.js file and just use values from that object rather than hardcoded strings for user and organization. Pretty simple right? Let's see how we improved our usage by doing this. If we take a look at our random component now we obviously need to import set user name, set organization name and module object. But right now in map mutations we're not passing hardcoded strings anymore. We're passing a module name and the second argument we're not passing an array anymore rather an object where we map a mutation name to a name we want to use in our component. So right now it's set organization name and set user name. You can set it to any way you want. It's completely up to you. Good! So our store is split into modules right now. We have those mini stores. Their usage is so clear. Not only that we have map mutations and possibly all the other helpers like mega address map actions, we also need to import those methods to use them. So immediately when you open your component at the top of the file you will see, okay, I use set user name here and set organization name here and it's so clear. Oh, this component uses these parts of the store. It's really important when your app scales that you have that clear, clear picture rather than just accessing store object directly. And because of namespace set to true our store is isolated too. We don't have hard-coded strings. Yeah, best thing. But there's still one problem we need to solve. Even though our app is split into modules now, those modules can be pretty, pretty big and we need to somehow solve that and split them even more. To do so, we need to take a look at our current folder structure first. At the top we have root store folder. Then within it we have index.js, modules.js, organization module.js and user module.js. This is pretty cool for small apps, mid-sized apps, but it's not good for massive apps. That's why we need to refactor this structure. This is our desired structure. Store is the same, so that root folder is at root, index.js and modules.js inside, but right now we've added another folder called modules. And within that folder we're going to have multiple folders with the separate modules. So right now we have organization and user. Within organization we have actions, getters, index, mutations and types. And within the user we have the same things, I just didn't want to expand it because it would look bad. Let's take a look now at the details of these files. How can we do that? So the title says splitting the modules. That's basically what we need to do right now. We need to grab certain parts of our modules and just create separate files for them, export default those objects and we're good to go. First we have types.js file. You remember those hardcoded strings. So this types.js, basically it's a list of all consts, actions, mutations and getters. Everything we have and use in this module. It serves as a kind of documentation as well. You can look here. Oh, okay, this module is using these methods. It's pretty reasonable, pretty clear. It's not clotted with any logic, just consts here. So yeah, as I said, a nice sort of a documentation. Then we have mutations. We obviously need to import consts from types and set mutation names to those const values. Obviously you're going to have multiple mutations here. Right now we have only a single one and then you need to export default that object. With actions, currently we don't have any actions. That's why we're exporting default an empty object. That is possible to happen for some new modules. I highly recommend exporting default an empty object rather than not having anything at all here or not having a file at all, just so you can be consistent and then when you add something inside, you already have that boilerplate for it. Everything with actions is the same as with mutations. The same goes on for getters. Right now we're just exporting an empty object, but the process is the same as with mutations and actions. Finally, we have our index.js. That's not that index.js in root store folder. That's index.js within organization folder, within our module. Here we need to import actions, mutations and getters. Then we need to create state object. You might think, oh, we can maybe create a separate file from state and import it too. That's true. You can do that. You don't have to do that. We don't do it because state object doesn't have any logic connected to it. We love that every time we open an index.js file that we can see everything there. It's just what we do. You can create a separate file for it. You don't have to. It's completely up to you. I definitely recommend creating separate files for actions, getters and mutations because there is a lot of logic behind those methods. We trust those logic. That's why we don't want to look at it. We just want to import it and have a clean look of the state. Finally, we need to export default.object by setting, of course, namespace to true, passing state, mutations, actions and getters. The process is the same for all modules. I won't repeat the same thing for user module right now because it's literally the same. What we need to do now is update our root store. To do so, we need to import user module, import organization module and import our module object with all the names. Then we're going to declare global state, global actions, global mutations and global getters. Be careful with them because they are accessible at the global namespace. That's the place where they will be registered. Right now, they're empty, but the process is the same as with the ones which are namespaced. The process for creating them. Then we need to create modules folder. We're going to map user module to username and organization module to organization name. We're getting from the module const. Finally, we need to use create store from Vuex. We need to export default.object with state, actions, mutations, getters, global ones and modules. That's it. We have it now. We have that clean, scalable and flexible architecture of the store for your massive app. Let's take a look at it. At the top, we have index.js file, our root store. That root store has its own global state, actions, mutations and getters. But from the second layer, that root store imports all the different modules you have. Right now, we have only organization and user, but you're going to have much more, trust me. And then all those different kinds of modules from the second layer import their own isolated actions, getters, mutations, state from the third layer. Right now, at Orbital Witness, we don't have any problems with this architecture. These three layers are enough. But if you're a pro player, then you can actually create a fourth layer. So you can split, for example, your mutations into different clusters. You can separate them by concerns and obviously import it to some index file and then import it to the third layer. And that's something for massive, massive apps, I would say. We don't need it right now. We could do it, but we're not doing it right now. If you have something like massive, massive, massive app, then you can create a fifth layer. And this process, you can dig as deep as you want. You can have as many layers as you want. This architecture supports massive apps, the massivest apps you can see. And that's everything I wanted to say here. Thank you all for your attention. It was so nice speaking here. Feel free to drop any questions. If you don't have anything on your mind right now, you can find my information on the conference's website under speakers. You have my email there. We can connect on Twitter. Also, check out my GitHub profile because this code is publicly available there. So you can use it as a boilerplate for your new app. Or if you want to refactor your current store, you can take a look at these practices. You don't need to refactor the whole store at once. So take your time, take days, weeks, months, whatever you need. And yeah, you can do it partially. That's everything from me. Thanks a lot. Vue.js London.


Domagoj Vidovic

Vuex? No, it’s X(state)Vue for UI

Maya Shavin

#vuex