DEV Community: Usama

What is a Transient Prop?

Usama — Wed, 08 Jul 2026 19:23:54 +0000

A transient prop is a special prop in styled-components that starts with a dollar sign ($).

Example:

<StyledRow $columns="1fr 2fr 1fr" />

Inside the styled component:

const StyledRow = styled.div`
  grid-template-columns: ${(props) => props.$columns};
`;

The $ tells styled-components:

"This prop is only for styling. Do not pass it to the HTML element."

Why do Transient Props exist?

Sometimes we pass values only to generate CSS.

For example:

Number of grid columns
Background color
Padding
Width
Border radius
Active state

These values are needed by styled-components, but the browser's HTML elements (div, button, section, etc.) do not understand them.

Without transient props, React forwards those props to the DOM, which causes warnings like:

Warning: Unknown prop "columns" on <div>.

Transient props solve this problem by keeping styling props inside styled-components and preventing them from reaching the DOM.

Normal Prop vs Transient Prop

Normal Prop

<StyledRow columns="1fr 2fr" />

const StyledRow = styled.div`
  grid-template-columns: ${(props) => props.columns};
`;

React renders:

<div columns="1fr 2fr"></div>

Since columns is not a valid HTML attribute, React shows a warning.

Transient Prop

<StyledRow $columns="1fr 2fr" />

const StyledRow = styled.div`
  grid-template-columns: ${(props) => props.$columns};
`;

React renders:

<div></div>

The $columns prop is used only by styled-components to generate CSS and is not passed to the DOM.

Key Differences

Normal Prop	Transient Prop
`columns`	`$columns`
Passed to the DOM	Not passed to the DOM
Can trigger React warnings	Prevents React warnings
Used for component logic or data	Used only for styling

When Should You Use Transient Props?

Use transient props whenever a prop is only needed for styling.

Examples:

<Button $primary />
<Card $active />
<Box $padding="2rem" />
<Grid $columns="1fr 2fr 1fr" />

If the prop is only used to create CSS and should not become an HTML attribute, make it a transient prop by adding the $ prefix.

Summary

A transient prop is a styled-components feature that uses the $ prefix to mark styling-only props. These props are available inside the styled component but are not forwarded to the browser's HTML elements. This keeps the DOM clean, avoids React warnings, and makes your components easier to maintain.

I Almost Gave Up... But One Console Log Changed Everything

Usama — Sat, 04 Jul 2026 19:05:28 +0000

Today I spent hours chasing a bug that looked impossible.

When I clicked "Add Cabin", nothing happened.

No modal.

No error.

Nothing.

At first, I thought the problem was in my React state.

Then I thought it was styled-components.

Then I suspected PropTypes.

I kept changing code, but the bug was still there.

Instead of randomly editing files, I decided to debug step by step.

Step 1: Check if the button works

I added a simple log:

console.log("Button clicked");

The console printed:

Button clicked

Great!

That meant the click event was working.

Step 2: Check the modal state

Next, I logged my modal state.

console.log({ openName, name });

I expected to see:

openName: "cabin-form"
name: "cabin-form"

Instead, I noticed something strange.

The value became "cabin-form" for only a moment, then immediately changed back to an empty string.

That was the biggest clue.

Step 3: Ask the right question

Instead of asking,

"Why doesn't the modal open?"

I started asking,

"Who is closing the modal immediately?"

That changed everything.

Step 4: Find the real culprit

The problem wasn't React.

It wasn't the modal.

It wasn't styled-components.

It was my outside click handler.

I had this:

document.addEventListener("click", handleClickOutside);

The same click that opened the modal was also triggering the outside click listener, so the modal closed instantly.

Step 5: The fix

I changed it to:

document.addEventListener("mousedown", handleClickOutside);

And suddenly...

The modal opened perfectly.

What I learned

Today taught me a lesson I'll remember for a long time.

Debugging isn't about guessing.

It's about collecting evidence.

Every console.log() is a clue.

Every observation eliminates another possibility.

