Forem: Usama

The Hardest Phase in Development No One Talks About

Usama — Sun, 12 Apr 2026 16:07:49 +0000

When people think about software development, they usually imagine one thing:

Coding.

Writing functions.

Fixing bugs.

Building UI.

And yes, that part is hard… in the beginning.

But after spending enough time—months, maybe a year—you realize something uncomfortable:

Coding is not the hardest part anymore.

The Phase That Breaks You

Right now, I’m going through a phase that feels completely different.

I can code.

I can build components.

I can follow tutorials.

I can even complete projects.

But when I sit down to build something on my own from scratch, my mind goes blank.

What should I build first?
How should I structure this system?
How will different parts connect?
What happens when this scales?

This is the phase I call:

Architecture Thinking

And honestly… it’s painful.

Why This Phase Feels So Difficult

Because suddenly:

There is no step-by-step guide
There is no exact tutorial
There is no copy-paste solution

You are forced to think.

Not just write code—but design systems.

And that’s a completely different skill.

You Can’t Learn This From Tutorials Alone

This is something I’ve realized the hard way:

YouTube can teach syntax
Courses can teach frameworks
AI can help you debug

But none of them can fully teach you how to think like an engineer.

Because architecture thinking is not about:

“How to write code”

It’s about:

“What code should exist in the first place?”

The Truth No One Tells You

There is no single:

Perfect course
Perfect book
Perfect roadmap

That will magically give you this skill.

Because this phase requires something uncomfortable:

Struggling with unclear problems.

My Current Approach (Still Learning)

I’m not an expert yet.

I’m still in this phase.

Still confused. Still learning.

But one thing is slowly helping me:

1. Start With the Big Picture

Before writing code, I try to ask:

What is the goal of this system?
Who is using it?
What are the main parts?

2. Break It Into Small Pieces

Instead of thinking:

“Build entire app”

I think:

Authentication
Dashboard
Data flow
API structure

Small, understandable chunks.

3. Think Before Coding

Earlier, I used to jump directly into coding.

Now I try to pause and ask:

Why this approach?
Is there a simpler way?
What will break later?

4. Accept the Pain

This is the hardest part.

Because this phase feels like:

Slow progress
Confusion
Self-doubt

But I’m starting to believe:

This pain is a sign of growth.

Where I Stand Right Now

I’m not someone who has mastered architecture.

I’m someone who is experiencing it for the first time.

And it’s uncomfortable.

But it also feels like:

I’m finally moving from “coder” → “engineer”

Final Thought

If you’re also feeling stuck at this stage…

If coding feels easy but building systems feels impossible…

Then maybe you’re not lost.

Maybe…

You’ve just entered the hardest phase of development.

And that’s exactly where real growth begins.

I Had to Stop Writing to Start Understanding

Usama — Thu, 02 Apr 2026 16:09:23 +0000

I didn’t plan this.

I started writing blogs because I wanted my message to reach beyond my circle. I wanted to help people — even if it was in a small way. Writing felt like a bridge between what I was learning and what others might need.

But now… I’ve decided to stop. At least for a while.

Not because I’ve lost interest.
Not because I’ve run out of ideas.

But because I finally understood something uncomfortable:

I know concepts… but I don’t truly understand them.

The Illusion of Knowing

As developers, we often feel like we “get it.”

We can build a UI
We can use state
We can set up routing
We can make things work

But is that enough?

I realized something while working:

Knowing how to do something is very different from knowing why, when, and what happens if it breaks.

For example:

Everyone can create a UI.

But:

Can you design a UI that aligns with how a client thinks?
Can you predict where it might fail?
Can you explain your UI decisions clearly to a non-technical person?
Can you design interactions that feel natural instead of forced?

That’s a completely different level.

And I’m not there yet.

The Real Gap: Depth

Right now, my biggest struggle is not learning new things.

It’s going deep into the things I already “know.”

Some concepts take:

2 days
3 days
Sometimes even more

And still… they don’t fully click.

Things like:

State management (beyond basic usage)
Routing logic and data flow
Component architecture
UI behavior under edge cases

These are not things you can “finish” in a day and write a blog about.

They demand:

Isolation
Focus
Repetition
Failure

And honestly… patience.

Why I’m Pausing My Blogs

I used to write regularly.

But now I’ve realized:

Writing fast is slowing down my understanding.

If I keep pushing myself to write weekly or daily:

I’ll only explain surface-level ideas
I’ll repeat what others are already saying
I won’t grow beyond a certain point

