02 / 10

Explain the concept of actions in Redux.

We can think of actions as events. An action describes something that happened in the application. An action is a plain JavaScript object that has a type field and can optionally include additional data payload.

By convention, we put data in a field called payload.
Difficulty: 5/10
Topics: action creators, payload structure, dispatch flow

Scenario Questions

0-2 years experience
  1. 1

    How would you create and dispatch an action to add a new item to a todo list in a Redux store?

  2. 2

    If you dispatch an action with a typo in its type field, what will happen in the reducer?

  3. 3

    What does the payload property represent in a Redux action, and how would you use it when updating state?

2-5 years experience
  1. 1

    We have a feature where users can edit a profile, but after dispatching the UPDATE_PROFILE action, the UI doesn't reflect the changes. Walk me through how you'd debug this.

  2. 2

    When designing action types for a large app, would you prefer string constants or a utility like createAction from Redux Toolkit? Explain the trade‑offs.

  3. 3

    Suppose you need to batch multiple related actions into a single network request. How would you structure the actions and what middleware might you use?

5-8 years experience
  1. 1

    Our application experiences performance issues because every action causes the entire state tree to be re‑serialized for logging. How would you redesign the action handling or logging to mitigate this at scale?

  2. 2

    We are migrating from plain action objects to using Redux Toolkit's createAction and createSlice. What architectural considerations and potential pitfalls should we watch for during the migration?

  3. 3

    In a micro‑frontend setup, different teams dispatch actions that may collide in type names. How would you design a naming convention or system to avoid conflicts while keeping actions discoverable?

8+ years experience
  1. 1

    Our organization has multiple legacy Redux codebases, each with its own action naming scheme. We want to unify them under a single convention without breaking existing apps. Outline a migration strategy and governance model.

  2. 2

    When introducing a new cross‑cutting feature like feature flags that needs to affect many reducers, how would you design the action payload and handling to minimize coupling and support future extensions?

  3. 3

    Considering long‑term maintainability, how would you evaluate whether to keep using Redux actions at all versus moving to an event‑sourcing or CQRS approach for a high‑throughput system?

Follow-up Questions

  • How would you test that your action creators produce the correct objects?
  • What are the trade‑offs of using string constants versus a utility like createAction?
  • How do you ensure backward compatibility when changing an action's shape?