Forem: Mohamad Msalme

React Concurrent Mode Deep Dive - Complete Series, (You Do Not Know React Yet)

Mohamad Msalme — Tue, 30 Sep 2025 21:56:06 +0000

Know WHY — Let AI Handle the HOW 🤖

A three-part series that takes you from surface-level understanding to deep architectural insights into React's concurrent features.

🎯 What You'll Learn

This isn't another tutorial on "how to use hooks." This series reveals the WHY behind React's concurrent rendering - the architectural decisions, low-level mechanisms, and mental models that transform how you build React applications.

📚 The Series

Part 1: React Concurrent Mode Isn't Magic - It's Just Really Smart Priorities

The Foundation: Understanding Priority-Based Rendering

Learn the core mental model that makes everything else click:

Why React treats updates with different urgency levels
The critical insight: "It's about the VALUE, not the component"
How useDeferredValue tells React which work can wait
Real-world search and dashboard examples with exact timelines

Key Takeaway: React doesn't detect slow components - YOU assign priorities by choosing which values to defer.

Read Part 1 →

Part 2: React's Fiber Architecture - The Secret Behind Interruptible Rendering

The Implementation: How React Actually Pauses Work

Dive into the low-level architecture that makes concurrent rendering possible:

What is a Fiber and why linked lists matter
The brilliant double buffering system (current + work-in-progress trees)
Priority lanes explained with binary operations
Render phase (interruptible) vs Commit phase (atomic)

Key Takeaway: React maintains two complete trees and can throw away work-in-progress without affecting what's on screen.

Read Part 2 →

Part 3: Time Slicing in React - How Your UI Stays Butter Smooth

The Execution: The 5ms Frame Budget Secret

Understand exactly when and why React pauses:

The 60fps problem and frame budgets
React's 5ms time slice rule
Frame-by-frame breakdown with millisecond precision
Suspense integration with concurrent features

Key Takeaway: React works in 5ms chunks, yielding to the browser after each chunk to maintain 60fps and responsive UI.

Read Part 3 →

🎓 Who This Series Is For

You'll get the most value if you:

✅ Know basic React (hooks, components, state)
✅ Want to understand the "why" behind React's design
✅ Are curious about performance optimization
✅ Want to build truly responsive UIs
✅ Like deep technical explanations with analogies

This series is NOT for you if:

❌ You just want a quick "how-to" tutorial
❌ You're brand new to React
❌ You prefer surface-level explanations

💡 Why This Series Is Different

Most tutorials teach you:

"Use useDeferredValue for expensive updates"
"Use useTransition for navigation"
Here's the API, good luck!

This series teaches you:

WHY React needs concurrent features
HOW the architecture enables interruptible rendering
WHEN React actually pauses and resumes work
WHAT happens at the millisecond level

Understanding the "why" transforms you from someone who uses React to someone who thinks in React.

🚀 Apply What You Learn

After completing this series, you'll be able to:

Diagnose Performance Issues
- Understand why your UI feels laggy
- Know which concurrent feature to use
- Think in terms of priority lanes and fiber trees
Build Better UIs
- Create truly responsive search experiences
- Handle tab switching without freezing
- Keep animations smooth during heavy work
Debug with Confidence
- Understand exactly when components re-render
- Know why some updates feel instant and others don't
- Trace through fiber trees mentally
Make Architectural Decisions
- Choose between useDeferredValue and useTransition
- Understand the trade-offs of concurrent features
- Design data flows with priorities in mind

📖 Recommended Reading Order

Start with Part 1 - Get the core mental model right
Then Part 2 - Understand the implementation details
Finish with Part 3 - See the complete picture with precise timing

Each post builds on the previous one, but can also stand alone if you're already familiar with some concepts.

🎯 More in This "Know WHY" Series

If you enjoyed this deep dive, check out my other posts that explain the "why" behind React patterns:

Remember: Know the WHY behind React's design decisions, and the HOW becomes a natural extension of that understanding.

Time Slicing in React - How Your UI Stays Butter Smooth (The Frame Budget Secret)

Mohamad Msalme — Tue, 30 Sep 2025 21:49:46 +0000

Know WHY — Let AI Handle the HOW 🤖

In Part 1, we learned about priority-based rendering. In Part 2, we explored Fiber architecture. But here's the final piece of the puzzle: How does React know WHEN to pause?

What if I told you React gives itself a strict 5ms budget per frame, and understanding this timing mechanism is the key to building silky-smooth user interfaces?

🤔 The 60 FPS Problem

Your screen refreshes 60 times per second. That gives you 16.67ms per frame to do everything:

One Frame (16.67ms):
├─ JavaScript execution (React rendering)
├─ Style calculations
├─ Layout
├─ Paint
└─ Composite

If ANY of this takes > 16.67ms:
→ Frame gets dropped
→ UI feels janky
→ User notices lag

The Challenge: How do you render expensive components without dropping frames?

🧠 Think Like a Video Game Engine for a Moment

Modern games run at 60fps by:

Doing critical work (player movement, collisions)
Checking the clock: "Do I have time left?"
If yes, do nice-to-have work (background animations)
If no, pause and continue next frame

React does the exact same thing!

function gameLoop() {
  const frameDeadline = performance.now() + 16.67;

  // Critical: Player movement
  updatePlayerPosition();

  // Check time remaining
  if (performance.now() < frameDeadline - 5) {
    // Nice-to-have: Background details
    renderDistantTrees();
  } else {
    // Out of time! Skip to next frame
    return;
  }
}

🔑 React's Frame Budget: The 5ms Rule

React follows a simple rule: Work in ~5ms chunks, then check if we should yield.

// Simplified React work loop
function workLoopConcurrent() {
  // React's frame budget strategy
  const deadline = performance.now() + 5; // 5ms time slice

  while (workInProgress !== null) {
    // Do one unit of work
    workInProgress = performUnitOfWork(workInProgress);

    // Time to check if we should pause?
    if (performance.now() >= deadline) {
      // Used our 5ms, yield to browser
      break;
    }
  }

  if (workInProgress !== null) {
    // More work to do, schedule continuation
    scheduleCallback(workLoopConcurrent);
  } else {
    // Done! Commit to DOM
    commitRoot();
  }
}

Why 5ms?

16.67ms per frame
-5ms for React work
= 11.67ms left for browser (layout, paint, user input)
Keeps UI at 60fps ✅

🎯 The shouldYield Check

This is where the magic happens:

function shouldYield() {
  const currentTime = performance.now();

  // Have we used our time slice?
  if (currentTime >= deadline) {
    return true; // Pause!
  }

  // Is there urgent work waiting?
  if (hasUrgentWork()) {
    return true; // Pause and handle urgent work!
  }

  // Keep going
  return false;
}

// Used in the render loop:
while (workInProgress && !shouldYield()) {
  workInProgress = performUnitOfWork(workInProgress);
}

💡 Real Example: Typing in Search Box

Let's see EXACTLY what happens with millisecond precision:

function SearchPage() {
  const [query, setQuery] = useState('');
  const deferredQuery = useDeferredValue(query);

  const results = useMemo(() => {
    console.log('Filtering for:', deferredQuery);
    // Let's say this takes 50ms total
    return expensiveFilter(bigDataset, deferredQuery);
  }, [deferredQuery]);

  return (
    <div>
      <input 
        value={query}
        onChange={e => setQuery(e.target.value)}
      />
      <ResultsList items={results} />
    </div>
  );
}

Frame-by-frame breakdown when you type "r":