And that’s not what I want anymore.

So I made a hard decision:

I will write less… but understand more.

A Shift in Identity

Earlier, I was writing as a learner documenting the journey.

Now, I want to write as:

Someone who has struggled with a concept long enough to truly understand it.

Not just:

“Here’s how you use it”

But:

“Here’s how it breaks”
“Here’s what nobody tells you”
“Here’s what actually matters in real projects”

That kind of writing takes time.

And right now, I need that time for myself.

About AI and Fear

There’s another pressure we all feel today.

AI.

Everywhere you look, there’s noise:

“AI will replace developers”
“Learn faster or fall behind”
“Do more in less time”

And honestly… it’s overwhelming.

But I’ve come to a simple belief:

If you’re doing something, do it with your heart.

Because in the end:

Tools will change
Trends will change
Speed will change

But depth will always matter.

AI can generate code.

But:

Can it understand your client deeply?
Can it feel the friction in a user experience?
Can it make intentional decisions for your product?

That’s where we still matter.

This Is Not an End

I’m not quitting writing.

I’m just… stepping back.

Learning slowly.
Understanding deeply.
Building real clarity.

And when I come back:

It won’t be frequent.

But it will be real.

Final Thought

If you’re in the same place — feeling like you “know things” but not deeply enough…

You’re not behind.

You’re just at the point where real learning begins.

Take your time.

Go deeper.

And don’t rush your growth just to stay visible.

Because sometimes…

Silence builds stronger developers than noise ever can.

The Day I Finally Understood `useActionData` (React Router)

Usama — Sun, 29 Mar 2026 12:46:59 +0000

There are some concepts in programming that don’t just confuse you… they haunt you.

For me, one of those concepts was useActionData in React Router.

I remember clearly — when I first learned it, everything made sense. I implemented it, it worked, and I moved on.

But then…

A few days later, I opened my old code, looked at it, and thought:

“What is this doing… and why did I even write this?”

The Confusion

I even tried reading the definition again:

“Returns the data from the last action.”

Simple sentence.
Zero clarity.

I watched YouTube videos.
Still confused.

I checked my own code.
Even more confused.

At that point, I realized something important:

👉 I didn’t need more information
👉 I needed a clear mental model

Let’s Break It Down (In Simple Language)

Think of useActionData like this:

👉 It is a way to get the result of a form submission handled by React Router

That’s it.

The Real Flow (Step-by-Step)

Let me explain what actually happens behind the scenes.

1. You create a form using React Router

<Form method="post">
  <input name="username" />
  <button type="submit">Submit</button>
</Form>

This is not a normal form.

This form is connected to React Router.

2. You define an `action` function in your route

export async function action({ request }) {
  const formData = await request.formData();
  const username = formData.get("username");

  if (!username) {
    return { error: "Username is required" };
  }

  return { success: "Form submitted successfully" };
}

👉 This action runs when the form is submitted
👉 It processes the data
👉 It returns something (important!)

3. Now comes `useActionData`

const data = useActionData();

👉 This hook gives you whatever the action returned

The Key Idea (THIS is what I was missing)

useActionData = “Show me the result of my last form submission”

Why Do We Even Need It?

Because after submitting a form, we often want to:

Show errors (validation)
Show success messages
Show server responses

And React Router gives us a clean way to do that.

Real Example (Now It Makes Sense)

const data = useActionData();

return (
  <>
    <Form method="post">
      <input name="username" />
      <button type="submit">Submit</button>
    </Form>

    {data?.error && <p style={{ color: "red" }}>{data.error}</p>}
    {data?.success && <p>{data.success}</p>}
  </>
);

What’s Actually Happening?

Let me say it in very simple words:

User submits the form
React Router calls the action
action processes data and returns something
useActionData receives that return value
UI updates based on it

The Mistake I Was Making

I was thinking:

❌ “This is some complicated magic function”

But in reality:

✅ It’s just a bridge between backend logic (action) and UI

One Line Summary (For Future Me)

useActionData is used to access and display the result of a form submission handled by a route action.

When Should You Use It?

Use it when:

You are using <Form> from React Router
You have an action function
You want to show errors or results without manual state

When NOT to Use It

Don’t use it when:

You’re using normal React forms (onSubmit)
You’re handling everything with useState
No action function is involved

Final Thought

This concept confused me not because it was hard…

…but because I didn’t understand the flow.

Now I do.

And if future me ever gets confused again:

👉 Just remember:

Form → Action → Return → useActionData → UI

