Во vuex сторах есть экшены и мутации. Они бы оба про изменение данных. В пятницу до меня дошло что экшены это про бизнес логику, мутации - чисто про изменения состояния.
Если сравнивать с mobx, например, то в нем нет этого логического разделения. В mobx есть только “экшены которые могут мутировать состояние”. Поэтому у меня, работая с mobx, чешутся руки создать слой бизнеслогики вместо того чтобы слать запросы напряму из компонент.
Возникает вопрос - о зависимости бизнес логики и состоянии приложения. Слой бизнес логики который будет реализован на actions который не будет менять состояние ?
Хорошее замечание. Получается нужно принимать идеологическое решение будет бизнеслогика жить отдельно от vuex, или по определению вся бизнеслогика - это методы vuex стора.
Мне понятно что теоретически описываемые случай может происходить, но я не могу придумать конкретного примера, у тебя есть какой пример на уме?
Думаю, что в приложении которое написано с использованием vue, удобно разбивать логику на компоненты, а в компоненте, методы которые соответствуют этому компоненту.
Vuex - используется для упрощения взаимодействия между компонентами (удобный инструмент). А сами компоненты взаимодействуют с vuex через actions. А внутри actions может, в зависимости от тех действий которые нужны, находятся getters и mutations. (как вариант, но не обязательно так).
Конечно приложение можно организовать и другим образом и добавить различных “ограничений” (в широком смысле этого слова) на уровне программиста или команды. Только хотелось бы знать какую выгоду от этих ограничений можно получить?
К примеру:
Увеличение быстродействия
Уменьшение используемой памяти
Уменьшение использования заряда батарейки
Уменьшения сложности
Уменьшение строк кода и/или избавление от дублирования кода.
Упрощение для тестирования
и др.
Идейные ограничения обычно вводят для уменьшения избыточной сложности и/или более жесткой структуры, для того что б новый человек быстрее смог вникнуть в процесс работы. Уменьшит ли то ограничение сложность понимания структуры приложения ?
P.S. Приложение - это довольно широкое понятие, которое на мой взгляд больше чем vue и организация его может быть самая различная, в которой vue всего лишь одна из составных частей. Я имел в виду приложение которое практически целиком описывается с использованием vue + extantions.
Ну и понятно, что это мое мнение, а не истина в конечной инстанции, я могу ошибаться :)
Только предсказуемость. Чтобы можно было описать “вся бизнеслогика у нас в vuex экшенах”. Я не утверждаю что так надо делать, это для примера. Тогда не будет появляться ситуаций когда программист пишет обработку запроса в компоненте, а в экшен передает уже результат ответа.
В точку. Ответа на этот вопрос у меня нет ибо ответ ситуативен. В частности я ищу такой подход, с которым невозможно представить больших проблем на средних (10к) и больших (10к+) кодовых базах, при этом базу можно растить инкрементно.
Я поднимаю эту тему потому что сам нахожусь в поиске набора практик которые упростят фуллстек разработку. При этом сравниваю подход mobx к моделированию (есть стор и есть экшены, которые умеют стор менять) и vuex (где есть и экшены и мутации). Подход разделения событий и эффектов встречается в других решениях для менеджмента состояния GitHub - day8/re-frame: A ClojureScript framework for building user interfaces, leveraging React (event и effect). И меня мучал вопрос: зачем во vuex 2 сущности чтобы работать со стором (мутации и экшены).
Да, читал эту штуку. Мне понятно что происходит но не почему. Почему нужны экшены? Что мне мешает вызвать аякс вне экшена, получить данные и вызывать мутацию? И если ничего, тогда в чем ценность экшенов?
Хм… Ну вот в качестве аналогии для примера можно привести пример из vue. Можно использовать v-model, а можно не использовать, заменив его обработчиком события. Но на мой взгляд v-model довольно удобная штука. (это просто пример, для того как одно и тоже можно реальзовать разными способами).
Или значения из vuex в компоненте можно получать на прямую через переменную, а можно через геттеры, а можно геттеры обернуть мутацией, а мутацию засунуть в экшены.
Возможно есть смысл реализовать одно и тоже на mutations и на actions. И понять, что более предпочтительно. А для большей надежности посмотреть в исходниках, как реализованы mutations и actions. С какими типами данных и как идет работа.
И вот вопрос - “В чем ценность экшенов?”. Хотя на основании этого вопроса, хочется задать и другой вопрос - “В чем ценность мутаций?”.
P.S. “Сразу после mutation можно получить результат.” Вот хорошо, если результатом не будет зависшее приложение.
P.P.S. Эти ответы основоны на моем убеждении того, что я понимаю вопрос. Но возможно, что я просто, не могу понять сути самого вопроса, того эти ответы могут показаться нелепыми :))
Как я понял если очень сильно упростить на идейном уровне:
Мутации - синхронны
Экшены - асинхронны
Геттеры = геттеры
Мутации = могут быть как геттерами так и сеттерами (могут в себе содержать геттеры)
Экшоны для взаимодействия компонентов с хранилищем. (может в себе содержать мутации и др.)