Да прямые вызовы fetch и axois - это плохо и да нужна обертка (обычно это пишут не сразу или вообще не пишут). Можете писать свой Request Manager (я показал как это выглядит у меня и это не так страшно) и пользуйтесь им где угодно (в рамках разумного). Мы используем в store, на страницах (компонент верхнего уровня), в модулях Vue.Observable, но не в компонентах (они просто слой View, которые могут сказать что то родителю - через emit)
Это не значит, что нужно полностью отказаться от store (я в нем храню какие то словари, данные пользователя и др. глобальные вещи), нужно сделать его проще и убрать оттуда не нужное.
Увы золотой пилюли у меня нет и каждый должен найти свой баланс.
Посыл статьи все таки, что хранилища перегружены и их надо разгружать. Composition API или Vuex - дело вкуса. В целом интересна больше последняя статья. Она описывает решение части проблем через Composition API. Но проблемы Fetch layer и Serialization layer остаются в компоненте/хранилище или рядом с ним. Для генерации api sdk можно использовать swagge или писать свой Request Manager (они должны решать проблемы получения и сериализации данных) - это один из посылов данной статьи + они могут кешировать. Дальнейшее отличие в том, что в примере по ссылке - работа идет с одним списком пользователей (page: /users), а я привожу пример store который подойдет к примеру для списка статей пользователя (page: /users/{userId}/article) и показываю на сколько он получается сложнее и как можно это упростить (Пример Vue Store с использованием обертки). Другой из посылов - это то, что не обязательно использовать store, иногда можно сделать запрос из компонента страницы и если есть пагинация, поиск, фильтрация, сортировка и тп. и это будет гораздо чище (упрощенный пример под заголовком Моя реальность).
Ошибок не было (нужно импортировать Vue). Без Vue.set свойство не будет реактивным. Вторая строчка избыточна, наверно корректней было бы сделать через Object.assign. И скорее всего вы правы и стоило вызвать commit и делать это там. Почему было сделано примерно так, я сейчас не скажу (проект 2019-2020 года).
Спасибо)
Да прямые вызовы fetch и axois - это плохо и да нужна обертка (обычно это пишут не сразу или вообще не пишут). Можете писать свой Request Manager (я показал как это выглядит у меня и это не так страшно) и пользуйтесь им где угодно (в рамках разумного). Мы используем в store, на страницах (компонент верхнего уровня), в модулях Vue.Observable, но не в компонентах (они просто слой View, которые могут сказать что то родителю - через emit)
Увы золотой пилюли у меня нет и каждый должен найти свой баланс.
Посыл статьи все таки, что хранилища перегружены и их надо разгружать. Composition API или Vuex - дело вкуса. В целом интересна больше последняя статья. Она описывает решение части проблем через Composition API. Но проблемы Fetch layer и Serialization layer остаются в компоненте/хранилище или рядом с ним. Для генерации api sdk можно использовать swagge или писать свой Request Manager (они должны решать проблемы получения и сериализации данных) - это один из посылов данной статьи + они могут кешировать. Дальнейшее отличие в том, что в примере по ссылке - работа идет с одним списком пользователей (page: /users), а я привожу пример store который подойдет к примеру для списка статей пользователя (page: /users/{userId}/article) и показываю на сколько он получается сложнее и как можно это упростить (Пример Vue Store с использованием обертки). Другой из посылов - это то, что не обязательно использовать store, иногда можно сделать запрос из компонента страницы и если есть пагинация, поиск, фильтрация, сортировка и тп. и это будет гораздо чище (упрощенный пример под заголовком Моя реальность).
Ошибок не было (нужно импортировать Vue). Без Vue.set свойство не будет реактивным. Вторая строчка избыточна, наверно корректней было бы сделать через Object.assign. И скорее всего вы правы и стоило вызвать commit и делать это там. Почему было сделано примерно так, я сейчас не скажу (проект 2019-2020 года).