That’s the whole story.

Week 24: Redux Toolkit Finally Made Redux Feel Simple + Deep Dive into React Router Data Fetching

Usama — Wed, 25 Mar 2026 16:24:32 +0000

This week felt like a shift.

Not because I learned something completely new…
But because things that once felt complex started becoming simple.

I moved from classic Redux to Redux Toolkit, and at the same time, I started understanding React Router at a deeper level — especially how data fetching actually works.

From Redux Complexity to Redux Toolkit Simplicity

Before this week, Redux felt structured… but heavy.

For a single feature, I had to think about:

action types
action creators
reducers
store setup

It worked, but it didn’t feel efficient.

Then I started using Redux Toolkit.

And honestly… it changed how I see Redux.

The Moment Redux Toolkit Clicked

Two things made the biggest difference for me:

1️⃣ `configureStore`

Earlier, setting up a store required multiple functions.

Now it’s just:

one clean configuration
everything handled internally

No unnecessary setup.
No confusion.

2️⃣ `createSlice`

This was the biggest upgrade.

Instead of writing:

action types
action creators
reducers

I can now define everything in one place.

That means:

👉 Less boilerplate
👉 Cleaner code
👉 Better structure

For the first time, Redux felt practical.

Middleware & Thunks — Real-World Logic

I continued working with Redux Thunk.

This helped me understand how Redux handles:

API calls
async logic
delayed actions

Instead of putting everything inside components, I started moving logic into Redux.

This made my components:

👉 cleaner
👉 easier to manage

React Router — Not Just Navigation Anymore

This week I also went deeper into React Router.

Before, I used it only for navigation.

Now I started understanding:

👉 It’s not just routing
👉 It’s also about data flow

Understanding `createBrowserRouter`

Instead of defining routes in a simple way, I explored a more structured approach.

Routes now feel like:

a configuration system
not just components

This makes large applications easier to manage.

Data Fetching with React Router (Big Realization)

This was the most interesting part of the week.

Before:

I used to fetch data inside components using useEffect.

Now:

React Router allows fetching data before the component renders.

That means:

better user experience
cleaner components
more predictable data flow

This felt like a more professional approach.

What Changed for Me This Week

Before Week 24:

Redux felt heavy.
Routing felt basic.

After Week 24:

Redux feels simpler and cleaner.
Routing feels more powerful and structured.

Key Takeaways

Redux Toolkit reduces unnecessary complexity
configureStore simplifies setup
createSlice organizes everything in one place
Thunks help handle real-world async logic
React Router is more than just navigation
Route-based data fetching improves architecture

Final Thoughts

This week wasn’t about learning more tools.

It was about learning better ways to use them.

That’s the difference.

And slowly, things are starting to connect.

If you're learning React and Redux, my advice:

Don’t just follow tutorials.

Try to understand:

how data flows
where logic should live
how to structure things properly

That’s where real growth happens.

I Finally Understood How to Pass Multiple Values in Redux Toolkit (The Right Way)

Usama — Thu, 19 Mar 2026 00:47:11 +0000

Today was one of those small learning moments…
but it completely changed how I write Redux logic.

I used to think:

👉 “Redux actions can only take one value”
👉 “If I need more data, things will get messy”

But today I learned a clean and scalable way to handle multiple values in Redux Toolkit using the prepare function.

The Problem I Faced

I was trying to dispatch an action like this:

Loan amount
Loan purpose

At first, I didn’t know how to pass both values properly.

I thought maybe I need:

multiple actions
or a complex payload structure

But that would make things messy and hard to maintain.

The Solution: `prepare` Function in Redux Toolkit

Then I discovered something powerful inside createSlice:

👉 The prepare method

Here’s the code I worked with:

requestLoan: {
  prepare(amount, purpose) {
    return {
      payload: { amount, purpose },
    };
  },

  reducer(state, action) {
    if (state.loan > 0) return;

    state.loan = action.payload.amount;
    state.loanPurpose = action.payload.purpose;
    state.balance += action.payload.amount;
  },
}

What’s Happening Here?

This is what I understood:

1️⃣ `prepare` Handles Multiple Arguments

Instead of passing one object manually, I can do this:

dispatch(requestLoan(5000, "Buy Car"));

And prepare converts it into:

payload: {
  amount: 5000,
  purpose: "Buy Car"
}

Clean. Structured. Scalable.

2️⃣ Reducer Stays Simple

Inside the reducer, I don’t worry about arguments anymore.

