[TIL] Суть экшенов и мутаций в vuex

Во vuex сторах есть экшены и мутации. Они бы оба про изменение данных. В пятницу до меня дошло что экшены это про бизнес логику, мутации - чисто про изменения состояния.

Если сравнивать с mobx, например, то в нем нет этого логического разделения. В mobx есть только “экшены которые могут мутировать состояние”. Поэтому у меня, работая с mobx, чешутся руки создать слой бизнеслогики вместо того чтобы слать запросы напряму из компонент.

Возникает вопрос - о зависимости бизнес логики и состоянии приложения. Слой бизнес логики который будет реализован на actions который не будет менять состояние ?

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

Мне понятно что теоретически описываемые случай может происходить, но я не могу придумать конкретного примера, у тебя есть какой пример на уме?

Думаю, что в приложении которое написано с использованием vue, удобно разбивать логику на компоненты, а в компоненте, методы которые соответствуют этому компоненту.

Vuex - используется для упрощения взаимодействия между компонентами (удобный инструмент). А сами компоненты взаимодействуют с vuex через actions. А внутри actions может, в зависимости от тех действий которые нужны, находятся getters и mutations. (как вариант, но не обязательно так).

Конечно приложение можно организовать и другим образом и добавить различных “ограничений” (в широком смысле этого слова) на уровне программиста или команды. Только хотелось бы знать какую выгоду от этих ограничений можно получить?

К примеру:

  1. Увеличение быстродействия
  2. Уменьшение используемой памяти
  3. Уменьшение использования заряда батарейки
  4. Уменьшения сложности
  5. Уменьшение строк кода и/или избавление от дублирования кода.
  6. Упрощение для тестирования

и др.

Идейные ограничения обычно вводят для уменьшения избыточной сложности и/или более жесткой структуры, для того что б новый человек быстрее смог вникнуть в процесс работы. Уменьшит ли то ограничение сложность понимания структуры приложения ?

P.S. Приложение - это довольно широкое понятие, которое на мой взгляд больше чем vue и организация его может быть самая различная, в которой vue всего лишь одна из составных частей. Я имел в виду приложение которое практически целиком описывается с использованием vue + extantions.
Ну и понятно, что это мое мнение, а не истина в конечной инстанции, я могу ошибаться :)

1 лайк

Только предсказуемость. Чтобы можно было описать “вся бизнеслогика у нас в vuex экшенах”. Я не утверждаю что так надо делать, это для примера. Тогда не будет появляться ситуаций когда программист пишет обработку запроса в компоненте, а в экшен передает уже результат ответа.

В точку. Ответа на этот вопрос у меня нет ибо ответ ситуативен. В частности я ищу такой подход, с которым невозможно представить больших проблем на средних (10к) и больших (10к+) кодовых базах, при этом базу можно растить инкрементно.

Я поднимаю эту тему потому что сам нахожусь в поиске набора практик которые упростят фуллстек разработку. При этом сравниваю подход mobx к моделированию (есть стор и есть экшены, которые умеют стор менять) и vuex (где есть и экшены и мутации). Подход разделения событий и эффектов встречается в других решениях для менеджмента состояния GitHub - day8/re-frame: A ClojureScript framework for building user interfaces, leveraging React (event и effect). И меня мучал вопрос: зачем во vuex 2 сущности чтобы работать со стором (мутации и экшены).

Может тебе будет полезна информация о том что actions и mutations реализованы по разному внутри vuex. Actions - асинхронны.

В том смысле что сразу же после mutation можно получить результат mutation, и это не так для action. Есть ли еще последствия, которые я не описал?

Вот интересная статейка на офф сайте.
https://vuex.vuejs.org/ru/guide/actions.html

Да, читал эту штуку. Мне понятно что происходит но не почему. Почему нужны экшены? Что мне мешает вызвать аякс вне экшена, получить данные и вызывать мутацию? И если ничего, тогда в чем ценность экшенов?

Хм… Ну вот в качестве аналогии для примера можно привести пример из vue. Можно использовать v-model, а можно не использовать, заменив его обработчиком события. Но на мой взгляд v-model довольно удобная штука. (это просто пример, для того как одно и тоже можно реальзовать разными способами).

Или значения из vuex в компоненте можно получать на прямую через переменную, а можно через геттеры, а можно геттеры обернуть мутацией, а мутацию засунуть в экшены.

Возможно есть смысл реализовать одно и тоже на mutations и на actions. И понять, что более предпочтительно. А для большей надежности посмотреть в исходниках, как реализованы mutations и actions. С какими типами данных и как идет работа.

И вот вопрос - “В чем ценность экшенов?”. Хотя на основании этого вопроса, хочется задать и другой вопрос - “В чем ценность мутаций?”.

P.S. “Сразу после mutation можно получить результат.” Вот хорошо, если результатом не будет зависшее приложение.

P.P.S. Эти ответы основоны на моем убеждении того, что я понимаю вопрос. Но возможно, что я просто, не могу понять сути самого вопроса, того эти ответы могут показаться нелепыми :))

Как я понял если очень сильно упростить на идейном уровне:

Мутации - синхронны
Экшены - асинхронны

Геттеры = геттеры
Мутации = могут быть как геттерами так и сеттерами (могут в себе содержать геттеры)
Экшоны для взаимодействия компонентов с хранилищем. (может в себе содержать мутации и др.)