 |
| Photo by Barth Bailey on Unsplash |
State management
When building Vue applications, it (and other similar frameworks) structure the project to be built over a Component based architecture. So, when you design and develop your components, there will be always a need for those components to talk to each other. Vue provides a way to pass Prop, which helps in sending data from one component to another. But, that too only from Top level component to Lower level component, and not the other way around. Even then, your project can quickly become messed up and difficult to debug, if you drill the props to a way deeper components.
And here comes State management to the rescue.
What state management does is, it stores all component's data at one place, and you make the changes to the data, present over there. It keeps track of the changes made to those data, which will help you in debugging. And the good thing is, as you change the data in the Store, it gets updated to wherever it is been used.
...
Flux libraries are like glasses
Even though, flux libraries like Vuex looks very useful, there is a catch.
Vuex helps us deal with shared state management with the cost of more concepts and boilerplate.
It can become verbose quickly for small projects. Most small projects can be built well and good even without Vuex. But, even then, if you are going to handle huge set of data, it is good to adopt Vuex at an early stage, as it helps your project in scaling faster.
Vue documents clearly mentions that, if we have never built a large scale SPA and directly jump into Vuex, it may feel daunting.
Flux libraries are like glasses: you’ll know when you need them. - Dan Abramov
...
Store pattern to the rescue
Vue documents also suggest in using Vue store pattern for early stage and small scale applications. So, coming back to our question, can Vue store pattern replace your Vuex? Let's find now.
It is obvious that, all data objects present inside Vue components are reactive. Using this concept, we can achieve a poor man's state management to our application.
As you can see in the above example, we have created an object which will actually store all your data that needs to be shared with different level of components. And also note that, the sourceOfTruth object is used inside the data object by declaring as part of its reactive system of sub-components, which needs to be updated when the sourceOfTruth changes.
Good to know: From Vue 3 all data objects inside Vue components are to be defined as an Object returned by a Function. Earlier it shows a simple warning, if we have declared the data as an Object directly. Now it is made mandatory for better code and debugging purpose. So it is good to practice using Object returned by a Function type of data inside Vue Components.
Coming back, since it is shared across the components, the component gets re-rendered whenever the sourceOfTruth object changes, since it is bound with the data of the components. And also, Vue provides a way to manipulate the sourceOfTruth from sub-components, with the access scope of this.$root.sourceOfTruth.
...
Footprints to debug
But, here too, it becomes void for debugging application. One cannot know, which component modified a data. So, it is better to leave a trace of the change. It is simple. Log messages for each change made, in debug mode alone.
So as in this example, components should be never allowed to directly mutate ie., assigning or changing the state, instead of which, we are using setMessageAction and clearMessageAction which logs the change, to help us in debugging and change the data. Log trace will lead us to the function, which actually made the change to the state.
One who is aware of Javascript's core defineProperty usage, could easily create such kind of reactivity system, but it becomes super tedious for large set of data.
And also, in addition to this shared data instance, each component can have it's own private data instance too.
It’s important to note that you should never replace the original state object in your actions - the components and the store need to share reference to the same object in order for mutations to be observed. - Vue docs
...
To conclude, it totally depends upon your project size and project needs. As Dan Abramov, author of Redux clearly said, you will know when you need them. But, make sure that, it never becomes too late. For small scale application and early stage medium scale applications, Vue Store pattern really comes to rescue of the all boiler plate codes and verbose functions to be executed.
So, that's it from me today! Do let me know, what do you feel about Vuex and Vue store pattern and how are you going to implement in your project or how did you implement in your project.
- Balaji SV
Comments
Post a Comment