I just use:

action.payload.amount
action.payload.purpose

Everything is already organized.

3️⃣ Logic Feels More Professional

This approach helped me:

avoid messy payload creation in components
keep logic centralized
write cleaner and more readable reducers

Why This Matters

Before this, I was thinking in a limited way.

Now I understand:

👉 Redux Toolkit is designed to simplify complex patterns
👉 You don’t need hacks — just the right tools

Using prepare:

makes actions flexible
keeps reducers clean
improves scalability

My Key Takeaway

Today I learned:

You don’t need multiple actions for multiple values.

You just need a better way to structure your payload.

And prepare gives you exactly that.

Final Thoughts

This wasn’t a big feature.

But it was a big mindset shift.

Redux Toolkit is not just about writing less code…

It’s about writing smarter and cleaner code.

If you're learning Redux Toolkit, don’t ignore small features like this.

Sometimes, these small things make the biggest difference.

why start i use redux toolkit? why not classic redux?

Usama — Tue, 17 Mar 2026 17:32:56 +0000

I Was Writing 4 Redux Functions for Everything… Until Redux Toolkit Changed It

When I first started learning Redux, I thought this was just how things worked.

If I needed to manage a simple feature, I had to write:

Action types
Action creators
Reducers
Store configuration

At first, it felt “professional”.

But after a few days, it started to feel… repetitive.

And honestly, a bit exhausting.

The Problem With Classic Redux (From My Experience)

Let me be real.

Redux is powerful. No doubt.

But as a beginner, I kept asking myself:

Why do I need so much code just to update a simple state?

For one feature, I was jumping between multiple files:

actions.js
reducers.js
store.js

And inside those files:

writing constants
writing functions
writing switch cases

It felt like I was doing the same thing again and again.

Then I Discovered Redux Toolkit

Today, I finally spent time understanding Redux Toolkit.

And this is where everything started to change.

Redux Toolkit is basically the modern way of writing Redux.

It removes the unnecessary complexity and keeps the power.

The Moment That Changed Everything

There were two functions that completely changed my understanding:

1️⃣ `configureStore`

Before:

I had to manually use:

createStore
combineReducers
applyMiddleware

Now:

Just one function:

const store = configureStore({
  reducer: rootReducer,
});

That’s it.

Everything is handled internally.

No extra setup.

2️⃣ `createSlice`

This one honestly surprised me.

Before, I had to write:

action types
action creators
reducers

Separately.

Now:

const counterSlice = createSlice({
  name: "counter",
  initialState: { value: 0 },
  reducers: {
    increment(state) {
      state.value++;
    },
  },
});

And just like that:

actions are created automatically
reducer is created automatically

One function replaces 3–4 things.

The Best Part: Cleaner Code

What I really liked is how clean everything feels now.

No switch statements
No scattered files
No repeated boilerplate

Everything lives in one place.

And for the first time, Redux felt… simple.

A Small But Important Realization

Another thing I learned today:

You don’t have to switch everything at once.

You can use:

classic Redux
Redux Toolkit

in the same project

And both connect to React in the same way.

That means you can migrate step by step.

No pressure.

What I Learned Today

Today wasn’t about building something big.

It was about understanding:

How to write better Redux code.

How to reduce unnecessary complexity.

How to focus more on logic instead of boilerplate.

Final Thoughts

Before today, Redux felt like a lot of work.

After understanding Redux Toolkit, it finally started to feel practical.

If you’re learning Redux right now, my honest advice:

Don’t just learn classic Redux.

Learn Redux Toolkit early.

It will save you time, energy, and a lot of confusion.

Week 23: I Finally Went Deep Into Redux (And It Started Making Sense)

Usama — Tue, 17 Mar 2026 17:24:02 +0000

This week was intense.

Not because Redux is impossible…
But because I finally stopped just “using” it — and started understanding how it actually works under the hood.

And that changed everything.

From Confusion to Clarity

Before this week, Redux felt like a set of rules I had to follow:

Dispatch this
Write that reducer
Create actions
Connect everything

It worked… but I didn’t fully get it.

This week, I decided to go deeper.

Understanding the Redux Store (The Brain)

The biggest realization:

Redux Store is not just storage.

It’s the single source of truth for the entire application.

Everything flows through it:

State lives here
Actions go here
Reducers update it

Once I understood this flow, Redux stopped feeling random.

It started feeling predictable.

Action Creator Functions (Not Just Functions)

Earlier, I used to think action creators were just “extra functions”.

