Both can be correct depending on your use case. The application I’m currently building uses both.
When to use B: Go Directly to the server
Use B if the data is very important to save. In this case you may want to go directly to the server and serve up the response to verify it was committed to the DB. We use this process for Admin type changes. Note that you can also update Vuex after the server response and still use Vuex to serve up your data.
When to use A: Go Through Vuex
Use A if you require faster experience, since there’s no waiting for the server. You must be okay with optimistically displaying changes before actually saving. The other benefit is you can sync Vuex to localStorage. We use this for user preferences that are used to customize views. Its a poor experience to slow down the page just to wait on fetching those.
How to use A: Go through Vuex
There’s a couple ways to do this. Here’s one pattern:
- Dispatch Vuex Action 1 from component
- Commit Vuex Mutation from Action that updates state – this is an optimistic update as you’re assuming it’ll go through
- Dispatch another Vuex Action 2 from Action 1 – This assumes you’ll reuse this Action in multiple Actions, otherwise it can all go in Action 1
- Action 2 sends data to server
- Upon promise return, Action 2 commits mutation to update Vuex state
- Mutation needs to handle any discrepancies (or errors)
Count the cost of Vuex
Like your comment shows, its good to count the cost if you need to use Vuex at all because it does add a lot of overhead and complexity. The ideal is to write your components in such a way as to contain all interactions with one type of data (such as ‘Lists’) so you do not have to share state through Vuex.