[parr0t]

Interesting timing with coming across this article for me. I have started developing re-designing our site frontend to use Vue with Vuex and the point this author makes about where to put the API logic also made me scratch my head a bit. Sometimes I just need to make a simple API call that does not alter the application state and just needs to grab some information and render said information in 1 component. Technically, in the component, I can just call Axios and get the data then and there, but then I have other components such as the Login that does need to set some Vuex state and therefore that's abstracted away further in the actions/API class as all documentation seems to suggest that's what you should do. I suppose I am just finding it a bit of a challenge to keep things a) consistent and b) not overly abstracted for the task at hand.

[mmcnl]

I think the answer is that there is no right or wrong answer. Something that has worked well for me was to put my API calls in a seperate module and call this module whenever I need it (either in Vuex or a Vue component). Very simple.

[petepete]

It's not perfect, but I think Vuex Pathify can help keep Vuex organised and somewhat sane.

https://davestewart.github.io/vuex-pathify/

[davestewart]

Is there anything in particular you found sub-optimal?

[RussianCow]

I think the most important thing is to be consistent, instead of having a mix of API logic that originates from components and from the store. And since there are certain types of higher-level logic that are very difficult to house inside components, I have found that having your store be the origin for _all_ API-related logic is the best way to go, even if it seems overkill for simple things. It's better to be globally consistent than to try to have the simplest solution for every individual case.

(Disclaimer: I use React/Redux and not Vue/Vuex, but I think the above applies equally to both.)

[parr0t]

This is essentially my chain of thought and what I have done. Even if it is a simple request that is confined to a single component when a developer looks at the codebase they can know that all API calls are called from Vuex modules and not modules _and_ components.

That then leads me to my next question though, if I am using Vuex to abstract the API calls is it bad practice to use Vuex actions for API calls that don't need to be saved into the store?

[RussianCow]

I don't think it's bad at all to have an action trigger an API call that doesn't save anything to the store. However, as @mmcnl said in response to your original comment, you probably want to abstract the actual API-related code into its own module, so that you don't implement the API calls in the actions; then your actions become thin functions that simply call that code with the necessary parameters.

[noir_lord]

I just put those Api calls in a module in the same dir as the component usually.

Then api.fetchFoo(bar).then() mostly does it.

Benefit is separation of API from component.

[RussianCow]

This doesn't actually solve the dilemma of where to put the logic—all you've done is moved the API code into its own object, but your component is still the one controlling the higher-level flow in this case.