But now I understand their real purpose:

They make actions:

reusable
consistent
easier to manage

Instead of manually creating objects every time, action creators standardize everything.

Redux File Structure (Why It Matters)

This week I also explored proper file structure.

Before, my files were scattered.

Now I understand why developers organize Redux like:

store.js
features/
separate slices or reducers

A good structure is not about “clean folders”.

It’s about scalability.

Because when your app grows, bad structure becomes a real problem.

Dispatching (The Trigger Point)

Dispatch finally clicked for me.

It’s not just a function.

It’s the only way to change state.

That means:

No direct updates.
No shortcuts.

Everything must go through dispatch.

And that’s what makes Redux predictable.

Redux Middleware (The Hidden Power)

This was one of the most interesting parts of the week.

Middleware sits between:

👉 Action → Reducer

And it can:

log actions
handle async logic
modify behavior

It’s like a gatekeeper for your state flow.

Thunks (Handling Async Like a Pro)

Before learning thunks, I didn’t fully understand how Redux handles async code.

Now I do.

Thunks allow us to:

write async logic
delay dispatching
handle API calls

This is where Redux becomes truly powerful.

Making API Calls with Redux

This was a big step.

Instead of calling APIs directly in components, I learned to:

move logic into Redux
handle loading states
manage success and errors

Now the data flow feels:

cleaner
centralized
easier to debug

Redux DevTools (Game Changer)

If there is one tool that made the biggest difference this week, it’s Redux DevTools.

Before:

Debugging felt messy.

After:

I can see:

every action
every state change
full history of my app

And the best part?

👉 Time-travel debugging

I can literally go back and see where things broke.

That’s insane.

What Changed for Me This Week

Before Week 23:

Redux felt complicated.

After Week 23:

Redux feels structured and logical.

I won’t say it’s “easy” yet.

But now I understand:

👉 Why things are done
👉 Not just how they are done

And that’s a big shift.

Final Thoughts

This week wasn’t about building fancy UI.

It was about building mental clarity.

Understanding:

how data flows
how state is managed
how real applications scale

Redux is not just a library.

It’s a way of thinking.

And this week, I finally started thinking like it.

If you’re learning Redux, don’t rush.

Take time to understand:

Store
Dispatch
Middleware
Async flow

Because once it clicks…

Everything starts making sense.

I Thought Redux DevTools Was Just a Fancy Logger — Until I Actually Used It

Usama — Sun, 15 Mar 2026 11:53:25 +0000

When I first started learning Redux, I thought Redux DevTools was just another debugging tool.

You know… something like console.log() but with a better UI.

But when I actually started building real features, I realized something surprising:

Redux DevTools is not just a debugger.
It is a complete timeline of your application's brain.

And once you understand that, debugging Redux becomes 10x easier.

The Problem I Faced While Learning Redux

While building a feature in my React project, I had a simple flow:

User clicks a button
An action dispatches
The reducer updates the state
UI re-renders

Simple right?

But something weird happened.

The UI was not updating the way I expected.

At first I tried:

console.log(action)
console.log(state)
checking reducers manually

But after a few actions, the logs became messy.

I couldn't clearly understand:

Which action triggered the bug
What the previous state was
What the next state became

That is where Redux DevTools completely changed the debugging experience.

What Redux DevTools Actually Does

Redux DevTools is a browser extension that lets developers inspect every action and state change in a Redux application. ([Artoon Solutions][1])

Instead of guessing what happened in your application, you can literally see the entire state timeline.

Think of it like a recording of everything that happened in your Redux store.

The Feature That Blew My Mind: Time Travel Debugging

This was the moment I realized why Redux DevTools is powerful.

Redux DevTools allows something called time-travel debugging.

Meaning:

You can move backward and forward through your application's state history. ([Colin.js][2])

Yes… literally.

Example:

Action 1 → LOGIN_USER
Action 2 → ADD_ITEM
Action 3 → REMOVE_ITEM

You can click any action and Redux DevTools will show:

Previous State
Action Payload
Next State

This means you can instantly see which action broke your app.

No guessing.

Real Example: Debugging a Cart Bug

Imagine you're building an e-commerce cart.

A user adds a product and the quantity becomes wrong.

Without Redux DevTools:

You would probably add logs everywhere.

With Redux DevTools:

You just open the DevTools and see:

ADD_PRODUCT
previousState: { cart: [] }

nextState: { cart: [{ id: 1, quantity: 2 }] }

Boom.

Now you instantly know the reducer logic is wrong.

