I help developers get prepared for interviews, and almost every interview for a React developer includes questions about state management in general and Redux in particular.

Whenever you’re asked about Redux, such as "What is Redux?" or "Why use Redux?", you can provide a structured “3 things” answer that includes the main facts about Redux that highlight its three most important features.

These functions make Redux a must-have technology for any application that is more complex than a single-page feedback form:

1️⃣ - There is only one state

2️⃣ - All changes have an explicit interface

3️⃣ - The state is immutable

Let’s go through them one by one.

1. There is only one state

One of the key features of Redux (that comes from Flux) is its centralized state management. Redux provides a central store that holds the entire state of an application. This makes it easier to manage and manipulate the state in a predictable and consistent way.

All components can access the state from the store and dispatch actions to update the state. This also helps to keep the application organized and reduces the risk of the state being scattered throughout the application.

In a nutshell, the Redux store instance is sitting in the React Context on the application level, so if you request the same piece of data from 2 different parts of your application you will get the same result:

const ComponentA = () => {
    // ...
    const user = useSelector(state => state.user)
    // ...
}

const ComponentB = () => {
    // ...
    const user = useSelector(state => state.user)
    // ...
}

These 2 components will get the same user as long as they are nested inside the same context.

2. All changes have an explicit interface

Another important feature of Redux is the way it enforces a predictable data flow. In Redux, all state changes are made through actions that have an explicit interface consisting of a type and a payload.

This means that we can't randomly change our state, and always follow a predictable and lucid flow. By using this interface, we can ensure that state changes are clear and easy to understand.

Let’s break down the flow into steps:

1. To dispatch the action we run a dispatch instance in our React component. Keep in mind that the instance comes from the same React context wrapper as our state.

    const SubmitFormButton = () => {
        // ...
        const handleSubmit = () => {
            dispatch({ 
                type: SUBMIT_FORM
                payload: formData
            })
        }
        // ...
    }
   

2. Under the Store’s hood, all middleware functions are being run. For example, Redux DevTools sees changes and updates its dashboard inside your browser. The same with any other middleware, such as Redux-Thunk or Saga.

3. Then all reducers are being run, that’s how changes are actually being applied.

4. Finally, all listeners are notified that the state has been changed. This is the way how React understands when it should re-render pieces of the interface that depend on the particular slices of data from the Redux.

3. State is immutable

Redux (as a part of the Flux philosophy) follows the principle of immutability, which means that the state is never directly modified.

Why it is important? At the first point, that unlocks an ability to time travel through our application history (using Redux DevTools), and see how data is being changed on each step, it’s never achievable with direct mutation, since middleware won’t be run without a dispatch, exactly the same with notifying listeners after the change was performed.

Also, if you use Redux actions for asynchronous operations (with Thunk or Saga), you want to make sure that your Thunks are being run, as well as DevTools middleware.

In summary, immutability helps us to:

• Do a proper, step-by-step debugging

• Make sure that any connected middleware (such as Redux-Thunk) will be run

• All listeners (such as React components) will be notified

---

My goal is to help developers understand and embrace programming concepts, so they can apply them in both interviews and day-to-day work. If you know the basics and want to grow further, hop on a train that's headed from developer productivity to high-level solution architecture.