The goal isn't to write more code.

The goal is to understand what the code is actually doing.

Today I didn't just fix a modal.

I learned how experienced developers think when they debug.

And that lesson is worth much more than fixing a single bug.

Why I Started Learning React Query (TanStack Query) Today

Usama — Sat, 20 Jun 2026 11:00:21 +0000

Today I started learning something that honestly changed the way I think about React apps: React Query, now known as TanStack Query.

At first, I thought it was just another state management tool like Redux. But it’s not.
It solves a completely different problem.

And if you are building React apps, especially with APIs, this is one of those tools that quietly removes a lot of pain.

The Real Problem It Solves (What I Didn’t Understand Before)

In React apps, we usually deal with two types of state:

UI state → buttons, modals, inputs
Server state → data from APIs (users, posts, products, etc.)

Most developers (including me at first) try to manage server state using:

useState
useEffect
Redux
Context API

And it becomes messy fast.

Because server state is not simple:

It changes
It needs caching
It needs refetching
It can fail
It should sync across screens

This is where TanStack Query comes in.

What React Query Actually Is

React Query is NOT a traditional state manager.

It is a server-state manager.

It automatically handles:

Fetching data
Caching responses
Updating stale data
Background refetching
Error handling
Loading states
Retry logic

You don’t manually build all of this anymore.

Instead of writing:

loading state
error state
fetch logic
cache logic

You just declare the data you need.

The Big Idea (Simple Explanation)

Think of it like this:

Instead of you managing data manually, React Query creates a smart cache layer between your UI and API.

So your UI always asks:

“Do I already have this data?”

If yes → it gives cached data instantly
If no → it fetches it, stores it, and updates UI automatically

This is why apps feel faster.

What Makes It Powerful

Here’s what impressed me the most:

1. Caching (Automatic Memory)

Once data is fetched:

it is stored in cache
reused instantly next time
no unnecessary API calls

2. Background Refetching

Even if data is shown from cache:

it silently updates in background
UI stays fresh without flickering

3. Auto Loading & Error States

You don’t manually write:

loading
setLoading
try/catch

It gives you:

isLoading
isError
error

4. Refetching Smartly

It can refetch when:

window refocuses
network reconnects
time interval passes

5. Prefetching

You can load data before user even clicks:

Example:

user hovers button → data already loaded

That feels like “instant app speed”.

6. Offline Support

Even when internet is weak:

cached data still shows
UI doesn’t break instantly

A Small Mental Shift I Had

Before:

“I need to manage API data manually”

Now:

“I just describe what data I need”

That shift is huge.

Simple Example (How It Feels in Code)

Instead of writing complex useEffect, now it looks like:

const { data, isLoading, error } = useQuery({
  queryKey: ['users'],
  queryFn: fetchUsers
});

That’s it.

No loading state. No manual caching. No extra logic.

Alternatives You Should Know

React Query is not the only solution. Here are other tools in the ecosystem:

1. Redux Toolkit

Redux Toolkit
Good for:

global UI state
complex app logic

But not great for server-state by default.

2. RTK Query

Part of Redux Toolkit
It actually competes directly with React Query.

Good for:

API data handling inside Redux ecosystem

3. SWR

SWR
Simple alternative to React Query:

lightweight
easy caching
less features than TanStack Query

4. Apollo Client (GraphQL)

Apollo Client
Best for:

GraphQL APIs
complex data graphs

5. AWS Amplify (Backend approach)

Amazon Web Services
Not just state management, but full backend solution:

auth
APIs
storage

But it’s heavier and not just frontend state handling.

When You Should Use React Query

Use it when:

you work with REST APIs
you want fast UI experience
you want less boilerplate
you care about caching & performance

Don’t use it for:

simple static apps
only UI state (useState is enough)

Why I Think This Is Important for Developers

Modern frontend is not just UI anymore.

It’s about:

performance
caching strategy
data synchronization
user experience speed

React Query handles all of this behind the scenes.

And that’s why it feels like a “missing layer” in React.