This is why many teams use DevTools to trace bugs in complex applications. ([pixeeto.com][3])

My Favorite Redux DevTools Features

1️⃣ Action History

Every action is recorded.

You can see:

action type
payload
timestamp

This helps you understand exactly what triggered a state change.

2️⃣ State Tree Inspector

You can inspect the entire Redux store.

Nested objects, arrays, everything.

No more console.log(state) everywhere.

3️⃣ Action Replay

You can replay actions.

Meaning you can reproduce bugs without manually repeating user steps.

This is extremely useful when debugging.

4️⃣ Import / Export State

You can export the state snapshot and send it to another developer.

They can load it and reproduce the exact bug scenario.

The Biggest Lesson I Learned

Before Redux DevTools:

Debugging Redux felt confusing.

After Redux DevTools:

Redux actually became one of the easiest things to debug.

Because everything is:

predictable
visible
traceable

Redux forces your application to follow a clear data flow.

And DevTools lets you watch that flow step by step.

One Important Tip

Never enable Redux DevTools in production.

Because it exposes the entire state of your application.

Use it only in development mode.

Final Thoughts

At first, Redux DevTools looked like just another extension.

But once I started using it during real debugging, I realized something:

It’s not just a tool.

It’s like having X-ray vision into your application's state.

And once you get used to it, debugging Redux without DevTools feels almost impossible.

If you're learning Redux right now, my advice is simple:

Don't just install Redux DevTools.

Actually learn how to read the action timeline.

Because that's where Redux truly starts making sense.

Why Redux Middleware Exists (And The Moment It Finally Made Sense to Me)

Usama — Sat, 14 Mar 2026 11:19:52 +0000

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.

Redux vs Context API — Same Energy, Different Power Level

Usama — Wed, 11 Mar 2026 17:10:47 +0000

I need to be honest with you about something.

When I first started learning Redux, I kept getting this nagging feeling — have I seen this before? The Provider wrapping the app. The hook that reads state. The function that updates it. It all felt familiar in a way I couldn't place.

Then it hit me. Context API. I'd learned this already. Just under a different name.

And once I made that connection, Redux stopped feeling like a new language. It felt like an upgrade to one I already spoke.

The Concepts Map Almost Perfectly

Let me show you what I mean side by side.

Context API has createContext — Redux has createSlice

In Context, you create a context object to hold a piece of state. In Redux, you create a slice. Both are you saying: this is a dedicated space for this specific data. The slice just gives you more — built-in reducers, action creators, and cleaner organisation out of the box.

Both have a Provider. Literally.

This one made me laugh when I realised it. Context API uses <MyContext.Provider>. Redux uses <Provider store={store}>. You wrap your app. You pass in the data source. Every child gets access. The concept is identical — Redux just has one global Provider instead of one per context.

useContext → useSelector

In Context, you call useContext(MyContext) to read your state. In Redux, you call useSelector((state) => state.slice.value). Both are hooks. Both read from a shared source. The difference is that useSelector is more precise — you pick exactly which piece of state you need, which means your component only re-renders when that specific piece changes.

setState / useReducer dispatch → useDispatch

In Context, you either call a setter function or dispatch an action through useReducer. In Redux, you call useDispatch and fire an action. Same idea. You're telling the system: something happened, update accordingly.

So What's Actually Different?

The concepts are the same. The difference is scale and control.

Context API is lightweight and built into React. It's perfect for small to medium apps — things like theme toggling, auth state, language preference. It gets the job done without adding any dependencies.

But when your app grows, Context starts to show cracks. Every time context value changes, every component consuming it re-renders — even if it only cares about one small part of the data. For a large app with complex, frequently-changing state, that becomes a performance problem.

Redux was built for that scale. It gives you fine-grained subscriptions through useSelector, a single organised store with clear structure, and DevTools that let you time-travel through every state change like a debugging superpower. It's more setup, but it earns its complexity.

The Way I Think About It Now

Context API is your local neighbourhood — quick, accessible, good for everyday things.

Redux is the city infrastructure — more complex to build, but designed to handle real traffic.

If Sanjana taught you Context API, you already understand the soul of Redux. You're not starting over. You're levelling up. The Provider is still a Provider. The hook that reads is still a hook that reads. The function that writes is still a function that writes.

The vocabulary changed. The grammar didn't.

Why This Realisation Matters

Learning gets so much easier when you stop treating every new tool like it's foreign. Redux felt intimidating because I approached it like a stranger. The moment I saw it as Context API's bigger, more structured cousin — it opened up.

