2021-09-30
2512
#vue
Michael Gallagher
1742
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:

Kombai AI: The AI agent built for frontend development

Kombai AI converts Figma designs into clean, responsive frontend code. It helps developers build production-ready UIs faster while keeping design accuracy and code quality intact.

Jude Miracle
Oct 23, 2025 ⋅ 7 min read

The Replay (10/22/25): AI-assisted coding, Wasm 3.0, and more

Discover what’s new in The Replay, LogRocket’s newsletter for dev and engineering leaders, in the October 22nd issue.

Matt MacCormack
Oct 22, 2025 ⋅ 29 sec read
Where AI-assisted coding accelerates development — and where it doesn’t

Where AI-assisted coding accelerates development — and where it doesn’t

John Reilly discusses how software development has been changed by the innovations of AI: both the positives and the negatives.

John Reilly
Oct 22, 2025 ⋅ 12 min read
Debugging with Chrome DevTools MCP: Giving AI eyes in the browser

Debugging with Chrome DevTools MCP: Giving AI eyes in the browser

Learn how to effectively debug with Chrome DevTools MCP server, which provides AI agents access to Chrome DevTools directly inside your favorite code editor.

Emmanuel John
Oct 21, 2025 ⋅ 6 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?

    Thanks!

  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.

    Cheers
    Mike

Leave a Reply

Hey there, want to help make our blog better?

Join LogRocket’s Content Advisory Board. You’ll help inform the type of content we create and get access to exclusive meetups, social accreditation, and swag.

Sign up now