Frame 1 (0-16ms):
├─ 0ms:   User types "r" (keypress event)
├─ 1ms:   query = "r" (HIGH PRIORITY state update)
├─ 2ms:   React starts render phase
│         → <input> fiber (SyncLane priority)
├─ 3ms:   Commit phase: Update DOM
├─ 4ms:   Input shows "r" on screen ✅
│         User sees immediate feedback!
├─ 5ms:   deferredQuery = "" (still old value)
├─ 6ms:   Start LOW PRIORITY render
│         → ResultsList fiber (TransitionLane)
│         → Start expensiveFilter("")
├─ 7ms:   Filter chunk 1/10 complete
├─ 8ms:   Filter chunk 2/10 complete
├─ 9ms:   Filter chunk 3/10 complete
├─ 10ms:  Filter chunk 4/10 complete
├─ 11ms:  shouldYield() = true (used 5ms slice)
└─ 12ms:  PAUSE! Save progress, yield to browser
          Browser uses remaining 4ms for:
          - Handling any input
          - Painting the input change
          - Smooth scrolling

Frame 2 (16-32ms):
├─ 16ms:  Resume LOW PRIORITY render
├─ 17ms:  Filter chunk 5/10 complete
├─ 18ms:  Filter chunk 6/10 complete
├─ 19ms:  Filter chunk 7/10 complete
├─ 20ms:  Filter chunk 8/10 complete
├─ 21ms:  shouldYield() = true
└─ 22ms:  PAUSE again

Frame 3 (32-48ms):
├─ 32ms:  Resume LOW PRIORITY render
├─ 33ms:  Filter chunk 9/10 complete
├─ 34ms:  Filter chunk 10/10 complete ✅
├─ 35ms:  Commit phase: Update DOM
└─ 36ms:  Results appear on screen!

The key: Input felt instant (4ms), while expensive work happened in background across 3 frames!

⚡ Interruption in Action

Now let's see what happens when you keep typing:

Frame 1 (0-16ms):
├─ 0ms:   Type "r"
├─ 1ms:   query = "r"
├─ 4ms:   Input shows "r" ✅
├─ 6ms:   Start filtering "" → "r" (LOW PRIORITY)
├─ 11ms:  shouldYield() = true, PAUSE
└─ 12ms:  Browser gets control back

Frame 2 (16-32ms):
├─ 16ms:  Resume filtering for "r"
├─ 20ms:  25% done with filter...
├─ 21ms:  shouldYield() checks for urgent work
│
├─ 22ms:  ⚡ User types "e" (HIGH PRIORITY!)
│         shouldYield() = true (urgent work detected!)
│
├─ 23ms:  ABANDON current render
│         Throw away partial "r" filter work
│
├─ 24ms:  query = "re" (HIGH PRIORITY)
├─ 25ms:  Input shows "re" ✅
├─ 26ms:  deferredQuery updates to "r"
│         (but immediately cancelled by "re")
│
├─ 27ms:  Start NEW filtering "r" → "re"
└─ 28ms:  shouldYield() = true, PAUSE

// Old "r" filter NEVER completes or shows!
// React intelligently skipped that intermediate state

🔄 The Scheduler API

React uses the browser's Scheduler API (with polyfill):

// Modern browsers (Chrome, Edge)
scheduler.postTask(() => {
  workLoopConcurrent();
}, { priority: 'background' });

// Fallback: MessageChannel for time slicing
const channel = new MessageChannel();
channel.port1.onmessage = () => {
  workLoopConcurrent();
};

function scheduleCallback(callback) {
  channel.port2.postMessage(null);
}

Why MessageChannel?

setTimeout(fn, 0) has 4ms minimum delay (too slow!)
requestAnimationFrame only runs before paint (wrong timing)
MessageChannel runs immediately after current task (perfect!)

🎯 Complete Real-World Example: Dashboard

function Dashboard() {
  const [metric, setMetric] = useState('revenue');
  const [isPending, startTransition] = useTransition();

  const switchMetric = (newMetric) => {
    startTransition(() => {
      setMetric(newMetric);
    });
  };

  return (
    <div>
      <Tabs selected={metric} onChange={switchMetric} />
      {isPending && <LoadingBar />}
      <ExpensiveChart metric={metric} />
    </div>
  );
}

function ExpensiveChart({ metric }) {
  const chartData = useMemo(() => {
    // This takes 80ms to compute
    const data = [];
    for (let i = 0; i < 10000; i++) {
      data.push({
        x: i,
        y: complexCalculation(metric, i)
      });
    }
    return data;
  }, [metric]);

  return <ChartLibrary data={chartData} />;
}

Frame timeline when switching from "Revenue" to "Profit":

Frame 1 (0-16ms):
├─ 0ms:   User clicks "Profit" tab
├─ 1ms:   metric = "profit" (TRANSITION priority)
├─ 2ms:   Tab switches to "Profit" ✅
├─ 3ms:   isPending = true
├─ 4ms:   LoadingBar appears ✅
│         User sees immediate feedback!
├─ 5ms:   Start chart re-render (LOW PRIORITY)
│         Calculate data point 0
├─ 6ms:   Calculate data point 1
├─ 7ms:   Calculate data point 2
│         ... (calculating in loop)
├─ 10ms:  Calculate data point 500
├─ 11ms:  shouldYield() = true
└─ 12ms:  PAUSE (used 5ms slice)
          Progress saved: at data point 500

Frame 2 (16-32ms):
├─ 16ms:  Resume chart calculation
├─ 17ms:  Calculate data point 501
├─ 18ms:  Calculate data point 502
│         ... (calculating in loop)
├─ 21ms:  Calculate data point 1000
├─ 22ms:  shouldYield() = true
└─ 23ms:  PAUSE again
          Progress saved: at data point 1000

// This continues across ~16 frames (80ms / 5ms per frame)

Frame 16 (240-256ms):
├─ 240ms: Resume chart calculation
├─ 241ms: Calculate data point 9998
├─ 242ms: Calculate data point 9999
├─ 243ms: All calculations complete! ✅
├─ 244ms: Commit phase: Update DOM
├─ 245ms: New chart renders
├─ 246ms: isPending = false
└─ 247ms: LoadingBar disappears

Total time: 247ms
But UI stayed responsive the entire time! 🎉

🏠 The Perfect Analogy: Restaurant Kitchen

Think of React's time slicing like a restaurant kitchen:

Without Time Slicing (Old React):

Chef starts making a complex dish
New urgent order comes in (appetizer)
Chef: "Sorry, I have to finish this entrée first"
Customer waits 20 minutes for a simple appetizer 😡

With Time Slicing (Concurrent React):

Chef starts making complex entrée (5 min work)
After 30 seconds, checks: "Any urgent orders?"
Urgent appetizer comes in!
Chef: "Let me pause the entrée"
Makes appetizer immediately (2 min)
Returns to entrée
Both customers happy! 😊

🧪 Suspense with Time Slicing

Time slicing makes Suspense for data fetching smooth:

function ProfilePage({ userId }) {
  const [isPending, startTransition] = useTransition();

  const switchUser = (newId) => {
    startTransition(() => {
      setUserId(newId);
    });
  };

  return (
    <Suspense fallback={<Skeleton />}>
      <ProfileDetails userId={userId} />
    </Suspense>
  );
}

function ProfileDetails({ userId }) {
  const user = use(fetchUser(userId)); // Suspends

  // Heavy computation after data loads
  const stats = useMemo(() => {
    return calculateComplexStats(user);
  }, [user]);

  return <ProfileView user={user} stats={stats} />;
}

Timeline when switching users:

Frame 1 (0-16ms):
├─ 0ms:   Click "Switch User"
├─ 1ms:   userId = 2 (TRANSITION priority)
├─ 2ms:   Start render ProfileDetails
├─ 3ms:   Suspend! (waiting for data)
├─ 4ms:   Old profile STAYS VISIBLE (smooth!)
└─ 5ms:   Inline spinner shows

... Network request in flight ...

Frame 50 (800-816ms):
├─ 800ms: Data arrives! fetchUser(2) resolves
├─ 801ms: Resume ProfileDetails render
├─ 802ms: Start calculateComplexStats (expensive!)
├─ 807ms: shouldYield() = true
└─ 808ms: PAUSE calculation