That's the meta-lesson here. Concepts in programming repeat. They evolve. They get refined. But the underlying ideas stay consistent. The more you learn, the more you'll notice: it's never completely new. It's always a variation of something you already know.

Keep connecting the dots. That's how this actually works.

React Week 22: Mastering useEffect Rules, Closures, Performance Optimization & Starting Redux

Usama — Tue, 10 Mar 2026 16:11:07 +0000

This week was mainly about understanding React behavior at a deeper level and beginning my journey into Redux state management.

Instead of focusing on building large features, I spent most of my time studying how React works internally, especially around effects, closures, and performance optimization.

These concepts are not always visible in the UI, but they are extremely important for writing predictable and efficient React applications.

Understanding useEffect Rules and Best Practices

One of my main goals this week was to improve my understanding of useEffect.

Many developers (including myself earlier) tend to use useEffect for almost everything. But after studying it more carefully, I realized that effects should be used only when necessary.

I focused on learning the core rules and best practices, such as:

Using useEffect only for side effects
Avoiding derived state inside effects
Understanding the importance of dependency arrays
Cleaning up effects properly when components re-render or unmount

This helped me better understand when useEffect should be used and when it should be avoided.

Understanding Closures Inside useEffect

Another important concept I studied this week was closures inside useEffect.

Closures can sometimes cause unexpected behavior, especially when working with:

intervals
timers
asynchronous logic

If the dependencies are not handled correctly, the effect might capture stale state values, which can lead to bugs.

Understanding this concept helped me see why dependency management in React is so important.

Performance Optimization Challenge

This week I also worked on a performance optimization challenge using a project called Workout Timer.

The goal of this challenge was not just to build the UI but to analyze how React components render and update.

While working on this project, I practiced:

analyzing unnecessary re-renders
understanding how effects influence rendering
structuring components more efficiently
thinking about performance early in development

This challenge helped me think more like a React developer who cares about performance, not just functionality.

Starting My Redux Journey

Another big milestone this week was starting to understand Redux.

At first, Redux felt complex, but I quickly noticed that its core idea is very similar to React’s useReducer hook.

The basic Redux flow includes:

defining an initial state
creating a reducer function
creating a Redux store
dispatching actions
updating state through the reducer

Understanding this structure helped me see how Redux manages global state across an application.

Learning About Redux Store and Action Creators

I also began learning about:

Redux Store – the central place where application state is stored
Action Creator Functions – helper functions that create action objects

These concepts make state management more structured and predictable, especially in larger applications.

Although modern tools like Redux Toolkit simplify Redux development, I focused on understanding the classic Redux flow first.

What I Learned This Week

Week 22 helped me improve my understanding of several important concepts:

useEffect rules and best practices
closures inside React hooks
performance optimization thinking
Redux fundamentals
Redux store and action creators

These topics are more about understanding React deeply rather than just building features.

Moving Forward

Next, I plan to continue exploring:

Redux Toolkit
more performance optimization techniques
improving component architecture

The goal is to gradually build a stronger foundation in React application architecture and state management.

Every week I try to focus not only on building projects but also on understanding the concepts that make React applications scalable and maintainable.

Step by step, the journey continues

Writing My First Redux Code — And Realizing How Similar It Is to useReducer

Usama — Sun, 08 Mar 2026 12:56:06 +0000

Yesterday I started exploring Redux and one thing immediately stood out to me.

Redux feels very similar to React’s useReducer hook.

Yesterday I mostly observed and tried to understand the structure.
But today I finally started writing my own Redux code, and the similarities became even clearer.

Step 1: Creating the Initial State

Just like useReducer, the first thing we need in Redux is an initial state.

This initial state holds the starting values for our application.

For example, it might contain things like:

account balance
loan amount
transaction history

All the default values are defined here before any action changes the state.

Step 2: Writing the Reducer Function

The next step is creating a reducer function.

This is also very similar to useReducer.

The reducer receives two things:

state
action

Inside the reducer we usually use a switch statement to handle different action types.

Each case checks the action type, and if needed it can also use the payload to update the state.

Something like:

deposit
withdraw
request loan

Based on the action type, the reducer returns the next state.

Step 3: Creating the Redux Store

Here is where Redux becomes a little different from useReducer.

In useReducer, React manages everything inside the component.

But in Redux, we need to create a central store.

This is done using the createStore function that comes from Redux.

The store holds the entire application state and uses the reducer to update it.

