Vuex Explained Visually by Adam Jahr

[Music] my name is Adam jar I am with you mastery and this morning I want to invite you all on an adventure who wants to go on an adventure this morning okay most of you cool except maybe the people who stayed up till like 2:00 a.m. maybe not ready so we are going on an adventure deep into space to a planet called beautopia yes not quite utopia but close so we are going on a quest for some hidden knowledge we hear that there is an ancient temple that contains some information that we are questing for so we're gonna head towards that and heck why not go inside inside we find the view Oracle who can who we can ask questions to and she'll provide answers to us so we're gonna open up a portal this morning and learn about the wonderful world of UX so when we're talking about view X we're really talking about state management so what does that even mean well what's basically as your component tree grows in your application the complexity of the state that your components are managing and communicating amongst themselves that grows as well so state management increasingly becomes more of an issue to solve so Facebook discover this the hard way the result of that was the flux based design pattern and that's what UX is designed after all so what redux is designed after so if ux is a full state management pattern and library and it helps us manage the state of our components so without it each individual component within our app might be having its own state so when I say state that might be something like a boolean or a collection of data that's a blog posts or to-do items or notifications so if say this child needs to communicate something about its state to its distant relative across the component tree the non view X kind of traditional way you might think of to do that would be to send that up via events and down via profs but that can get quite messy it's not very scalable there's a lot of ways that can go wrong and be just increasingly more and more of a headache so wouldn't it be nice instead of all of these little you know individual states if we could collapse them aggregate them into one central state where in other words one single source of truth so this is what UX provides for us and it allows all of the different components in our app to directly access that state versus try to manage the state amongst themselves and just like the data in your view components the state is reactive so what that means is if this little child were to update state and that distant cousin were to be listening for changes on that state then it could receive it reactively when it changed so we'll look at what that actually looks like in code in just a bit but just having one centralized global store for your state doesn't solve all the problems of state management because if different components are kind of updating state in different ways from different locations things can become a bit unpredictable and untraceable so we need ways to kind of document and keep track of how state changes are being made to our UX store so fortunately UX with the whole store which is the pattern for state management and if you know anything about view components it's gonna look pretty similar to the view instance so if we were to create a new view instance we'd it would look like this and with a new store it'd look like that so a component it's gonna have its data the UX store is gonna have its State both of which are reactive and then the components gonna have its methods which of course can do many things one of which it can update the data and the actions can update the state a component might have a computed property which can be basically reactively computing values and and changing based on those dependencies that's similar to excuse me a getter and getters allow us to this like take state process maybe filter it in a way and return that and a computed processed version of our state so the difference here with view X is the UX has mutations so mutations are what commit and track state changes so I know that I just said that the actions allow us to change and update the state and that's because they work together with mutations to do so so I know when I was learning about it this was a bit confusing for me but you can imagine actions a bit like rappers that wrap mutations a single mutation or multiple and it can combine that with some business logic so you can run an action that commits multiple mutations to your state and the good thing about the view dev tools is that it allows for time travel debugging so we can essentially rewind in time and see what the different state was at the time that those state changes were made based on those mutations so let's look let's look at an example the UX store so here in the state we have a loading status and a empty - duze array and then we are going to add a couple of mutations so we have a set loading status it takes the state of the loading status and sets it equal to whatever status was passed into it and similar to the two that is the set to dues where it takes the state of our - duze sets it equal to whatever to do is we pass into it and here's our action of course more code so we're gonna go through it line by line so this context object is essentially allows it gives us access to all the properties on the view X store so that we can do things like commit notations and get access to the state so we're passing in the context object and then doing a number of things so we're committing the loading status setting it to loading we're then going to make an API call when that response gets back we can commit again the set loading status setting it back to not loading and then since we now have that response we can commit these set to do's and set our state love to do is equal to what we got back from that API call and I mentioned getters earlier so if we wanted to get this state now we could write out a getter that looks a bit like this we'd call it done to do is I could take in the state and then return a filtered version of that state let's say we only wanted the ones that were labeled done yep so grab just those too cool so happy mastery we were to spend a lot of time on our slides and animations we're not comedians like Chris for it so we have to do really pretty slides so this will hopefully visualize it even better so taking that same example we're gonna look at it in motion here so we're going to dispatch the fetch to dues action which contain those mutations and that action is going to run all the logic we just looked at so it's gonna first commit the set loading status which updates our state to loading which might display loading indicator in the component we're gonna fetch our data when we get it back then if you can commit the next mutation setting the loading status back to not loading and then finally we'll commit the final set to dues mutations since we have that response back update the state with what we got and if again we wanted to just get the ones that were labeled done we could use a getter for that so let's see that in action we would get just the ones that we needed if we're using time-traveling debugging with a view dev tools we can see a record of a time step time-stamped record of all those mutations and could see the state at that given time so that's kind of the high level of how view X at least currently works do it in view too so let's look at how you actually use it to access State a little more practically first I want to show you kind of if you were to say ahead use the view CLI and added UX you'd find this storage is file which would look like this and in your main j/s you'd find that it was basically inserted for you in your root view instance cool so simple example if in our store we had some that's a user state how would we get that and display that in our component so in our template we could say dollar signs store which gives us access to the store and then say state to go into this state in the store and then user and name which as I'm sure you can imagine would display this in the template but we often don't just want to be accessing our state from the template of our components so we it's a common practice to use computer properties to do this so how would we refactor this to do so so we could create a user computed property which would return now in this case this dot dollar sign store dot they'd dot user in our template we would just now say user dot name if you want to display that name and now we can use user throughout the component and because this is a computed property its value is cached until the state changes also view X comes with helpers which are a way to kind of clean up your code and make it a little more readable and take up less lines so let's look at using a view X helper in this case called map state so to refactor this we could simply say map state passing an object where the user on I guess let's see my right is the state that we're mapping to and then we're essentially there's a function that's returning that state we could also streamline this a bit cleaning it up to look like this which means the same thing we just looked at if we had multiple pieces of state in our view acts that our component we're mapping to we could also pass in an array of just a single string which would simultaneously be mean the piece of state so like if our state had user that means user and it's also the name of the kind of local state that we're calling that which we're mapping to so user in this case means our view X state and the local state that is mapped to hopefully that make sense as you probably noticed that maps take took up the whole computed space so what if you needed to add a additional kind of local computer property in addition to what you were mapping to in view X the solution there is pretty simple you would just use the object spread operator so dot dot dot is what that looks like and then you could add your local computed property cool so touchdown Gators a bit before but right now I want to show you how we can use dynamic Gators so in this case for example if we wanted to get a to do by its specific ID we could do that in this way so there's a bunch of arrows so what's happening here so it's basically a function that's taking in the state which is returning a function that's taking in the ID which is returning the filtered state that is only where it's found only the two dues by that ID so in the component we could use a computer property call it get to do a by ID and return this dot store dot getters dot get to do by ID and then in the template do that to get that very specific a piece of our state dynamically just like we looked at map state there's also map getters so we could clean up the code a bit using that importing it into the component and then that's as simple as that would look and you could add as many as you would need for that given component within that array all right so we looked at a couple different ways to get an access the state so how do we actually mutate it what does that look like so like I said before mutations can update or mutate the view X state so let's say we had a simple state of just one property which had account value and we wanted to update that so the in our mutations we could write a increment count mutation which takes our state and updates the count by one so from the so-so vernacular by the way so we commit mutations we dispatch actions we'll get to that in just a minute so how do we actually commit the mutation from the component so in this case we would write a method we call it increment count and say this dot dollar sign store dot commit and pass in the string name of the mutation to run and then we could trigger that say on a button click so when a user clicks a button it's going to trigger our method which is then going to run our mutation which then kind of clicks forward our state in time incrementing it by one but that was super simple so let's look at something where we have something a little more dynamic let's say we have now a input so we want to update the state of our count by a number that the user enters in so we will add to our data and we're going to pass in that increment by value as a payload which then our mutation can receive and increment our state by that new dynamic payload so now since we are V modeled to our increment by data value when a user enters that value increment by is going to reflect that so when they hit the button we're gonna run our method which commits our mutation passing along the payload and that will update our state by whatever they entered in so and then this is a kind of screencast of what the dev tools might look like in this case so as you can see there's a record being collected of each mutation that's happening with those timestamps so you can really have good insight into what change your state when and what was the state at that given change also this is quite old version of the few dev tools they're actually much better now so uh thanks gem right you've worked on those yeah thanks again all right so now we're going to move on to actions which again are they work in harmony with mutations so let's look at how they do that so mutations are synchronous so meaning the order in which they are written are the order in which they're run whereas actions allow us to do some more asynchronous behavior so kind of running things out of order if necessary and like I mentioned before actions can wrap business logic around mutation so what we looked at earlier was one single action that set a loading status made an API call when it got the response it reset the loading status and then committed that final mutation setting our state so two mutations ends the business logic all wrapped within an action so to make this a little more tangible Chris Fritz shared this metaphor with me a while back that I put into some graphic so the difference between actions mutations can kind of be thought about where if you were to ask your friend to pick up some bread for you that picking up of the bread and actually having it in your possession is more likely mutation the state of bread is true you had it whereas the action is more like please pick up bread so if possible go and fetch the bread and then this will you have it you that then it's true but actions in view apps don't always commit their mutations because things can go wrong or you know there might be some conditional logic that's running an API call might not how it is supposed to or in this example you know the car might break down there out of bread etc I'm just plugging Chris RIS constantly he he yes that's true patting each other's backs okay so he recommends and I agree that we ought to always put mutations within actions so even if you only have a single mutation wrapping it within the action allows you to centrally to future-proof your app because even though you might not need right now that business logic around it as your app scales if you do end up needing to it's gonna be a lot less refactoring if you already have it wrapped within that action so it increases scalability and my current knowledge is that in few three mutations are going away so if it's so my thought process is if we think about actions being that which update the state even through these mutations that they're containing once those mutations go away it's still those actions that are doing it they're not these loan mutations that are kind of not wrapped in actions so yeah mutations within actions is a best practice that is highly recommended so let's see actions in action we'll look at the example we were looking at earlier where we had that state of count you have the increment count mutation which just you know updates that count but with this action now we could say the right update count which again takes in that context object giving us access to both the state and the ability to commit mutations and we could pass a the payload initially into the action which passes it to the mutation and then in our template and then in our temple cool then they're our template we instead of committing the mutation again we're dispatching the update count action passing it that payload so an excerpt but again allows us to do some business logic for you know this kind of contrived example if we have a user we're gonna commit that mutation and again increases scalability with that with that action so so far we just looked at view acts that only had that singular kind of root store file and inside of which are state mutations actions and getters all lived and that's fine for a smaller app but out imagine if you're using view X you intend for your app to get larger so there are ways to avoid it getting messy and this one single large store file there's ways to modularize your view X code so you can think of it maybe you have a user module maybe you have a to do's module which each have their own state actions etc and those essentially are branches that break off from the root store within your view X and you can kind of fractal this and like even you could branch the the user state you smaller and smaller to get more and more modular and there's ways to communicate efficiently amongst your modules cool so that basically brings me to the end of this talk it was kind of a preview of several lessons from our complete mastering view X course on the mastery so if you are interested in implementing state management with UX in your view app this is a great place to get started doing so and I also wanted to make you aware we our sponsor booth outside so if you want any cheat sheets we have the view 3 composition API cheat sheet so we worked that with the core team haven't even took a look at it so it's got the most up-to-date view 3 composition API syntax so that you can start to familiarize yourself with that and kind of get ahead of the curve and get your head around what those new options are for you to write these view 3 components we also have a view 3 essentials course that my colleague Greg is nearly completed up on view mastery after that we'll be doing a view 3 reactivity course so we're already producing view 3 content so if it's something that you kind of want to get ahead of want to be one of the first people on your team to really understand the composition API and start being able to use it where we offer that ability to start learning we also have stickers if you like to put stickers on your laptop which I don't but there's plenty of stickers if you want any so yep that's my time thank you so much [Applause]

Channel: VueConf Toronto

Views: 16,855

Keywords: vue, vue.js, vue 3, vuex, vue store, vueconf, vueconf to, vue toronto, js, javascript

Id: wbp_ro-eWwQ

Length: 26min 32sec (1592 seconds)

Published: Mon Feb 10 2020