Frame 51 (816-832ms):
├─ 816ms: Resume calculateComplexStats
├─ 821ms: Calculation complete!
├─ 822ms: Commit phase
└─ 823ms: New profile smoothly appears ✅

No jarring skeleton screen!
Old content stayed visible during load!

🎯 Performance Monitoring

You can actually see time slicing in action:

function ExpensiveComponent({ data }) {
  // Log when rendering starts/pauses
  console.log('Render start:', performance.now());

  const result = useMemo(() => {
    const start = performance.now();
    const computed = expensiveComputation(data);
    const end = performance.now();
    console.log(`Computation took: ${end - start}ms`);
    return computed;
  }, [data]);

  console.log('Render end:', performance.now());
  return <div>{result}</div>;
}

// Console output:
// Render start: 0.5ms
// Render end: 1.2ms (fiber created)
// (pause - browser handles other work)
// Computation took: 50ms (spread across 10 frames!)
// (pause - browser handles other work)
// Render start: 52ms (commit phase)
// Render end: 53ms

🧠 The Mental Model Shift

Stop Thinking:

"React renders everything at once"
"Long computations always block the UI"
"I need to manually split work with setTimeout"

Start Thinking:

"React renders in 5ms chunks"
"Long work is automatically split across frames"
"Browser gets control back between chunks"
"UI stays responsive even during heavy work"

💭 The Takeaway

Many developers learn the HOW: "Use useDeferredValue and it makes things faster."

When you understand the WHY: "React works in 5ms time slices, yielding control back to the browser after each slice to maintain 60fps, and can pause/resume work at any fiber node," you gain insights that help you:

Understand why some operations feel instant
Know when concurrent features actually help
Debug performance with precise timing knowledge
Build UIs that feel professional and responsive

React's Fiber Architecture - The Secret Behind Interruptible Rendering (And Why It's Brilliant)

Mohamad Msalme — Tue, 30 Sep 2025 21:39:42 +0000

Know WHY — Let AI Handle the HOW 🤖

In Part 1, we learned how React prioritizes updates using useDeferredValue. But here's the question that should be bugging you: How does React actually pause rendering mid-way and resume later?

What if I told you it's not magic - it's actually a clever data structure called Fiber that transforms your component tree into something React can pause, resume, and even throw away? Understanding this changes how you think about React performance forever.

🤔 The Problem React Had to Solve

Before we get to Fibers, let's understand the problem:

function App() {
  return (
    <div>
      <Header />
      <MainContent>
        <Article />
        <Sidebar>
          <Widget1 />
          <Widget2 />
          <Widget3 />
        </Sidebar>
      </MainContent>
      <Footer />
    </div>
  );
}

Old React (before Fiber):

Renders from top to bottom recursively
Once started, MUST finish the entire tree
No way to pause halfway through
If user clicks during render, too bad - they wait

The Challenge: How do you make rendering interruptible without breaking everything?

🧠 Think Like a Book Reader for a Moment

Imagine you're reading a book:

Without Bookmarks (Old React):

Start chapter 1
Must read straight through to the end
Can't stop mid-sentence
Can't remember where you were if interrupted

With Bookmarks (Fiber Architecture):

Start chapter 1
Can place a bookmark on any page
Stop reading when something urgent comes up
Resume exactly where you left off
Can even decide "this chapter isn't relevant anymore" and skip it

That's exactly what Fiber does for React rendering.

🔑 What Is a Fiber? The Unit of Work

A Fiber is a JavaScript object that represents one unit of work in React. Each React element becomes a Fiber node.

// Your JSX
<DisplayCounter count={5} />

// Becomes a Fiber object (simplified):
{
  // Identity
  type: DisplayCounter,        // Component function/class
  key: null,                   // React key

  // Tree structure (linked list!)
  return: parentFiber,         // Parent (going up)
  child: firstChildFiber,      // First child (going down)
  sibling: nextSiblingFiber,   // Next sibling (going across)

  // Props and State
  pendingProps: { count: 6 },  // New props to apply
  memoizedProps: { count: 5 }, // Current props
  memoizedState: null,         // Current state

  // THE KEY TO CONCURRENT MODE!
  lanes: 0b0001,              // Priority (binary flag)
  childLanes: 0b0011,         // Children's priorities

  // Effects (what needs to happen)
  flags: Update,              // Bitwise flags

  // Double buffering
  alternate: otherVersionOfThisFiber
}

Why Linked List Instead of Array?

Array (Old React):

const tree = [
  { type: 'div', children: [
    { type: Header },
    { type: MainContent, children: [...] }
  ]}
];

// Problem: Can't easily pause mid-traversal
// Would need complex index tracking

Linked List (Fiber):

const fiber = {
  type: 'div',
  child: headerFiber,  // ← Can pause here
};

const headerFiber = {
  type: Header,
  return: fiber,       // ← Know where we came from
  sibling: mainFiber,  // ← Know where to go next
};

// Can pause at any fiber and resume later!

💡 The Brilliant Part: Double Buffering

React maintains TWO complete fiber trees at all times:

Current Tree - What's displayed on screen right now
Work-in-Progress Tree - What React is building

// Current tree (what user sees)
const currentTree = {
  type: App,
  child: {
    type: 'div',
    child: {
      type: DisplayCounter,
      props: { count: 5 },
      alternate: wipFiber  // ← Points to work-in-progress version
    }
  }
};

// Work-in-progress tree (what React is building)
const workInProgressTree = {
  type: App,
  child: {
    type: 'div',
    child: {
      type: DisplayCounter,
      props: { count: 6 },  // ← New count!
      alternate: currentFiber  // ← Points back to current
    }
  }
};

Why This Is Genius:

// React can work on work-in-progress tree
// User still sees current tree (stable UI)

// If interrupted by urgent update:
// → Just throw away work-in-progress tree
// → Start fresh with new priorities
// → No harm done!

// When rendering completes:
// → Swap pointers in ONE atomic operation
// → current = workInProgress
// → workInProgress = current

Real Example: Updating a Counter

function App() {
  const [count, setCount] = useState(5);
  const deferredCount = useDeferredValue(count);

  return (
    <div>
      <DisplayCounter count={count} />         {/* Fiber A */}
      <ExpensiveList count={deferredCount} />  {/* Fiber B */}
    </div>
  );
}

After user clicks (count becomes 6):

// CURRENT TREE (still visible on screen)
Fiber A: {
  type: DisplayCounter,
  props: { count: 5 },  // Old value
  lanes: 0b0000,
}

Fiber B: {
  type: ExpensiveList,
  props: { count: 5 },  // Old value
  lanes: 0b0000,
}

// WORK-IN-PROGRESS TREE (being built)
Fiber A (WIP): {
  type: DisplayCounter,
  props: { count: 6 },     // New value!
  lanes: 0b0001,           // SyncLane - HIGH PRIORITY
  alternate: currentFiberA // Points to current tree
}

Fiber B (WIP): {
  type: ExpensiveList,
  props: { count: 5 },     // Still old (deferred!)
  lanes: 0b1000,           // TransitionLane - LOW PRIORITY
  alternate: currentFiberB
}

🎯 Priority Lanes: How React Tracks Urgency

React uses binary flags for lightning-fast priority checks.

// Priority lanes (actual React source - simplified)
const SyncLane            = 0b0000000000000000000000000000001; // Highest
const InputContinuousLane = 0b0000000000000000000000000000100;
const DefaultLane         = 0b0000000000000000000000000010000;
const TransitionLane      = 0b0000000000000000000001000000000; // Low priority
const IdleLane            = 0b0100000000000000000000000000000; // Lowest

// Why binary? Super fast operations:
const hasUrgentWork = (lanes & SyncLane) !== 0;  // Single CPU instruction!
const combinedWork = lanes1 | lanes2;            // Merge priorities instantly

How useDeferredValue Sets Lanes

function App() {
  const [count, setCount] = useState(0);
  const deferredCount = useDeferredValue(count);

  // When count updates:
  // 1. Components using `count` get SyncLane (0b0001)
  // 2. Components using `deferredCount` get TransitionLane (0b1000)
}

