Today and yesterday I spent time trying to understand a single lecture about Redux middleware.
The lecture itself was not very long, but the concept required deeper attention. Sometimes a small topic takes longer because it changes how you think about the system.
I also learned a little about loading states, but that part was relatively straightforward. The real challenge for me was understanding middleware.
At first, it didn’t fully click.
So I watched the lecture again, asked questions, and even used ChatGPT to clarify some parts until the concept became clearer.
Now I want to explain it in the simple way that made it finally click for me.
What Is Redux Middleware?
Middleware is something that sits between dispatching an action and the reducer processing that action.
In simple terms, middleware can intercept actions before they reach the reducer and perform additional logic.
This could include things like:
- logging actions
- handling asynchronous requests
- modifying actions
- dispatching new actions
Redux Toolkit vs Classic Redux
One interesting thing I discovered is that Redux Toolkit already includes middleware by default.
So if you are using Redux Toolkit, you usually don’t need to manually add it.
However, since I started learning with classic Redux, I had to install and configure middleware manually.
The steps were simple:
- Install the middleware
- Add it when creating the Redux store
- Apply it using Redux functions
But the important part is not the setup — it’s understanding why middleware exists.
The Problem Middleware Solves
Normally in Redux, when we dispatch an action, it must be a plain JavaScript object.
For example:
{ type: "account/deposit", payload: 100 }
Redux reducers expect actions to be simple objects.
Because of this rule, we cannot dispatch functions directly.
Where Middleware Helps
Middleware changes this limitation.
With middleware (for example Redux Thunk), we can dispatch functions instead of plain objects.
This allows us to write logic like:
- fetching data from APIs
- performing asynchronous operations
- dispatching multiple actions
Instead of sending an object directly, we send a function that contains logic.
That function can then dispatch real actions after the async work finishes.
This was the moment when the concept finally clicked for me.
My Current Understanding
Right now my mental model is this:
Normal Redux flow:
Action → Dispatch → Reducer → New State
Redux with middleware:
Action / Function → Middleware → Reducer → New State
Middleware acts like a processing layer that can control what happens before the reducer runs.
Final Thoughts
The lecture itself wasn’t very long, but the concept required patience to fully understand.
Sometimes learning programming is not about rushing through lectures. It’s about slowing down, repeating concepts, and waiting for that “click moment”.
Today was one of those moments for me.
Understanding middleware made Redux architecture feel much clearer.
And step by step, the bigger picture is starting to form.
Top comments (0)