It's a trade-off between short term and long term productivity. Vuex helps us deal with shared state management with the cost of more concepts and boilerplate. If you want to learn Vuex in an interactive way you can check out this Vuex course on Scrimba, which gives you a mix of screencast and code playground that you can pause and play around with anytime. Unlike the other patterns, Vuex is also a library implementation tailored specifically for Vue.js to take advantage of its granular reactivity system for efficient updates. This is the basic idea behind Vuex, inspired by Flux, Redux and The Elm Architecture. So why don't we extract the shared state out of the components, and manage it in a global singleton? With this, our component tree becomes a big 'view', and any component can access the state or trigger actions, no matter where they are in the tree!īy defining and separating the concepts involved in state management and enforcing rules that maintain independence between views and states, we give our code more structure and maintainability. Both of these patterns are brittle and quickly lead to unmaintainable code. For problem two, we often find ourselves resorting to solutions such as reaching for direct parent/child instance references or trying to mutate and synchronize multiple copies of the state via events. Actions from different views may need to mutate the same piece of state.įor problem one, passing props can be tedious for deeply nested components, and simply doesn't work for sibling components.Multiple views may depend on the same piece of state.However, the simplicity quickly breaks down when we have multiple components that share a common state: This is a simple representation of the concept of 'one-way data flow': The actions, the possible ways the state could change in reaction to user inputs from the view.The view, a declarative mapping of the state.The state, the source of truth that drives our app.It is a self-contained app with the following parts:

Vuex64