Internal priority assignment:

// Simplified React internals
function scheduleUpdate(fiber, newValue, isDeferred) {
  if (isDeferred) {
    // LOW PRIORITY - can be interrupted
    fiber.lanes = TransitionLane;
    fiber.pendingProps = newValue;
  } else {
    // HIGH PRIORITY - process immediately
    fiber.lanes = SyncLane;
    fiber.pendingProps = newValue;
  }

  // Bubble priority up to root
  let parent = fiber.return;
  while (parent) {
    parent.childLanes |= fiber.lanes;  // Bitwise OR combines lanes
    parent = parent.return;
  }
}

🔄 The Two Phases of Rendering

React's work is split into two distinct phases:

Phase 1: Render Phase (Interruptible ✅)

This is where React can pause.

function workLoopConcurrent() {
  // THE KEY: This loop can be interrupted!
  while (workInProgress !== null && !shouldYield()) {
    performUnitOfWork(workInProgress);
  }

  // If shouldYield() returns true, we pause here
  // workInProgress remembers where we stopped
  // We can resume later from this exact fiber!
}

function performUnitOfWork(fiber) {
  // Step 1: Call the component
  const children = fiber.type(fiber.props);

  // Step 2: Reconcile (diff) children
  reconcileChildren(fiber, children);

  // Step 3: Return next unit of work
  if (fiber.child) return fiber.child;      // Go down
  if (fiber.sibling) return fiber.sibling;  // Go across
  return fiber.return;                      // Go up
}

Example: Rendering Pauses Mid-Tree

<App>
  <Header />              {/* ✅ Rendered */}
  <MainContent>
    <Article />           {/* ✅ Rendered */}
    <Sidebar>
      <Widget1 />         {/* ✅ Rendered */}
      <Widget2 />         {/* ⏸️ PAUSE HERE - shouldYield() = true */}
      <Widget3 />         {/* ⏳ Not rendered yet */}
    </Sidebar>
  </MainContent>
  <Footer />              {/* ⏳ Not rendered yet */}
</App>

// React: "Used my 5ms time slice, better let browser handle user input"
// workInProgress = Widget2Fiber
// Can resume from here later!

Key Characteristics:

✅ No DOM mutations yet
✅ Can pause at any fiber
✅ Can resume where left off
✅ Can throw away all work if urgent update arrives
✅ Pure computations only

Phase 2: Commit Phase (Uninterruptible ❌)

Once render phase completes, React commits changes atomically.

function commitRoot(root) {
  const finishedWork = root.finishedWork;

  // THIS PHASE CANNOT BE INTERRUPTED!
  // Must complete to avoid inconsistent UI

  // Sub-phase 1: Before mutation
  commitBeforeMutationEffects(finishedWork);
  // → Calls getSnapshotBeforeUpdate
  // → Schedules useEffect

  // Sub-phase 2: Mutation (THE CRITICAL MOMENT)
  commitMutationEffects(finishedWork);
  // → Actual DOM updates happen here
  // → All at once, atomically

  // Sub-phase 3: Switch trees (ATOMIC SWAP)
  root.current = finishedWork;
  // ↑ NOW the new tree is visible!

  // Sub-phase 4: Layout effects
  commitLayoutEffects(finishedWork);
  // → Calls useLayoutEffect
  // → Calls componentDidMount/Update
}

Why Must Commit Be Uninterruptible?

// Imagine if commit could pause mid-way:
function UserProfile() {
  return (
    <div>
      <Avatar src={user.avatar} />
      <Name>{user.name}</Name>
      <Email>{user.email}</Email>
    </div>
  );
}

// If paused after Avatar but before Name/Email:
// DOM shows:
//   Avatar for User B
//   Name for User A  ← INCONSISTENT!
//   Email for User A ← INCONSISTENT!
// 
// Users would see mixed data! 😱

🎯 Real-World Example: Search with Interruption

function SearchPage() {
  const [query, setQuery] = useState('');
  const deferredQuery = useDeferredValue(query);

  const results = useMemo(() => {
    // Expensive filtering
    return bigDataset.filter(item => 
      item.name.includes(deferredQuery)
    );
  }, [deferredQuery]);

  return (
    <div>
      <input value={query} onChange={e => setQuery(e.target.value)} />
      <ResultsList items={results} />
    </div>
  );
}

What happens internally when you type "react":

User types "r":
0ms:  query = "r"
1ms:  RENDER PHASE (HIGH PRIORITY)
      → Input fiber: lanes = SyncLane
      → Render <input value="r" /> ✅
2ms:  COMMIT PHASE
      → Update DOM, input shows "r" ✅
3ms:  RENDER PHASE (LOW PRIORITY)
      → ResultsList fiber: lanes = TransitionLane
      → Start filtering for "r"
      → ResultsList fiber #1 rendering...
      → ResultsList fiber #2 rendering...

10ms: User types "e" (NEW HIGH PRIORITY UPDATE!)
11ms: shouldYield() = true (time to check for urgent work)
12ms: React finds SyncLane work waiting
13ms: ABANDON work-in-progress tree (throw it away!)
14ms: RENDER PHASE (HIGH PRIORITY)
      → Input fiber: lanes = SyncLane
      → Render <input value="re" /> ✅
15ms: COMMIT PHASE
      → Update DOM, input shows "re" ✅
16ms: RENDER PHASE (LOW PRIORITY)
      → ResultsList: START NEW render for "re"
      → Old "r" filter abandoned, never committed!

The user never sees results for "r" - React intelligently skipped that intermediate state!

🏠 The Perfect Analogy: Construction Site with Blueprints

Think of React's Fiber system like a construction site:

Current Tree = The actual building people are using
Work-in-Progress Tree = Blueprint and temporary scaffolding

Workers can modify the blueprint/scaffolding all day
People in the building don't see any changes (stable!)
If plans change, just throw away the scaffolding
When blueprint is done, do the final construction (commit phase)
Switch happens all at once - no half-renovated rooms

🧠 The Mental Model Shift

Stop Thinking:

"React renders top to bottom"
"Once rendering starts, it must finish"
"State updates are immediate"

Start Thinking:

"React renders fiber by fiber (unit by unit)"
"React can pause between any two fibers"
"React builds a new tree in the background"
"Priorities determine which fibers render first"
"Only commit phase makes changes visible"

💭 The Takeaway

Many developers learn the HOW: "Use React hooks and it works."

When you understand the WHY: "React uses Fiber nodes in a linked list structure with priority lanes, enabling interruptible rendering through double buffering," you gain insights that help you:

Understand why some updates feel instant and others don't
Know when to use useDeferredValue vs useTransition
Debug performance issues by thinking about fiber priorities
Make better architectural decisions

React Concurrent Mode Isn't Magic - It's Just Really Smart Priorities (And This Changes Everything)

Mohamad Msalme — Tue, 30 Sep 2025 21:18:58 +0000

Know WHY — Let AI Handle the HOW 🤖

Ever wonder why your React app feels sluggish when you type in a search box? Or why clicking a tab freezes the UI for a second? You're probably thinking "I need to optimize my components" or "I should debounce everything."

What if I told you the real problem isn't your code - it's that React is treating all updates with the same urgency, and there's a simple mental model shift that makes everything feel instantly responsive?

🤔 Let's Start With The Problem Everyone Has

You're building a search feature. Simple, right?

function SearchPage() {
  const [searchTerm, setSearchTerm] = useState('');

  // Heavy filtering of 10,000 items
  const results = useMemo(() => {
    return bigDataset.filter(item => 
      item.name.toLowerCase().includes(searchTerm.toLowerCase())
    );
  }, [searchTerm]);

  return (
    <div>
      <input 
        value={searchTerm}
        onChange={e => setSearchTerm(e.target.value)}
      />
      <ResultsList items={results} />
    </div>
  );
}

