мне это карты ballon надо там тупо строку из компонента вывести ничего не надо учитывать

Ребяты, привет! Что думаете насчет экшинов, не совершающих мутации (Vuex)? Я просто приложение разбил на уровни таким образом, что всё взаимодействие с api лежит на плечах ТОЛЬКО хранилища, в то время как компоненты могут просто диспатчить экшины в духе "fetchSomething" и реагировать на последующее изменение данных в хранилище. И всё это выглядит довольно логичным, если "fetchSomething" в процессе возни с http еще и вызывает изменение vuex-стейта ответными данными. Но сейчас вырисовываются ситуации, когда не всегда есть необходимость сохранять результат обращения к api в состоянии хранилища (соотв, мутации не нужны). Получаются такие "голые" экшины, работающие не совсем по своему прямому предназначению (см. скрин). Выглядит странно, но импортировать api-модули прямо в компоненты (минуя экшины) очень не хотелось бы, т.к. чревато нарушением разделения ответственности. Что скажете, как бы поступили/поступаете?)

а почему для получения данных не использовать функции геттеры?

что такое botsApi?

если http клиента, то странно,
явно не ожидается, что обращаясь к Vuex произойдет что-то несвязанное с хранилищем

лучше тогда наоборот сделать, пускай Вуекс будет частью какого-то провайдера

botsApi - модуль с функциями, совершающими преднастроенные запросы

ну тогда точно нет, это неожидаемо и это явно нарушение зон ответственности

вот вернули вы данные с экшена, что дальше?
запишите их в поле в компоненте?

Предполагается, что да)0 Эти данные слишком специфичны, чтобы записывать их в глобальное хранилище. Предлагаете, всё таки, импортировать  ( = использовать) нужный api-модуль прямо в компонент, без "проксирования" через экшин?

тогда вы сами же себе противоречите «взаимодействие с api лежит на плечах ТОЛЬКО хранилища»

У вас на плечах хранилища получается лежит логика вызова хттп запросов, а вопрос хранения ответов лежит не на хранилище. В идеале в хранилище лежит все, включая состояния диалогов, окон, роутера и тд, это будет чистый Flux, а наши компоненты будут максимально чисты и лишены своего состояния. На 100% это конечно очень сложно сделать и не всегда оправдано, но тем не менее

Вы можете инжектнуть новый плагин this.$botApi и делать запросы, это в общем то хорошая практика.

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

Если я в vuex запишу объект идентичный тому, что уже там есть? Реактивность сработает, да?

Экземпляр другой

Здравствуйте кто-нибудь использовал vuetify bottom sheet с v-swipe-down-close?

а как именно запишите

по идее нет

вы уже несколько раз спрашивали) лучше воспроизведите проблему в codesandbox и присылайте сюда

state.smth = {key : value}

Я предполагаю что таких обновлений у меня будет большинство

по идее не должно
вотчи не должны отрабатывать на это

Хм, понял вас, благодарю!) В интернетах, просто, всё довольно неоднозначно на тему подходов к стору - вот и озадачился. В таком случае, было бы также интересно узнать ваше мнение насчет:

1. Выходит, "идеальный флакс" стремится к отказу от локальных состояний компонента от слова вообще?)  Как, в таком случае, поступать с небольшими данными, которые узко необходимы только одному компоненту в приложении?

2. Я во Vue недавно, на днях познакомился с популярным в комьюнити срачем: что думаете насчет mapState и mapMutations? Уместны ли прямые мутации из компонентов, на ваш взгляд? Почитал https://github.com/vuejs/vuex/issues/587 , но к окончательному выводу так и не пришел

1 От небольших кусков сложно избавиться, это может быть например пользовательский ввод, странновато будет на каждый новый символ сразу вызывать мутацию

Эта отождествленность компонента от состояния должна помочь лучше понимать сам компонент, давать возможность эффективно его тестировать и представлять его в виде черной коробки, в которую что-то вышло и из которой что-то вышло. Размер этой коробки определяете вы сами. Вы ведь не будете тестировать на уровне «ввел символ а, в инпуте появилось а» Четкой грани тут нет наверно, по крайней мере я о ней не знаю, все бизнес данные я храню в хранилище, существенные интерфейсные переменные тоже, логику ввода данных оставляю внутри своего черного ящика

2 Думаю, что иногда это излише, в простых вопросах и аппках вполне можно сделать это «упрощение», понимая это Если это не противоречит чему-то еще, например автогенерации документации на основе всех экшенов или еще чему-то или нарушению цельного стиля большого проекта

Правило должно иметь под собой что-то, какую-то ценность.

Если есть обоснование - то да. Например вы делаете проект в команде и отдаете часть работы над компонентами людям, которым не нужно думать о том будет ли действие синхронно или асинхронно, тогда - да, это оправдано, это снимает ряд вопросов с некой команды.

А так, у меня например есть мутация «установить title страницы», я не писал поверх нее экшен

Супер, большое спасибо за развернутый ответ!)

Не за что) я тут всем советую прочитать идеи Аристотеля о формальной логике. Мне кажется все эти наши вопросы это прямые наследники его рассуждений ))))