Michael Gallagher
Sep 30, 2021 ⋅ 8 min read

Vuex showdown: Mutations vs. actions

Michael Gallagher Living in the vibrant city of Buenos Aires, developing project management software with Teamwork. Modern JS is my passion; Vue, my tool of choice.

Recent posts:

Mastering Modulo Operator JavaScript

Mastering the modulo operator in JavaScript: A complete guide

We investigate how the modulo operator works in JavaScript and explore several real-life applications, like cyclic patterns and animations.

Timonwa Akintokun
Dec 8, 2023 ⋅ 7 min read
Ken Pickering Leader Spotlight

Leader Spotlight: Building with grit with Ken Pickering

Ken Pickering discusses the challenges associated with uncertainty and shares insights on scaling data structures and engineering teams.

Jessica Srinivas
Dec 8, 2023 ⋅ 7 min read
Understanding Solid Js Props A Complete Guide From Beginner To Advanced

Understanding SolidJS props: A complete guide

Let’s see how Solid props work to promote component reusability, exploring basic to advanced concepts for a complete understanding.

Temitope Oyedele
Dec 7, 2023 ⋅ 11 min read
Eleventy Vs. Next.js Static-Site Generation

Eleventy vs. Next.js for static site generation

We evaluate Eleventy and Next.js and compare both static site generators in terms of performance, developer experience, scalability, and ecosystem.

Nelson Michael
Dec 7, 2023 ⋅ 11 min read
View all posts

2 Replies to "Vuex showdown: Mutations vs. actions"

  1. Hi Michael, thanks for this nice article! Vuex is a great tool but I think we are lacking some guidelines to follow to get it right.

    I often read that mutations should be one-liners , or at least remain really simple… Why? The doc describes a mutation as a transaction, this term makes me think that we could write as much code as needed in a single mutation to enforce state coherency.

    Let’s take a simple example: an image with its width and height stored in the state, and a boolean to keep aspect ratio when changing the width or height. Would you advise to write the keep aspect ratio logic in the ´setWidth’ and ´setHeight’ mutations, or move it into the actions?


  2. Hey Jonathan,

    Glad you like the article, I’ve tried my best not to be overly opinionated about it. I normally use actions, even if it is just wrapping a mutation. The question for me in your example is whether there are 1 or 2 actions/mutations. You could have the 2 you mention, or maybe `setDimensions` which would set both? The reason I say it is that, to me, the width and height will probably always be set together, considering them as separate transactions for either mutations or actions, doesn’t give any additional benefit to traceability, readability or reusability. And this would cover your aspect ratio point also.


Leave a Reply