The Problem: You type "react" and the input feels laggy. Each keystroke triggers expensive filtering, blocking the UI.

You think: "I should debounce this!"

But what if there's a better way that doesn't require manually managing timers?

🧠 Think Like a Hospital Emergency Room for a Moment

Imagine you're running an ER. Two patients arrive:

Patient A: Broken finger (painful but not urgent)
Patient B: Heart attack (URGENT!)

You don't treat them in order of arrival. You prioritize based on urgency.

That's exactly what React Concurrent Mode does with updates.

Before Concurrent Mode, React was like treating patients strictly in arrival order - no matter how urgent. With Concurrent Mode, React can:

Recognize which updates are urgent (user typing)
Which updates can wait (expensive filtering)
Interrupt low-priority work if something urgent arrives

🔑 The Mental Model That Changes Everything

Here's the insight most developers miss:

React doesn't magically detect "slow" components. YOU tell React which updates can be deferred.

import { useDeferredValue } from 'react';

function SearchPage() {
  const [searchTerm, setSearchTerm] = useState('');
  const deferredSearchTerm = useDeferredValue(searchTerm);

  const results = useMemo(() => {
    console.log('Filtering for:', deferredSearchTerm);
    return bigDataset.filter(item => 
      item.name.toLowerCase().includes(deferredSearchTerm.toLowerCase())
    );
  }, [deferredSearchTerm]);

  return (
    <div>
      <input 
        value={searchTerm}
        onChange={e => setSearchTerm(e.target.value)}
      />
      <p>Searching for: {searchTerm}</p>
      <ResultsList items={results} />
    </div>
  );
}

What just happened?

searchTerm updates immediately when you type (HIGH PRIORITY)
Input shows new character instantly - UI feels responsive!
deferredSearchTerm "lags behind" - updates later (LOW PRIORITY)
Expensive filtering uses the deferred value
React can interrupt filtering if you keep typing

Console output when you type "react" quickly:

// Without useDeferredValue:
Filtering for: r
Filtering for: re  
Filtering for: rea
Filtering for: reac
Filtering for: react
// 5 expensive operations! UI lags on every keystroke 😡

// With useDeferredValue:
Filtering for: react
// Only 1 operation after you stop typing! ✅

💡 The Critical Insight: It's About the VALUE, Not the Component

This is the part that blew my mind:

function DisplayCounter({ count }) {
  return <div>Count: {count}</div>;
}

function App() {
  const [count, setCount] = useState(0);
  const deferredCount = useDeferredValue(count);

  return (
    <div>
      <button onClick={() => setCount(count + 1)}>
        Increment
      </button>

      {/* Same component, different priorities! */}
      <DisplayCounter count={count} />         {/* HIGH PRIORITY */}
      <DisplayCounter count={deferredCount} /> {/* LOW PRIORITY */}
    </div>
  );
}

Same component rendered twice, but:

First instance uses count → renders immediately
Second instance uses deferredCount → renders later

React assigns priority based on which value the component receives, not the component itself!

🎯 Real-World Example: Auto-Complete Search

Let's see the difference in user experience:

function AutoComplete() {
  const [input, setInput] = useState('');
  const deferredInput = useDeferredValue(input);

  // Expensive: searches through 100,000 items
  const suggestions = useMemo(() => {
    return searchDatabase(deferredInput);
  }, [deferredInput]);

  return (
    <div>
      <input
        value={input}
        onChange={e => setInput(e.target.value)}
        placeholder="Type to search..."
      />

      {/* Always shows fresh input */}
      <SearchStatus query={input} />

      {/* Shows suggestions for deferred input */}
      <SuggestionsList items={suggestions} />
    </div>
  );
}

Timeline when you type "typescript":

User types: t → ty → typ → type → types → typesc → typescr → typescri → typescript

Without useDeferredValue:
0ms:   Type "t"
1ms:   input = "t"
2ms:   Start expensive search for "t"
       ... UI FREEZES 50ms ...
52ms:  Show results for "t"
53ms:  Type "y" (but you had to wait!)
       ... 9 expensive searches total! 😡

With useDeferredValue:
0ms:   Type "t"  
1ms:   input = "t" ✅
2ms:   Input shows "t" immediately!
3ms:   deferredInput still = ""
4ms:   Start search for "t" (low priority)
10ms:  Type "y"
11ms:  input = "ty" ✅
12ms:  Input shows "ty" immediately!
13ms:  React CANCELS search for "t"
14ms:  Start NEW search for "ty"
... you keep typing fast ...
500ms: You stop at "typescript"
600ms: deferredInput finally = "typescript"
650ms: ONE search completes
       ... Only 1 expensive search! ✅

Your input stays responsive because React prioritizes showing your keystrokes over computing search results.

⚡ useDeferredValue vs useTransition: When to Use What?

Both enable concurrent rendering, but for different scenarios:

useDeferredValue - Defer Expensive Renders

Use when: You have expensive computations during render that you can't control.

function DataDashboard() {
  const [filter, setFilter] = useState('all');
  const deferredFilter = useDeferredValue(filter);

  // Expensive computation during render
  const processedData = useMemo(() => {
    return heavyDataProcessing(deferredFilter);
  }, [deferredFilter]);

  return (
    <div>
      <FilterButtons current={filter} onChange={setFilter} />
      <DataTable data={processedData} />
    </div>
  );
}

useTransition - Control State Updates

Use when: You control the state update and want to mark it as non-urgent.

function TabContainer() {
  const [tab, setTab] = useState('home');
  const [isPending, startTransition] = useTransition();

  const switchTab = (newTab) => {
    startTransition(() => {
      setTab(newTab);
    });
  };

  return (
    <div>
      <button onClick={() => switchTab('profile')}>
        Profile {isPending && '⏳'}
      </button>

      {tab === 'home' && <HomeTab />}
      {tab === 'profile' && <ProfileTab />}
    </div>
  );
}

The difference:

useDeferredValue: "This value can lag behind"
useTransition: "This state update isn't urgent"

🏠 The Perfect Analogy: Email Priority Flags

Think of your React updates like emails:

const urgentUpdate = useState(value);        // 🔴 HIGH PRIORITY
const normalUpdate = useDeferredValue(value); // 🟡 LOW PRIORITY

// Components using urgentUpdate:
// → Process immediately (like urgent emails)

// Components using normalUpdate:  
// → Process when you have time (like regular emails)

When your inbox gets flooded:

Urgent emails (user input) get handled first
Regular emails (expensive renders) can wait
You don't freeze waiting to process every email in order

That's concurrent rendering!

💭 Common Misconception: "Won't This Show Stale Data?"

You might think: "If deferredValue lags behind, won't users see outdated results?"

Yes, briefly - and that's actually GOOD UX!

function SearchResults() {
  const [query, setQuery] = useState('');
  const deferredQuery = useDeferredValue(query);

  return (
    <div>
      {/* User always sees what they typed */}
      <input value={query} onChange={e => setQuery(e.target.value)} />

      {/* Visual feedback when results are updating */}
      {query !== deferredQuery && <Spinner />}

      {/* Results for deferred query */}
      <Results query={deferredQuery} />
    </div>
  );
}

Users prefer:

✅ Responsive input + brief spinner
❌ Laggy input that freezes on every keystroke

🎯 Real-World Pattern: Dashboard with Heavy Charts

function Dashboard() {
  const [metric, setMetric] = useState('revenue');
  const deferredMetric = useDeferredValue(metric);

  return (
    <div>
      {/* Tabs respond instantly */}
      <Tabs selected={metric} onChange={setMetric} />

      {/* Visual feedback */}
      {metric !== deferredMetric && <ChartSkeleton />}

      {/* Heavy chart renders with low priority */}
      <ExpensiveChart metric={deferredMetric} />
    </div>
  );
}

