Elegant

Actions are messages, not setters

The Elegant team 5 min readterminology
Actions are messages, not setters

The most common way to misuse Redux is to treat actions as setters: SET_USER, SET_LOADING, SET_ERROR, SET_ITEMS. It feels natural — you have a piece of state, so you write an action that sets it — but it quietly throws away the entire point of the pattern. An action is supposed to be a message about something that happened in the world, not a command telling the store which field to overwrite. USER_LOGGED_IN is a message; SET_USER is a setter wearing an action’s clothes. The difference decides whether your reducers stay readable and whether one event can update several slices at once.

One event as a setter reaches one field; as a message it reaches many reducers On the left SET_USER writes one field. On the right USER_LOGGED_IN is received by the user, cart and analytics reducers, each deciding its own change. setter SET_USER user field message USER_LOGGED_IN user cart analytics
A setter can only address one field. A message names an event, and every reducer that cares gets to respond in its own way.

A setter couples the caller to the shape

When you dispatch SET_LOADING, the component has to know there is a loading field and that it should be true right now. The knowledge of how state changes has leaked out of the reducer and into the caller. Compare a setter-style action with a message-style one:

// setter: the component decides the new state shape
dispatch({ type: "SET_LOADING", value: true });
dispatch({ type: "SET_ERROR", value: null });

// message: the component reports what happened; reducers decide the shape
dispatch({ type: "SEARCH_REQUESTED", query });

The message carries why, not what to write. That lets the reducer own the transition — clear the error, set loading, stash the query — in one place, and it lets a second reducer (say, analytics) react to the very same event without the caller knowing it exists.

One event, many reducers

Because every reducer sees every action, a single well-named message can fan out. USER_LOGGED_IN can populate the user slice, hydrate a saved cart, and reset a guest flag — three reducers, one dispatch, no coordination in the component:

// user.js
case "USER_LOGGED_IN": return { ...state, profile: action.user };
// cart.js
case "USER_LOGGED_IN": return { ...state, items: action.savedCart ?? state.items };
// ui.js
case "USER_LOGGED_IN": return { ...state, isGuest: false };

Try that with setters and you are dispatching three actions in the component and hoping nobody forgets one.

Name actions after events, in the past tense

The practical rule is to name actions the way you would narrate the app’s history: ITEM_ADDED_TO_CART, PAYMENT_FAILED, FILTER_CLEARED — past-tense facts, not imperative commands. When you find yourself writing SET_, stop and ask what actually happened that made you want to set that field, and name the action that. Your reducers become a log you can read, your components stop knowing the store’s shape, and the redux-devtools timeline turns into a story instead of a list of assignments. The action-creators exercise is where you practise phrasing these as events, which is most of what separates a maintainable store from a pile of setters.