What does a typical action object look like?

In Redux, an action is a plain JavaScript object that describes what event occurred in the app. Each action must have a type field that identifies the kind of operation being performed, and it can optionally include a payload carrying additional data.

Key Components of an Action Object

1
type: A string that uniquely identifies the action, often namespaced by slice (e.g., counter/increment).
2
payload: Optional data that provides information needed by the reducer to update the state.
3
meta and error: Optional fields used for advanced use cases like async operations or error handling.

Example: Typical Action Object

Difficulty: 4/10

Topics: action shape, payload conventions, type prefixing

Scenario Questions

0-2 years experience

1
You're adding a new button that dispatches an async thunk. How would you structure the action object that the thunk returns on success?
2
If you look at Redux DevTools and see an action with type 'user/login' but no payload, what does that tell you about how the action was created?
3
When a reducer generated by createSlice runs, what fields does the incoming action object contain?

2-5 years experience

1
During a bug you notice the payload of an action dispatched from a component is undefined. Walk me through how you'd debug the action creator to ensure the correct shape.
2
You need to add a requestId to actions generated by createAsyncThunk. How would you modify the action object without breaking existing reducers?
3
Explain why an action from createAction sometimes includes an 'error' field and how that influences error handling in a slice.

5-8 years experience

1
Our team is migrating from plain Redux to RTK and wants a consistent action shape across slices. What patterns or middleware would you introduce, and how would you handle legacy actions?
2
We have a performance‑critical feature that dispatches thousands of actions per second. How would you optimise the action object to minimise serialization overhead?
3
When integrating RTK with a logging system that expects a 'meta' field, how would you ensure all actions—including those from createAsyncThunk—conform without touching each slice?

8+ years experience

1
The organization is standardising on a company‑wide action schema that includes correlation IDs, timestamps, and source identifiers. How would you architect the RTK setup (custom middleware, typed creators) to enforce this across multiple product teams while keeping developer experience smooth?
2
We need to support a micro‑frontend architecture where actions may cross module boundaries. Discuss the trade‑offs of embedding routing info in the action versus using a separate event bus, and how you'd implement the chosen approach with RTK.
3
Looking ahead, we plan to replace Redux with a new state‑management library. How would you design a deprecation strategy for existing action objects to allow a gradual migration?

Follow-up Questions

❓Can you show a concrete example of an action created by createAction?
❓What changes in the object when an async thunk is rejected?
❓How would you add custom metadata without breaking existing reducers?