function ExpensiveChart({ metric }) {
  // Heavy computation during render
  const chartData = useMemo(() => {
    const data = [];
    for (let i = 0; i < 10000; i++) {
      data.push(calculateComplexDataPoint(metric, i));
    }
    return data;
  }, [metric]);

  return <ChartLibrary data={chartData} />;
}

User Experience:

User clicks "Profit" tab:

Without useDeferredValue:
0ms:   Click "Profit"
1ms:   metric = "profit"
2ms:   Start rendering ExpensiveChart
       ... UI COMPLETELY FROZEN for 800ms ...
800ms: Chart finally renders
       User frustrated, thinks app crashed 😡

With useDeferredValue:
0ms:   Click "Profit"
1ms:   metric = "profit"
2ms:   Tab switches to "Profit" immediately ✅
3ms:   User sees visual feedback (skeleton)
4ms:   deferredMetric still = "revenue"
5ms:   Start rendering new chart in background
       ... UI STAYS RESPONSIVE ...
800ms: Chart smoothly appears
       User happy, knows their click worked! 😊

🧠 The Mental Model Shift

Stop Thinking:

"I need to debounce everything"
"My components are too slow"
"I should use setTimeout to avoid blocking"

Start Thinking:

"Which updates need immediate feedback?"
"Which expensive work can wait?"
"Let React prioritize based on urgency"

💡 When to Use Concurrent Features

Use useDeferredValue when:

✅ Heavy filtering/searching while typing
✅ Expensive computations during render
✅ Large list rendering that lags input
✅ Data visualization that blocks UI

Don't use it when:

❌ Component is already fast
❌ You need synchronous updates (form validation)
❌ The "lag" would confuse users (critical UI feedback)

🎯 The Takeaway

Many developers learn the HOW: "Use useDeferredValue to defer values."

When you understand the WHY: "React prioritizes updates based on urgency, and you control priorities by choosing which values to defer," you gain a powerful tool that makes your UI feel instantly responsive without manual optimization.

Inside React Query: What’s Really Going On

Mohamad Msalme — Fri, 05 Sep 2025 20:04:08 +0000

Know WHY — Let AI Handle the HOW 🤖

React Query isn’t just hooks. It’s a data orchestration engine. Treat it like hooks, and you’ll end up with duplicate fetches, stale state, and components re-rendering like they’re on espresso.

Let’s go step by step inside React Query, show what each piece does, and why understanding it will make you a much stronger React developer.

QueryClient — The Conductor of Your Data Orchestra

1- The QueryClient isn't just a prop you pass to
QueryClientProvider.

It's the conductor of your entire data-fetching orchestra — the single source of truth that coordinates all your queries, manages the cache, and ensures everything stays in sync.

2- Why QueryClient Must Be Stable
Here's the critical insight: QueryClient holds the QueryCache instance. When you create multiple QueryClient instances, you're creating multiple, isolated caches. This breaks React Query's fundamental promise of shared state management.

// ❌ WRONG: Creates new client on every render
function App() {
// New instance every render! mean new cashe instance 
  const queryClient = new QueryClient() 

  return (
    <QueryClientProvider client={queryClient}>
      <RestOfYourApp />
    </QueryClientProvider>
  )
}

// ✅ CORRECT: Stable reference outside component
const queryClient = new QueryClient()

function App() {
  return (
    <QueryClientProvider client={queryClient}>
      <RestOfYourApp />
    </QueryClientProvider>
  )
}