Final Thought (From My Learning Today)

I’m currently learning React seriously, especially through courses by Jonas Schmedtmann.

And one thing I’m realizing is:

Writing less code is not the goal.
Writing smarter systems is.

React Query is exactly that kind of tool.

It removes repetitive work so you can focus on building real features.

If I had to summarize it:

React Query is not just a library.
It’s a mindset shift in how you handle data in React.

What is Tailwind CSS?

Usama — Sun, 10 May 2026 19:50:13 +0000

Tailwind CSS is a utility-first CSS framework.

It gives us ready-made utility classes like:

flex
text-center
p-4
rotate-90

We use these classes directly inside HTML or JSX to build designs quickly.

Instead of writing custom CSS again and again, Tailwind already provides hundreds of small reusable classes.

What does “Utility-First” mean?

A utility class does one small job only.

Example:

w-12 → sets width
h-12 → sets height
text-center → centers text
flex → makes flexbox layout

We combine many small classes together to create complete layouts and designs.

Easy Way to Remember

Think like this:

Normal CSS

You write your own CSS:

.box {
  width: 48px;
  height: 48px;
  display: flex;
}

Tailwind CSS

You use ready-made classes:

<div class="w-12 h-12 flex"></div>

So Tailwind means:

“Don’t write CSS from scratch. Use small ready-made classes.”

One-Line Memory Trick

Tailwind CSS = Small ready-made classes combined together to build any design quickly.

How Tailwind Utility Classes Work

In Tailwind CSS, classes like:

w-12
h-12
flex
text-center

already have CSS written behind the scenes.

Example:

.w-12 {
  width: 3rem;
}

.h-12 {
  height: 3rem;
}

Important Part

If you use w-12 100 times in your project:

<div class="w-12"></div>
<button class="w-12"></button>
<section class="w-12"></section>

Tailwind does NOT create the CSS 100 times.

The CSS rule for .w-12 is written only once.

Then every element simply reuses that same class.

So What Is the Benefit?

Instead of writing this again and again:

.card {
  width: 3rem;
}

.button {
  width: 3rem;
}

.box {
  width: 3rem;
}

Tailwind gives one reusable utility:

.w-12 {
  width: 3rem;
}

and everything shares it.

Easy Understanding

Think of utility classes like LEGO pieces.

You do not create a new LEGO block every time.

You reuse the same block in many places.

Tailwind utilities work the same way.

Final Simple Definition

Utility-first CSS means using small reusable classes that already contain one CSS property, and reusing them everywhere instead of writing new CSS repeatedly.

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.

DEV Community: Usama

What is a Transient Prop?

Why do Transient Props exist?

Normal Prop vs Transient Prop

Normal Prop

Transient Prop

Key Differences

When Should You Use Transient Props?

Summary

I Almost Gave Up... But One Console Log Changed Everything

Step 1: Check if the button works

Step 2: Check the modal state

Step 3: Ask the right question

Step 4: Find the real culprit

Step 5: The fix

What I learned

Why I Started Learning React Query (TanStack Query) Today

The Real Problem It Solves (What I Didn’t Understand Before)

What React Query Actually Is

The Big Idea (Simple Explanation)

What Makes It Powerful

1. Caching (Automatic Memory)

2. Background Refetching

3. Auto Loading & Error States

4. Refetching Smartly

5. Prefetching

6. Offline Support

A Small Mental Shift I Had

Simple Example (How It Feels in Code)

Alternatives You Should Know

1. Redux Toolkit

2. RTK Query

3. SWR

4. Apollo Client (GraphQL)

5. AWS Amplify (Backend approach)

When You Should Use React Query

Why I Think This Is Important for Developers

Final Thought (From My Learning Today)

What is Tailwind CSS?

What does “Utility-First” mean?

Easy Way to Remember

Normal CSS

Tailwind CSS

One-Line Memory Trick

How Tailwind Utility Classes Work

Important Part

So What Is the Benefit?

Easy Understanding

Final Simple Definition

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?

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`