Зачем во Vue запросы выносят в services?

Question

[Дима Паутов]

Зачем многие во vue js запросы выносят в services, а после вызывают запрос в vuex actions, когда можно просто писать его в actions?
Есть у нас vue.js, есть у нас vuex. Стал замечать, что многие выносят запросы в директорию services.

Есть например сервис User:

import api from '../api' // Там axios

class UserService {
  async getById (id) {
    return await api.get('/user/', {
      params: {
        id
      }
    })
  }

  // Другие запросы с работой пользователя
}

export default UserService

Есть у нас vuex и его actions:

import UserService from '../services/UserService'

//...
export const actions = {
  async getUserById ({ commit }, id) {
    const { data } = await UserService.getById(id)

    commit('setUser', data)
  },
}
//...

Вопрос, зачем всё это? Есть у меня есть actions, которые работать с запросами
Почему не написать запросы в нём?
Для чего эта прослойка которая по сути своей ничего не делает? Потому как все примеры, что я встречал в жизни, это просто функции запросы.

P.S. Код придумал на ходу, так что прошу в случае чего, не обращать на синтаксис. Я лишь хотел передать суть своего вопроса этими примерами

Answer 1

[Alex]

1. Для упрощения кода. Скажем, чтобы не писать каждый раз всю конструкцию аля

   axios.get(ENDPOINT + '/api/' + API_METHOD, {
     params: {
       id
     }
   })
   .catch
   ...

   
   Делается обёртка, условная функция getUser(id). В неё выносится вся логика по работе с запросом, определение маршрутов АПИ, обработка ошибки и так далее. Наружу торчит только одна функция и параметр.
   
2. При работе с TS это проще типизировать. Намного легче описать типы принимаемых параметров и возвращаемый тип для нескольких функций, чем описывать универсальную конструкцию для доступа к любым методам апи.
   
3. Ну и наконец: сервис можно вызывать прямо в компонентах. Вызывать методы АПи не обязательно внутри Vuex. Доже чаще это должно выполняться внутри отдельных компонентов, каждый из которых работает с одним-двумя апи, а не со всем набором.
   

Comments

[Дима Паутов]

Хороший ответ, благодарю. Вроде подобные мысли крутились в голове, но структурировать и понять их было сложно)))
Теперь вопрос стал более понятен

[Roman K]

Дима Турков, изучи SOLID, чтобы стало ещё более понятно

[alex4answ]

Alex , зачем axios сейчас используют?
fetch же вполне себе норм

[Alex]

alex4answ, Я для себя выделяю две причины:

1. Можно отслеживать процесс выполнения запроса, если это нужно https://github.com/axios/axios/issues/629#issuecom...
   
2. Чуть более удобный интерфейс.
   

Answer 2

[Mikhail Osher]

Бизнес-логика не должна находиться в компонентах. И это даже не специфичный кейс во VueJS, а вообще, в целом. Так же делают в и Angular, и React. Компонент не должен знать о том, как конкретно грузятся данные.

Answer 3

[Дмитрий]

Ко всему уже перечисленному добавлю - это очень удобно для тестирования. Вы можете mock'нуть модули/методы и не дергать при тестировании реальный API.

Answer 4

[Alexey Levicky]

Я не работал с Vue.js, но очень похоже на реализацию Redux - разделение состояния приложения, представления приложения и запросов. Что бы напрямую не менять стейт приложения создаются дополнительные прослойки. Actions в данном случае - это не только запрос, но и изменение стейта, а одни и те же запросы в теории могут использоваться в разных экшенах, по этому их и разделяют.

Comments

[Дима Паутов]

а одни и те же запросы в теории могут использоваться в разных экшенах, по этому их и разделяют.

во vue обычно нет. Т.к. создаётся отдельный store user.js где описывают работу с юзером, ну а после вызывай где хочешь и когда хочешь.

Что бы напрямую не менять стейт приложения создаются дополнительные прослойки.

Ну вот если только. Хотя я на своей практике мало встречал подобные моменты. Просто не приходит в голову, где мне это может понадобится. Ну, соглашусь, можно поставить + за разделение