// ✅ ALSO CORRECT: Stable reference with useState
function App() {
  const [queryClient] = useState(() => new QueryClient())

  return (
    <QueryClientProvider client={queryClient}>
      <RestOfYourApp />
    </QueryClientProvider>
  )
}`

QueryCache — Your In-Memory Data Warehouse

The QueryCache is React Query's in-memory data warehouse — a JavaScript object where the keys are stable serialized versions of your queryKey (called queryKeyHash) and the values are Query class instances containing your actual data.

// it is just to simplified the idea 

// The Simple Truth: It's Just an Object
// Simplified QueryCache structure
const queryCache = {
  // queryKeyHash: Query instance
  '["users",1]': QueryInstance1,
  '["posts","published"]': QueryInstance2,
  '["user",1,"profile"]': QueryInstance3,
}

// Where each Query instance contains:
class Query {
  constructor() {
    this.data = undefined        // Your actual data
    this.error = undefined       // Any errors
    this.status = 'idle'         // idle, loading, success, error
    this.dataUpdatedAt = Date.now()
    this.errorUpdatedAt = undefined
    this.staleTime = 0
    // ... more metadata
  }
}

Query — The Smart Data Manager with Selective Observers

The Query class is where all the magic happens in React Query. It's not just a data container — it's a sophisticated state machine that manages fetching, retries, cancellation, deduplication, and most importantly, knows exactly who's watching and what they care about.

The Core Insight: Selective Observer Notifications
Here's the critical concept you identified: Query knows who's subscribed and what each subscriber cares about. This enables React Query to be incredibly efficient by only notifying observers about changes they actually care about.

// Component A: Only cares about loading state
function LoadingIndicator() {
  const { isLoading } = useQuery({
    queryKey: ['user', 1],
    queryFn: fetchUser
  })

  // This component ONLY gets notified when isLoading changes
  // It doesn't care about data, error, or any other state
}

// Component B: Only cares about error state  
function ErrorBoundary() {
  const { isError } = useQuery({
    queryKey: ['user', 1],
    queryFn: fetchUser
  })

  // This component ONLY gets notified when isError changes
  // It doesn't care about loading, data, or any other state
}

// Component C: Only cares about data
function UserProfile() {
  const { data } = useQuery({
    queryKey: ['user', 1],
    queryFn: fetchUser
  })

  // This component ONLY gets notified when data changes
  // It doesn't care about loading, error, or any other state
}

QueryObserver — The Smart Bridge Between Components and QueryCache

The QueryObserver is the intelligent bridge that connects your React components to the QueryCache. Think of it as a smart subscription service that knows exactly what your component cares about and only notifies it when those specific things change.

The Core Concept: Smart Subscription
Your insight is spot-on: useQuery is essentially a QueryObserver that creates a subscription between your component and the QueryCache. Here's how it works:

// What you write
const { data, isLoading } = useQuery({
  queryKey: ['user', 1],
  queryFn: () => fetchUser(1)
})

// What actually happens internally
const observer = new QueryObserver(queryClient, {
  queryKey: ['user', 1],
  queryFn: () => fetchUser(1)
})

// Observer creates subscription to QueryCache
observer.subscribe(componentCallback)

🧠 The Bigger Picture

This explanation transforms React Query from a "magic hook library" into a sophisticated data orchestration system. The key insight is that React Query isn't just about making API calls easier—it's about creating a predictable, performant, and scalable data layer for React applications.
The architectural understanding (QueryClient → QueryCache → Query → QueryObserver) gives you the mental model you need to:
1- Debug React Query issues effectively
2- Optimize performance by understanding re-render patterns
3- Design better data fetching strategies
4- Avoid common pitfalls like unstable QueryClient instances

💭 The Takeaway

Learn the HOW: "Use React Query hooks to fetch and cache data."
When you understand the WHY: "QueryClient orchestrates shared state, QueryCache eliminates duplicate requests, and QueryObserver enables selective re-renders," you gain a powerful data orchestration system that makes your React applications more performant and predictable.

Don't Sync State. Derive It! - The Mental Model That Fixes Half Your React Bugs

Mohamad Msalme — Thu, 04 Sep 2025 14:56:13 +0000

Know WHY — Let AI Handle the HOW 🤖

Ever find yourself writing useEffect hooks just to copy data from one state variable to another? What if I told you that most state synchronization is actually a design mistake - and there's a better way that eliminates entire categories of bugs?

🤔 Let's Start With a Common Mistake

You're building a user dashboard that shows server data with some client-side filtering:

function UserDashboard({ userId }) {
  const [users, setUsers] = useState([]);
  const [filteredUsers, setFilteredUsers] = useState([]);
  const [searchTerm, setSearchTerm] = useState('');

  // Fetch users from server
  useEffect(() => {
    fetchUsers(userId).then(setUsers);
  }, [userId]);

  // Sync filtered users when users or search term changes
  useEffect(() => {
    const filtered = users.filter(user => 
      user.name.toLowerCase().includes(searchTerm.toLowerCase())
    );
    setFilteredUsers(filtered);
  }, [users, searchTerm]);

  return (
    <div>
      <input 
        value={searchTerm}
        onChange={(e) => setSearchTerm(e.target.value)}
      />
      {filteredUsers.map(user => <UserCard key={user.id} user={user} />)}
    </div>
  );
}

The Problem: You've just created two sources of truth for the same data. What could go wrong?

🧠 Think Like a Database for a Moment

In database design, there's a principle: Don't store what you can calculate.

Why? Because the moment you store calculated data separately:

It can get out of sync with the source
You need complex synchronization logic
Bugs multiply like rabbits

Your React components are mini-databases. The same principle applies.

🔄 The Synchronization Tax

Every time you copy state, you pay the "synchronization tax":

Race Conditions: What if users update before the sync effect runs?
Extra Re-renders: Your component renders twice - once with stale data, once with synced data
Bug Surface Area: Every sync effect is a potential bug waiting to happen
Mental Overhead: You have to remember which state is "real" and which is "derived"

// The synchronization tax in action
const [data, setData] = useState([]);
const [sortedData, setSortedData] = useState([]);
const [filteredData, setFilteredData] = useState([]);
const [paginatedData, setPaginatedData] = useState([]);

// Four pieces of state that can all get out of sync!

✨ The Derivation Solution

Here's the mindset shift: Don't store derived state. Calculate it on every render.

function UserDashboard({ userId }) {
  const [users, setUsers] = useState([]);
  const [searchTerm, setSearchTerm] = useState('');

  useEffect(() => {
    fetchUsers(userId).then(setUsers);
  }, [userId]);

  // Derive, don't sync!
  const filteredUsers = users.filter(user => 
    user.name.toLowerCase().includes(searchTerm.toLowerCase())
  );

  return (
    <div>
      <input 
        value={searchTerm}
        onChange={(e) => setSearchTerm(e.target.value)}
      />
      {filteredUsers.map(user => <UserCard key={user.id} user={user} />)}
    </div>
  );
}

One source of truth. Zero synchronization bugs.

💡 Real-World Examples Where Developers Sync Instead of Derive

1. The Props-to-State Copy

// ❌ Syncing props into state
function UserProfile({ user }) {
  const [currentUser, setCurrentUser] = useState(user);

  useEffect(() => {
    setCurrentUser(user); // This will break!
  }, [user]);

  return <div>{currentUser.name}</div>;
}

// ✅ Just use the props directly
function UserProfile({ user }) {
  return <div>{user.name}</div>;
}

2. The Server Data Duplication

// ❌ Copying server data into multiple state variables
const { data: posts } = useQuery(['posts'], fetchPosts);
const [featuredPosts, setFeaturedPosts] = useState([]);

useEffect(() => {
  setFeaturedPosts(posts?.filter(post => post.featured) || []);
}, [posts]);

// ✅ Derive it every time
const { data: posts } = useQuery(['posts'], fetchPosts);
const featuredPosts = posts?.filter(post => post.featured) || [];

3. The Manual Calculation Cache

// ❌ Manually tracking calculated values
const [items, setItems] = useState([]);
const [totalPrice, setTotalPrice] = useState(0);

useEffect(() => {
  const total = items.reduce((sum, item) => sum + item.price, 0);
  setTotalPrice(total);
}, [items]);

// ✅ Calculate on each render
const [items, setItems] = useState([]);
const totalPrice = items.reduce((sum, item) => sum + item.price, 0);

⚡ "But What About Performance?"

Here's the mental model shift: React is already optimized for this pattern.

React's reconciliation is fast at detecting when derived values actually change
Most calculations are cheaper than you think
If performance becomes an issue, use useMemo selectively

// Only optimize when you actually need to
const expensiveCalculation = useMemo(() => {
  return reallyExpensiveFunction(largeDataSet);
}, [largeDataSet]);

🏠 The Perfect Analogy: Your Home's Temperature

Think of state synchronization like having multiple thermometers in your house that you manually update whenever the temperature changes.

The Sync Approach:

Kitchen thermometer shows 72°F
Living room thermometer shows 72°F
Temperature changes to 75°F
You manually update ALL thermometers

The Derive Approach:

One central temperature sensor
All displays read from the same source
Temperature changes? All displays automatically show the correct value

Which approach is more reliable?

🎯 The Mental Model That Changes Everything

Stop thinking: "I need to keep this data in sync"

Start thinking: "I need to calculate this data from the source"

Server data → Derive client views
Props → Derive component state
User input → Derive validation messages
Form fields → Derive submit button enabled state

🔍 How to Spot Sync State in Your Code

Look for these patterns in your codebase:

// 🚨 Red flags
useEffect(() => {
  setSomething(derivedFromSomethingElse);
}, [somethingElse]);

const [originalData, setOriginalData] = useState([]);
const [processedData, setProcessedData] = useState([]);

// Two pieces of state that represent the same information

🧠 The Bigger Picture

When you derive instead of sync:

Single Source of Truth: Your data flow becomes predictable
Fewer Bugs: Impossible to have out-of-sync state
Simpler Code: No complex synchronization effects
Better Performance: React optimizes derived calculations automatically

Your derivation strategy IS your data consistency strategy.

💭 The Takeaway

learn the HOW: "Use useEffect to keep state in sync."

When you understand the WHY: "Derived state eliminates synchronization bugs and creates predictable data flow," you gain a powerful tool that makes your React code more reliable and easier to reason about.

Next time you feel like syncing state, stop and ask: "Can I derive this instead?"

Remember: Know the WHY behind React's data flow principles, and the HOW becomes a natural extension of that understanding.

React's Key Prop Isn't About Lists - It's About Component Identity (And That Changes Everything)

Mohamad Msalme — Sat, 30 Aug 2025 11:23:25 +0000

Know WHY — Let AI Handle the HOW 🤖

React's key prop is often seen as just a way to avoid console warnings in lists. But what if I told you it's actually React's identity system - and understanding this unlocks powerful patterns?

🤔 Let's Start With a Puzzle

Imagine you're building a user profile switcher. You have a form that should reset when switching between users:

function UserProfile({ userId }) {
  const [email, setEmail] = useState('');
  const [phone, setPhone] = useState('');

  return (
    <form>
      <input 
        value={email} 
        onChange={(e) => setEmail(e.target.value)}
        placeholder="Email"
      />
      <input 
        value={phone} 
        onChange={(e) => setPhone(e.target.value)}
        placeholder="Phone"
      />
    </form>
  );
}

The Problem: When you switch users, the form keeps the old values! Why?

🧠 Think Like React for a Moment

Here's the mental model that might be missing:

React doesn't see "components" - it sees "component instances."

When React renders <UserProfile userId={123} />, it creates an instance of UserProfile and attaches state to that instance.

When you change to <UserProfile userId={456} />, React thinks:

"Same component type? ✅"
"Same position in the tree? ✅"
"I'll keep the same instance and just update the props!"

But that's not what you wanted! You wanted a fresh instance for the new user.

🗝️ The Key Insight (Literally)

The key prop is React's way of saying: "This is a different thing, treat it as a separate instance."

// React keeps the same instance (state persists)
<UserProfile userId={456} />

// React creates a new instance (state resets)  
<UserProfile key={userId} userId={456} />

🔄 The Identity Pattern

Think of key as React's identity card system:

Same key = "I know this instance, keep it around"
Different key = "This is someone new, start fresh"
No key = "Use position in the tree as identity"

💡 Real-World Examples Beyond Lists

1. Route-Based Form Reset

function EditProduct({ productId }) {
  return (
    <ProductForm 
      key={productId} // Fresh form for each product
      productId={productId} 
    />
  );
}

2. Modal State Reset

function UserModal({ isOpen, userId }) {
  return (
    <Modal isOpen={isOpen}>
      <UserDetails 
        key={userId} // Reset modal content when user changes
        userId={userId} 
      />
    </Modal>
  );
}

3. Language Switcher

function App({ language }) {
  return (
    <ThemeProvider 
      key={language} // Restart theme when language changes
      language={language}
    >
      <Dashboard />
    </ThemeProvider>
  );
}

⚡ The Performance Angle

Common misconception: "Using key forces unnecessary re-renders!"

Reality: Sometimes you WANT to reset state completely instead of trying to sync it manually.

// The hard way - manual state management
useEffect(() => {
  setEmail('');
  setPhone('');
  setErrors({});
  resetValidation();
  clearAsyncData();
}, [userId]);

// The key way - let React handle it
<UserForm key={userId} userId={userId} />

Which is cleaner? Which is less error-prone?

🎯 The Mental Model Shift

Stop thinking of key as "something for lists."

Start thinking of it as React's instance control system:

Component recycling when you want to keep instances alive
Component recreation when you want fresh starts
Identity management for React's reconciliation algorithm

🔍 The Debugging Superpower

When you understand key as identity, debugging becomes easier:

State not resetting when it should? → Add a key that changes

State resetting when it shouldn't? → Make sure the key stays stable

Weird behavior in lists? → Check if your keys are unique and stable

🧠 The Bigger Picture

React's key prop isn't magic - it's instance lifecycle control.

Once you see it this way:

The "annoying" list warnings make perfect sense
You gain a powerful tool for state management
You understand React's reconciliation at a deeper level

Your key strategy IS your component identity strategy.

💭 The Takeaway

Many learn the HOW: "Put keys on list items to avoid warnings."

When you understand the WHY: "Keys control component identity and lifecycle," you unlock patterns that make your React code more predictable and easier to reason about.

Remember: Know the WHY behind React's design decisions, and the HOW becomes a natural extension of that understanding.

What If React Had NO useEffect?

Mohamad Msalme — Sat, 30 Aug 2025 10:39:54 +0000

What If React Had NO useEffect? Building It From Scratch to Understand the WHY

Know WHY — Let AI Handle the HOW 🤖

Ever wondered why useEffect works the way it does? Let's think through this together by imagining React without useEffect and building our own solution step by step.

🎯 The Foundation: Everything Is Event-Driven

Your entire React app is just responding to events:

User clicks something → you handle it
API sends data → you handle it
Timer fires → you handle it

Simple, right? But here's where it gets interesting...

🧩 The Missing Piece

What if I want to "listen" to my props changing? Or my state updating?

There's no props.addEventListener('change') - props aren't DOM events. They're React's internal updates.

We need a way to subscribe to React's private changes.

🔨 Building Our Solution Step-by-Step

If we designed this subscription system from scratch, we'd need:

1️⃣ A callback function (what to do)

2️⃣ A condition (when to do it)

3️⃣ Timing control (before/after DOM updates)

That's literally what useEffect is!

🪤 The Closure Problem (Here's the WHY)

Now here's where things get really interesting...

When your effect runs, JavaScript creates a "snapshot" of all the values it uses. This is called a closure - it literally closes over those values.

But what happens when those values change in your component?

Your effect is still holding onto the OLD snapshot! It has no idea the values have updated.

💭 The Question This Raises:

How do we tell our effect: "Hey, get a fresh snapshot when these specific values change"?

We need a way to say:

"I want to subscribe to changes in THESE values specifically, and when they change, give me a new closure with the updated values."

✨ That's Exactly What the Dependency Array Solves!

It's like telling React:

"Watch these values for me. When any of them change, throw away my old closure and create a new one with fresh values."

useEffect(() => {
  // This closure captures current values
  console.log(`Current count: ${count}`);
}, [count]); // "Re-create this effect when count changes"

📋 The Three Patterns Explained

Once you understand the subscription model, these patterns make perfect sense:

[value1, value2] → "Re-run when these change"
[] → "Run once, don't watch anything"
No array → "Run every single render" (usually overkill!)

⚡ Why Functions, Not Promises?

Here's a crucial design decision: Why does useEffect take a function instead of returning a Promise?

Because React needs to know RIGHT NOW what cleanup to do when values change.

Promises are async - they'd break React's predictable update flow. React's render cycle is synchronous, and effects need to be too.

🎯 The Real Insight

useEffect isn't some mysterious hook. It's just:

A subscription system for React's internal events
A way to get fresh closures when dependencies change
A cleanup mechanism that runs synchronously with React's lifecycle

Your dependency array IS your subscription criteria.

Once you see this, the "exhaustive dependencies" rule makes perfect sense - you're just telling React exactly what to watch!

🧠 The Takeaway

Understanding the WHY behind useEffect transforms how you think about:

Side effects in React
Dependency management
Component lifecycle
State synchronization

When you know the underlying model, the API becomes intuitive instead of magical.

React Query Pattern Changed How you Think About Caching Forever

Mohamad Msalme — Sat, 30 Aug 2025 10:29:52 +0000

Know WHY — Let AI Handle the HOW 🤖

Ever treat React Query cache keys as random arrays? Let's dig deeper into the architectural pattern that changes everything.

The Problem We Are Missing 🤔

AI can teach you HOW to write:

useQuery(['posts', id], fetchPost)

But here's the WHY that transforms your entire caching strategy...

The Pattern Hidden in Plain Sight 👁️

Look at your API routes:

/posts/1
/posts/user/123  
/posts/favorites

Now look at your cache keys:

['posts', 1]
['posts', 'user', 123]
['posts', 'favorites']

See the pattern? Your API structure IS your cache structure.

This is the exact same concept as Next.js cache tags - the first item acts as a namespace for cache invalidation!

Building the Solution: BaseApi Class 🔨

Once you understand the WHY, you can implement a Repository Pattern that gives you all the benefits:

class BaseApi {
  constructor(tag) {
    this.tag = tag;
  }

  invalidateAll() {
    queryClient.invalidateQueries([this.tag]);
  }

  // All your CRUD methods here...
}

class PostApi extends BaseApi {
  constructor() {
    super('posts');
  }
}

const postApi = new PostApi();

The Power Move 🔥

Now you have tagged cache invalidation just like Next.js - but in your React Query app:

// One line invalidates ALL posts-related cache
postApi.invalidateAll()

The Benefits ✨

✅ Backend mutations naturally invalidate frontend cache

✅ Predictable cache boundaries

✅ Scales with your API architecture

The Architecture Insight 🎯

Your cache key architecture should mirror your API architecture.

When you POST/PUT/DELETE on any /posts/* route, invalidate the ['posts'] cache namespace.

This isn't just React Query — it's distributed cache design.

The Real Breakthrough 🧠

Do not think cache keys are just "identifiers." But they're actually:

Hierarchical namespaces that mirror your API structure
Invalidation boundaries for efficient cache management
Architectural decisions that affect your entire data flow

Once you see cache keys as architecture, not random arrays, everything changes.

Implementation Pattern

Here's how this looks in practice:

// Your API structure defines your cache structure
const userApi = new BaseApi('users');
const postApi = new BaseApi('posts');
const commentApi = new BaseApi('comments');

// Mutations automatically invalidate the right caches
const createPost = useMutation(postApi.create, {
  onSuccess: () => {
    postApi.invalidateAll(); // Invalidates all ['posts', ...] keys
  }
});

Why This Matters

When you align your cache architecture with your API architecture:

Cache invalidation becomes predictable
Your frontend naturally stays in sync with backend changes
Scaling becomes a matter of following the established pattern

Remember: Know the WHY behind the pattern, and the HOW becomes crystal clear.

What's your biggest React Query caching challenge? Share your experience in the comments! 👇