This is considered the classic or old Redux method, but it is still important to understand it.

For anyone learning Redux for the first time, understanding this flow is very useful.

Step 4: Dispatching Actions

Once the store is created, we can dispatch actions to update the state.

Dispatching an action sends an object that contains:

a type
sometimes a payload

The reducer receives this action and decides how the state should change.

This flow looks like this:

Action → Dispatch → Reducer → New State

A More Advanced Way

There are also more modern and advanced ways to use Redux.

For example, developers often use action creator functions to simplify dispatching actions.

These helper functions make the code cleaner and easier to manage.

However, for this blog I focused only on the basic Redux flow, because understanding the fundamentals is more important at the beginning.

My Current Learning Progress

Right now, I’m still at the stage of understanding the classic Redux structure:

initial state
reducer
store
dispatch
actions

Even though modern tools like Redux Toolkit simplify many of these steps, learning the original flow helps build a deeper understanding of how Redux works internally.

Final Thoughts

Today was the first day I actually wrote Redux code myself.

And the biggest realization was this:

Redux is not completely new.

If you already understand useReducer, Redux becomes much easier to understand because the core idea is very similar.

The main difference is that Redux moves this logic outside the component and manages state globally.

I’m still early in my Redux learning journey, but step by step the concepts are becoming clearer.

More experiments coming soon 🚀

Forem: Usama

The Hardest Phase in Development No One Talks About

The Phase That Breaks You

Why This Phase Feels So Difficult

You Can’t Learn This From Tutorials Alone

The Truth No One Tells You

My Current Approach (Still Learning)

1. Start With the Big Picture

2. Break It Into Small Pieces

3. Think Before Coding

4. Accept the Pain

Where I Stand Right Now

Final Thought

I Had to Stop Writing to Start Understanding

The Illusion of Knowing

The Real Gap: Depth

Why I’m Pausing My Blogs

A Shift in Identity

About AI and Fear

This Is Not an End

Final Thought

The Day I Finally Understood `useActionData` (React Router)

The Confusion

Let’s Break It Down (In Simple Language)

The Real Flow (Step-by-Step)

1. You create a form using React Router

2. You define an action function in your route

3. Now comes useActionData

The Key Idea (THIS is what I was missing)

Why Do We Even Need It?

Real Example (Now It Makes Sense)

What’s Actually Happening?

The Mistake I Was Making

One Line Summary (For Future Me)

When Should You Use It?

When NOT to Use It

Final Thought

Week 24: Redux Toolkit Finally Made Redux Feel Simple + Deep Dive into React Router Data Fetching

From Redux Complexity to Redux Toolkit Simplicity

The Moment Redux Toolkit Clicked

1️⃣ configureStore

2️⃣ createSlice

Middleware & Thunks — Real-World Logic

React Router — Not Just Navigation Anymore

Understanding createBrowserRouter

Data Fetching with React Router (Big Realization)

What Changed for Me This Week

Key Takeaways

Final Thoughts

I Finally Understood How to Pass Multiple Values in Redux Toolkit (The Right Way)

The Problem I Faced

The Solution: prepare Function in Redux Toolkit

What’s Happening Here?

1️⃣ prepare Handles Multiple Arguments

2️⃣ Reducer Stays Simple

3️⃣ Logic Feels More Professional

Why This Matters

My Key Takeaway

Final Thoughts

why start i use redux toolkit? why not classic redux?

The Problem With Classic Redux (From My Experience)

Then I Discovered Redux Toolkit

The Moment That Changed Everything

1️⃣ configureStore

2️⃣ createSlice

The Best Part: Cleaner Code

A Small But Important Realization

What I Learned Today

Final Thoughts

Week 23: I Finally Went Deep Into Redux (And It Started Making Sense)

From Confusion to Clarity

Understanding the Redux Store (The Brain)

Action Creator Functions (Not Just Functions)

Redux File Structure (Why It Matters)

Dispatching (The Trigger Point)

Redux Middleware (The Hidden Power)

Thunks (Handling Async Like a Pro)

Making API Calls with Redux

Redux DevTools (Game Changer)

What Changed for Me This Week

2. You define an `action` function in your route

3. Now comes `useActionData`

1️⃣ `configureStore`

2️⃣ `createSlice`

Understanding `createBrowserRouter`

The Solution: `prepare` Function in Redux Toolkit

1️⃣ `prepare` Handles Multiple Arguments

1️⃣ `configureStore`

2️⃣ `createSlice`