CODEWITHSUNDEEP
javascriptvue.jsvuexstate-management
Liga
Liga

Reputation: 3439

Why do we need mutations, setters and getter for state management?

I am just now learning about state management in Vue.js and I can't quite understand why does it need to be so complicated and confusing with all these different methods (mutations, getters, setters). Isn't it more simple to change data directly? Doesn't that look cleaner?

What is wrong with just using plain code like this? What am I missing here? Except that I have to define store: window.store in every component. Is it safe for me to do it like this or is it critically necessary for me to use Vuex?

// global app data
window.store = {
    appName: 'Hello World!'
}

export default {
    template: `
        <div @click="changeAppName">Hellow {{ store.AppName }}</div>
    `,

    data()
    {
        return {
            store: window.store
        }
    }

    methods: {
        changeAppName() {
            store.appName = 'Reactive app name!'
        }
    }
};

Upvotes: 5

Views: 1022

Answers (3)

bernie
bernie

Reputation: 10400

First a quote from the Vuex doc:

When Should I Use It?

Although Vuex helps us deal with shared state management, it also comes with the cost of more concepts and boilerplate. It's a trade-off between short term and long term productivity.

If you've never built a large-scale SPA and jump right into Vuex, it may feel verbose and daunting. That's perfectly normal - if your app is simple, you will most likely be fine without Vuex. A simple store pattern may be all you need. But if you are building a medium-to-large-scale SPA, chances are you have run into situations that make you think about how to better handle state outside of your Vue components, and Vuex will be the natural next step for you. There's a good quote from Dan Abramov, the author of Redux:

"Flux libraries are like glasses: you’ll know when you need them."

When and if your components get very big because they have many different states and do lots of different state mutations, it becomes harder and harder to reason about their code and maintain or extend them. This is when decoupling state storage and modification from the component themselves becomes interesting.

Consider also the case where multiple components can trigger the same actions or mutations. In this case, it becomes apparent that the latter should be extracted to a common object/class/file to avoid duplicating the logic. Once you get to that point, you're already getting very close to a Vuex-like structure.

Also, an application that communicates with a backend API will involve asynchronous ajax calls, error handling, etc. If all this is placed in the same file as the component, it will be very long and again hard to read and understand.

Extracting all the mutations to a separate Vuex module makes them easy to test in isolation without having to instantiate the actual Vue components that use them. The Vue components can then be (mostly) purely about display logic and reacting to events.

As you can see, it's all about giving your application a better structure. All those reasons add up in a larger application to make it much easier to maintain.

Finally, Vuex does add nice features like state tracking and rollback with the Vue.js devtools plugin. This allows inspecting the state at any point in the application's execution and helps understanding all the modifications made to it. See below for a screenshot.

In short though, to answer your question: no, Vuex is not critically necessary and it should be used when it makes sense because it can bring more unjustified verbosity in some cases.

Update

Since I wrote this, I have actually scaled back the amount of state I store in VueX. I still use it, but not for all state. I keep state that is not meant to live longer than a given "page" (or route) directly in the "page" parent component and pass it down through properties. Since that state is automatically deleted with the component that owns it, this frees me from dealing with stale entries in the store and reduces total memory usage for long sessions in the app.

Some interesting reads:

Vuex devtools

Upvotes: 5

luhara
luhara

Reputation: 25

If you have experience in Object Oriented Programming this pattern should be familiar to you. So that you can rely on your data in a central way.

  • Getter: E.g. to check if your data is initialized
  • Mutations: E.g. validate data before it's written to the store
  • Actions: to make asynchronous mutations

And of course you can do it the way you mentioned, but that's not a clean style and may not scale.

And here is a plugin called vuex pathify to make all of this a lot easier but it's hard to understand if you don't know how vuex works.

Upvotes: 0

airen
airen

Reputation: 15

Once you have bigger application that will communicate with each other components, states from store, etc. you will be so glad that you did put an effort to create that getters and setters.

If you create a project that is small, simple PWA or you are just messing around, than yes, it can look confusing and not needed. But once that small project became more dependent on components, that are dependent on states from Vuex (consider using Vuex, you don't need it, but you will know when you need it).

Once you do create getters and setters and you will have this pattern in whole application, the code will be clean, easy to read for every programmer that will want to help you maintain the project.

Have fun with Vue.

Upvotes: 0

Related Questions