Комментарии 12
Посмотрите в сторону Vue3 и Composition API, там все проще гораздо реализуется без Vuex и тд. Пример тут https://vueschool.io/articles/vuejs-tutorials/state-management-with-composition-api/ или https://habr.com/ru/post/525038/ или альтернативный проект Pinia - https://github.com/posva/pinia или https://javascript.plainenglish.io/building-a-data-layer-with-vue-and-composition-api-547cc9761b4c . Реализаций уже много, не нужно ничего выдумывать.
Посыл статьи все таки, что хранилища перегружены и их надо разгружать. 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.set(state.newsItemObject, key, getNew());
Vue.set(state.newsItemObject[key], 'loadStatus', 'LOADING');
Вот такие штуки в экшенах разве не вызывают ошибку?
Ошибок не было (нужно импортировать Vue). Без Vue.set свойство не будет реактивным. Вторая строчка избыточна, наверно корректней было бы сделать через Object.assign. И скорее всего вы правы и стоило вызвать commit и делать это там. Почему было сделано примерно так, я сейчас не скажу (проект 2019-2020 года).
Стор изначально был нужен только Фейсбуку и его прямым конкурентам! Как и реакт...
Миллион леммингов подхватывает подобные идеи по трем причинам:
Авторитет : это же сам фейсбук, нихумать! Ходи как Фейсбук, крякай как Фейсбук и будут тебе миллионы!
Золотая пуля : лемминги падки на все, что "однозначно" пусть и не очень просто. Мол смотри, оказывается, стор спасает от всего этого головняка с вебкомпонентами и их состояниями. На самом деле стор "решает" примерно так же как шлагбаум - проблему нехватки парковочных мест.
Когда два первых крючка заглочены - вырастает третий уже у вас в пасти: "так делают все!" . Попробуйте заикнуться о том что стор да и вебкомпоненты сами по себе переоценены и услышите обвинение в слепоте! " Ты же клоун который игнорит свершившуюся реальность"
Но в айти, как в астрономии, реальность это не то что вы видите а то что должны предугадать, а видите вы всегда прошлое. Это обусловлено космической скоростью прогресса айти и животной инертностью 99% человеков.
Автор скорее прав чем нет и вдохновляет!
Я правильно понимаю, что вы недовольны как прямыми вызовами fetch и axios, так и их обвёртками?
И ваше решение это заменить «неправильные» обертки других разработчиков своей «правильной» обвёрткой?
Ну и вас не устраивает то, что взаимодействие с api идёт через store. А что если я вам скажу, что я могу взять ваш Request Manager и использовать внутри store?
Я без какого либо негатива задаю все эти вопросы. Пример, который вы привели в качестве плохого кода действительно плох. Но это не значит, ваше утверждение верно для всех случаев. Если нам нужно подгрузить глобальную настройку и обновить стейт всего приложения - ваше решение потребует больше костылей, чем принесёт пользы. А если речь идёт о единообразии и абстракциях, то компонентам вообще не стоит знать, что они идут в какой-то REST API. Одно цепляется за другое, ну вы поняли…
Да прямые вызовы fetch и axois - это плохо и да нужна обертка (обычно это пишут не сразу или вообще не пишут). Можете писать свой Request Manager (я показал как это выглядит у меня и это не так страшно) и пользуйтесь им где угодно (в рамках разумного). Мы используем в store, на страницах (компонент верхнего уровня), в модулях Vue.Observable, но не в компонентах (они просто слой View, которые могут сказать что то родителю - через emit)
Это не значит, что нужно полностью отказаться от store (я в нем храню какие то словари, данные пользователя и др. глобальные вещи), нужно сделать его проще и убрать оттуда не нужное.
Увы золотой пилюли у меня нет и каждый должен найти свой баланс.
Вот и мне всякие Store не нравится, он нужный, полезный, но когда начинаешь делать всё по правилам, то попадаешь в ад. Сейчас пробую использовать vuemc, очень удобно, а стор больше как глобальное хранилище для некоторых vuemc моделей.
Мне тоже кажется, что не нужно всё подряд тянуть в стор. Но в данном случае моё мнение прямо противополжно мнению автора. Я считаю, что данные, которые мы берём с бэкенда - должны быть в сторе. И логика получения этих данных должна быть отделена от компонентов, отвечающих за представление этих данных. Я уже многократно сталкивался с ситуацией, когда данные предназначенные для одного компонента внезапно становятся нужны где-то в другом компоненте. Если данные в сторе - никаких проблем. Если данные грузятся прямо из компонента - нужно прикручивать кэш или переносить всё в стор. Что действительно не нужно тянуть в стор - так это внутреннее состояние компонентов, состояние открытия поповера или текущий слайд в слайдере и т.п.
данные предназначенные для одного компонента внезапно становятся нужны где-то в другом компоненте
У меня такие ситуации возникают очень редко. Опять таки это все связано со спецификой проектов и возможно в вашем случае хорошо именно так (без примера сказать что то очень тяжело).
Повторюсь, мои компоненты (за исключением родительского page) это слой View (там нет логики получения данных - [props + emit] ). Таким образом разрабатывают очень мало людей (хотя это позволяет изолировано разрабатывать/тестировать компоненты). Соответственно поменять слой получения данных для меня это не проблема (на странице вы все равно пишете обращение в store или в другое место). Так же сам Request Manager имеет возможность кешировать (к примеру для главной страницы мне не нужен store).
И да есть исключения - есть компоненты для переключения языка, валюты, темы и тд. Данные компоненты - я называю виджетами и они имеют право доступа в глобальный store на прямую где бы они не находились. Но нужно понимать, что таких компонентов обычно не больше 5 и в этом нет чего то очень плохого...
Наверно дополню примером из реальной жизни. Сделали редизайн главной страницы, а на бек забили. В итоге слалось 1(осн.)+7(доп.) запросов (на старую api). Проект отдали другой команде и они перенесли все в store. В итоге слой данных размазался на 4 части, вместо 1, а кеширование просто уничтожено. Часть данных храниться на странице, часть данных в сторе и третья часть в Менеджере запросов и вишенка на торте axios запрос на странице. Благо они не убили менеджер запросов который делал грязную работу по отправке 8 запросов и не трогали сами компоненты.
Я не кидаю камень в чей то огород, это просто пример бездумного программирования и обида за тот проект. В целом store не при чем, проблема только в том, как им пользуются люди. Store может помочь уменьшить количество запросов на бек (как слой оптимизации), но этот слой становиться сложным (обычно - логика размазывается, а количество запросов не уменьшается - из за банальных ошибок, к примеру отсутствия проверок наличия данных). Как мне кажется, для многих проектов эта экономия на спичках вообще не нужна, а там где надо, достаточно простого кеша, так как поддержка store получается дорогой.
Все это лирика (мой опыт) и каждый сам решает что ему необходимо для счастья.
Vue/React Store и JS Request Manager