Why does everyone recommend using Vuex as an API layer (via axios)?

Question

Vue.js

Have a nice day, everyone.

In all lessons on Vue, they make API requests inside the actions of the Vuex store, commit the data in the state, and they are already taken in the component.

I just can’t understand what is the point of such a layer and why no one accesses the API bypassing Vuex.

When using this approach recommended in all lessons, no one explains what to do with this data when I am adding / updating new data.

Let's say I have a blog. The blog has: a list of articles (with pagination), "latest added", "most popular" and something else. There is also a publishing page.
It turns out that I need to produce states, getters, setters and mutations for each type of list, for the publication page too.

And what to do with this data in all states when I edited some publication?
What should I do when I leave the blog altogether for another section of the site? Clean states or leave hanging in memory?

The questions above are rather rhetorical. :) And the actual one - further.

Is there really any point in using Vuex as a layer for working with an external API (both for reading and writing), or is using it in this way guides / lessons / tutorials redundant, and should be used for a more general purpose, such as storing authorization state ?

By the way, nowhere in the official documentation did I find recommendations to use it as an API layer, but in the lessons - only this approach is used (both Russian and English)

Answer 1

Vuex is used as storage. Components as its consumers.
This allows you to separate the application into layers and not mix logic and display and simplifies testing.
And a typical example.
You have 3 components at level 1 posts, a paginator and a filter,
with the paginator and filter being duplicated. That is, instead of a simple display, you need both the logic and notifications of the top-level control. Nightmare!

Answer 2

When should you use Vuex?

Flux libraries are like glasses: you will know exactly when you need them.

If you don't understand why you need vuex, don't use it yet)

Answer 3

I don’t know why they do this, but I’ll assume that they have a relatively identical way of obtaining data, regardless of the components. If data about an authorized user or something else is requested from the server that does not imply changes depending on the request parameters, then it is probably logical to do this through the actions of the store. But lists that imply filtering and pagination in general only create problems. For example, a component takes a list from a store and renders it. Then I needed to display the same entities in the popup, but with a different filtering - that's all - the list of the first component was overwritten by the second. So one has to be very careful with this practice.
At our work, we initially went along the path of data in the store, then they cut it out.
Another disadvantage is that the data from the server in the store is reactive, although this is usually not required for data received from the server and affects performance negatively. In the case of using the composition api, it is better to store such data in a shallowRef entity and update it entirely when new ones are received.