It feels so good having an application along with Vuex. The application is growing, we add more and more logic into Vuex till we realise that some things went horribly wrong… our app getting slower and harder to maintain — we could have though “We have Vuex! Everything is in it! No more need of passing any business logic as a prop. What could have gone wrong? I’ve realised… everything went WRONG!
Let’s back to basis. Vuex was created to manage shared state across application — just like singleton pattern. We add something to one instance and it’s accessible in every page till we don’t remove it from there or do page reload by pressing f5. By considering example having three store modules: Cart, Product List and Authentication only one of it has place to be — otherwise you will always have to have in mind to clean module: visiting Cart, fetching all of needed data in Cart and then going to Product List. Wait, wait… we need to clear data between those pages, Product List has nothing with Cart module, as we do not do anything within it the data will be growing — we all know who works with e-commerce Product List may have enormous numbers of data. You may ask, but what’s wrong within it? Each data stored consuming browser memory, everything is getting slower, loading next pages, resetting all of the data, remembering to clean after your dirty code — what a pain!
Ok, ok! There are some strategies to prevent this behaviour:
Breaking Vuex structure into prime factors
Having state, actions, mutations, getters is an amazing architecture invention. Each of them has his own responsibility, but there is one typical approach which is showing where the problem is — remember aim to the point! Forms! We all are in love with them… they seems to be boring as hell and what do we do in first place? We think about Vuex! Oh, the mutations will solve our reactivity problem, awww — little drops of heaven ❤
As we can see we do not have anything complicate, then why am I complaining? Well we forgot about very important Vue feature and the “architecture pattern”
- component composition
Why do we have to create for each action mutation, when action does not do anything — just calling mutation. Oh and going further we need to call those actions inside components (another extra work = time).
Remember! This whole code is going to be compiled and accessible from dev tools — the code which is not needed, it should not be there.
Composition over copy-paste Vuex state
What is the composition? Using my own words the composition would be dividing silly components which are not related with any business logic from components that should have only context dependencies. Composition may be achieved by using slots. Components are inserted in any predefined place in parent component. Jumping into an upper example we can delete whole module with Vuex state and clean our code a bit.
It is that simple that we do not have to explain anything. We can easily call v-model because object comes from component — not from outside so the warning that is telling us that we cannot mutate anything which does not belong to component.
There is one question which comes to my mind:
- What if the form is used for add/edit?
Simple, instead of keeping e.g. axios request inside store, create render-less component which is going to handle any API call, what’s more! It will give ya nice feedback by returning progress and data inside scoped-slots. The data might be passed as one of the component props and there you can reassign it to the form data. Basing on this approach you can even generate dynamic form component which will generate form with any component you need — it would be pain on ass to create it with using Vuex.
Vuex is powerful tool which may solve your biggest problems, passing data over the components makes things harder to read and maintain, but on other hand you would not have it when you do correct composition — remember keep your layout things clear enough — one component one dependency, do not complicate it too much. As project grows along time, the Vuex in it selfs is starting to show you the limitations / problems. The perfect example for using it is Authentication module, you do not wanna call every time for user, right? I will leave you with one question — ask your self every time you start working on new feature / project.
Do you think your Vuex store is going save your time or consume it more? Less time more money in your pocket!
Hopu you like it! Feel free to leave any feedback!