DEV Community: Bishoy Bishai

Beyond useEffect: Specialized Effect Hooks for Async, Deep Comparisons, and SSR

Bishoy Bishai — Tue, 19 May 2026 13:44:14 +0000

Missing

✨ Let's keep the conversation going!

If you found this interesting, I'd love for you to check out more of my work or just drop in to say hello.

✍️ Read more on my blog: bishoy-bishai.github.io

☕ Let's chat on LinkedIn: linkedin.com/in/bishoybishai

Top Shadcn Blocks Libraries Released in April 2026

Bishoy Bishai — Sat, 16 May 2026 11:36:42 +0000

Unlocking Velocity: My Top Shadcn Blocks Libraries from April 2026

We've all been there, right? Staring at a design mockup, a complex feature request, or just a new project kickoff, and the immediate thought is: "How many hours am I going to spend wrestling with CSS, accessibility, and responsive layouts before I even get to the actual business logic?" It's a fundamental tension in frontend development: the desire for pixel-perfect, custom UIs versus the undeniable need for speed and consistency.

For years, component libraries were the answer, but they often came with a trade-off: either too rigid, too opinionated, or too much effort to truly customize. Then Shadcn UI came along and, in my experience, fundamentally shifted the paradigm. By giving us the code to own, it struck a near-perfect balance between speed and control. We weren't just using components; we were adopting a codebase, tailoring it, and making it our own.

But here's the thing: as great as individual components are, the real magic starts happening when you compose larger, more complex UI sections – what we affectionately call "blocks." Think an entire authenticated dashboard layout, a multi-step checkout flow, or a sophisticated marketing landing page. Building these from scratch, even with Shadcn components, still requires significant time and meticulous attention to detail.

That's why the releases from April 2026 have me genuinely buzzing. We're seeing a maturity in the Shadcn ecosystem where block libraries are stepping up, providing incredible starting points that integrate seamlessly with your existing Shadcn setup. These aren't just collections of pre-made UIs; they're thoughtfully engineered, accessible, and highly customizable foundations that elevate your development velocity without sacrificing ownership.

Let's dive into a couple of the standouts that I've found myself reaching for again and again.

1. `@shadcn/dashboard-blocks`: The Powerhouse for Admin Panels

If you've ever built an admin panel, a SaaS dashboard, or any kind of internal tool, you know the repetitive pain: navbars, sidebars, user tables with pagination, settings forms, analytics cards. It's a mountain of necessary but often uninspiring UI work.

@shadcn/dashboard-blocks is a revelation. It provides a comprehensive suite of opinionated but flexible blocks specifically designed for these scenarios. I've found its DashboardShell and DataTable components to be particularly transformative.

Why it matters:

Rapid Prototyping: Spin up a fully functional dashboard layout in minutes, complete with responsive navigation and basic authentication flows.
Feature-Rich Tables: The DataTable block isn't just a basic table; it comes pre-configured with filtering, sorting, pagination, and bulk actions, saving countless hours.
Consistency: All blocks adhere to the Shadcn UI design system, ensuring a cohesive look and feel across your application.

Quick Peek at Usage:

pnpm add -D @shadcn/ui
npx shadcn-ui@latest add button input # Make sure you have basic components
pnpm install @shadcn/dashboard-blocks
npx shadcn-ui@latest add dashboard-shell data-table # Copy the block code

Then, in your React component:

```typescript jsx
// app/dashboard/page.tsx
import { DashboardShell, DashboardHeader } from "@/components/dashboard-blocks";
import { DataTable } from "@/components/data-table"; // Adjust path as needed
import { columns } from "./columns"; // Define your columns here
import { users } from "./data"; // Your data source

export default function DashboardPage() {
return (

);
}




This isn't just a component; it's a *solution* for a common problem, ready for your data and custom actions.

## 2. `@shadcn/commerce-kit`: Streamlining E-commerce UIs

Building an e-commerce storefront is notoriously complex. Product listings, detail pages, shopping carts, checkout flows, order confirmations – each is a significant chunk of work. Prior to April 2026, I often found myself building these pieces from the ground up, even with individual Shadcn components.

Enter `@shadcn/commerce-kit`. This library focuses on the core building blocks of online retail. What truly sets it apart, in my experience, are the `ProductGrid` and `CheckoutWizard` blocks.

**Why it matters:**
*   **End-to-End Flows:** It provides not just individual components, but entire user flows (like a multi-step checkout) that you can drop in and connect to your backend.
*   **Optimized for Conversion:** These blocks often come with best practices for e-commerce UIs baked in, from clear calls-to-action to accessible forms.
*   **Rich Product Displays:** The `ProductGrid` block handles image loading, price display, and even quick-add-to-cart functionality, significantly accelerating product catalog development.

**Usage Snippet:**



```bash
pnpm add @shadcn/commerce-kit
npx shadcn-ui@latest add product-card checkout-wizard

```typescript jsx
// app/shop/page.tsx
import { ProductCard } from "@/components/product-card"; // from @shadcn/commerce-kit
import { products } from "./data"; // Your product data

export default function ShopPage() {

return (

Our Latest Products

{products.map((product) => (

))}

);

}



The `ProductCard` from this kit is a beautiful starting point, encompassing image, title, price, and even a "quick view" or "add to cart" button.

## The Real Insights: Beyond Just Copy-Pasting

Here's the thing that most tutorials gloss over when it comes to adopting tools like these: it's not just about the convenience of having pre-built components.

1.  **True Ownership & Customization:** Unlike traditional UI libraries that abstract away the implementation, Shadcn's philosophy means you *get the code*. This is even more powerful with blocks. You can dive in, tweak Tailwind classes, modify React logic, integrate your state management, or even completely re-architect parts of it if your unique requirements demand it. This isn't a black box; it's an intelligent starting point.
2.  **Learning Best Practices:** By examining the code for these blocks, you're essentially getting a masterclass in building accessible, responsive, and performant React components using Tailwind CSS and Radix UI primitives. I've found myself learning new patterns and tricks just by reviewing how these blocks are constructed.
3.  **Consistency Across Teams:** When a team adopts a block library, it naturally enforces a higher degree of UI consistency. Everyone is starting from the same well-designed foundation, which reduces design drift and developer disputes over styling.
4.  **Focus on Differentiation:** This is the most crucial takeaway. By offloading the "standard" UI work to these robust blocks, your team can redirect its energy and creativity to solving the *unique* problems your application addresses. That's where real value is created, not in spending hours perfecting a settings page layout.

## Pitfalls to Avoid

As powerful as these block libraries are, a thoughtful approach is key.

*   **Don't Treat Them as Black Boxes:** While the point is convenience, resist the urge to just copy-paste and forget. Take a moment to understand the structure, especially if you anticipate heavy customization. Knowing how they're built makes future modifications much smoother.
*   **Mindful Customization:** Shadcn blocks are highly customizable, but don't fall into the trap of over-customizing every minor detail. Leverage the existing styling and functionality where possible, and only deviate when your brand or UX truly demands it. Every custom change adds to your maintenance burden.
*   **Dependency Management:** While you own the code, remember it's still based on a specific set of Shadcn components. Keep your core Shadcn UI components updated (`npx shadcn-ui@latest update`) to ensure compatibility and benefit from bug fixes and improvements.
*   **"Not Invented Here" Syndrome:** Sometimes, we developers have a strong desire to build everything ourselves. Recognize when a block library offers a superior, faster, or more robust solution than what you'd build from scratch, even if it means adopting external code.

## The Future of UI Development is Composable

The release of these sophisticated Shadcn block libraries in April 2026 feels like a significant leap forward. It's a testament to the power of a developer-centric ecosystem that prioritizes ownership and flexibility. We're moving beyond mere component libraries to intelligent, composable UI sections that significantly reduce time-to-market and enhance the overall quality of our applications.

So, if you're looking to supercharge your React development workflow, empower your team, and build truly impressive UIs with unprecedented speed, I highly recommend diving into the latest Shadcn block libraries. They're not just tools; they're strategic assets that can redefine how you approach frontend development. Go on, give them a spin – your future self will thank you.

---

**✨ Let's keep the conversation going!**

If you found this interesting, I'd love for you to check out more of my work or just drop in to say hello.

✍️ **Read more on my blog:** [bishoy-bishai.github.io](https://bishoy-bishai.github.io/portfolio/blog/)  
☕ **Let's chat on LinkedIn:** [linkedin.com/in/bishoybishai](https://www.linkedin.com/in/bishoybishai/)

---

5 JavaScript Mistakes Beginners Still Make in 2026

Bishoy Bishai — Fri, 15 May 2026 12:24:13 +0000

The Persistent Perils: 5 JavaScript Mistakes Beginners (Still) Make in 2026

Alright, grab a coffee. We need to talk.

It’s 2026. We've got async/await, Optional Chaining, Nullish Coalescing, Top-level await, even Stage 3 Record & Tuple proposals potentially landing soon. Our tooling is slick, frameworks are mature, and TypeScript has become the undisputed champion of type safety. Yet, I've found, working with teams both big and small, that some fundamental JavaScript mistakes still sneak into our codebases, causing disproportionate amounts of head-scratching and late-night debugging sessions.

It’s easy to dismiss these as "beginner issues," but the truth is, they're more like foundational cracks. If left unaddressed, they can lead to flaky tests, unpredictable behavior, and architectural debt that grinds productivity to a halt. In my experience, even seasoned developers can sometimes overlook these subtleties when rushing to meet a deadline or diving into a new part of a large application.

So, let's pull back the curtain on five persistent JavaScript pitfalls. These aren't just theoretical; these are lessons learned from real projects, real bugs, and real moments of "aha, that's why it broke!"

1. The Async Abyss: Mismanaging Promises & `async/await`

This one feels obvious, right? We've had Promises for ages, and async/await has been standard for years. Yet, I still frequently see subtle misuses.

The Mistake:

Not correctly handling all possible error paths in asynchronous flows.
Using await inside a forEach loop without understanding its sequential nature or how to parallelize when needed.
Forgetting that a catch block for one Promise doesn't automatically catch errors from subsequent operations unless chained correctly.

Relatable Story: I remember a customer-facing dashboard where a critical data update sometimes just... wouldn't happen, with no visible error. Turns out, an async function was calling two other async functions: fetchUserData() and updateUI(). The updateUI() had a subtle error, but because fetchUserData() didn't await it, the parent function completed successfully without waiting for the UI to actually update, silently swallowing the error. We only found it by digging into network logs and noticing an incomplete UI state.

Here’s the thing: async/await makes async code look synchronous, which is a blessing and a curse. It feels like try...catch will just magically handle everything, but you need to be explicit.

// The Pitfall: Subtle error-swallowing
async function processData() {
    try {
        const user = await fetchUser(); // Might throw
        const posts = fetchUserPosts(user.id); // This is NOT awaited, returns a Promise
        // If fetchUserPosts throws, it's an unhandled promise rejection
        // If you intended to await posts here, you missed it!
        return { user, posts };
    } catch (error) {
        console.error("Failed to process data:", error);
    }
}

// The Fix: Await everything intended, chain errors, or use Promise.all
async function processDataRobustly() {
    try {
        const user = await fetchUser();
        // Option 1: Await directly
        const posts = await fetchUserPosts(user.id); // Now this error is caught
        return { user, posts };
    } catch (error) {
        console.error("Failed to fetch user or posts:", error);
        throw error; // Re-throw if you want upstream callers to handle
    }
}

// Another Pitfall: Await in loop without parallelization
async function processManyItemsSequentially(items: string[]) {
    const results = [];
    for (const item of items) {
        // This runs sequentially, one after another
        results.push(await processSingleItem(item));
    }
    return results;
}

// The Fix: Parallelize with Promise.all when independent
async function processManyItemsInParallel(items: string[]) {
    // All promises start executing immediately
    const promises = items.map(item => processSingleItem(item));
    // Wait for all of them to settle
    return Promise.all(promises);
}

The key is intentionality. Understand when to await, when to Promise.all, and always, always consider the full error path for every asynchronous operation.

2. Mutation Mayhem: Forgetting Immutability in Data Structures

This is arguably the most insidious bug generator in JavaScript applications, especially with component-based UIs like React or Vue.

The Mistake: Directly modifying objects or arrays that were passed into a function or component, instead of creating a new copy.

Relatable Story: A few years back, we had a data table where filtering and sorting sometimes glitched out, showing stale data until a full refresh. The filter and sort functions were operating directly on the props.data array. Since React (or any declarative UI) relies on detecting reference changes to re-render, mutating the array in place meant the component's data prop reference never changed, and thus, it never re-rendered with the "new" filtered/sorted state. The worst part? It worked sometimes because other unrelated state changes would force a re-render, making it incredibly hard to reproduce consistently.

Here's the thing: JavaScript objects and arrays are reference types. When you pass them around, you're passing a reference to the same underlying data. If one part of your application modifies that data directly, every other part holding a reference to it will see that change, often unexpectedly.

// The Pitfall: Direct mutation
function addItemToCart(cart: Item[], newItem: Item) {
    cart.push(newItem); // Mutates the original cart array
    return cart; // Returns the same mutated array
}

let userCart = [{ id: 1, name: "Book" }];
let updatedCart = addItemToCart(userCart, { id: 2, name: "Pen" });

console.log(userCart === updatedCart); // true - they are the same reference
console.log(userCart); // [{ id: 1, name: "Book" }, { id: 2, name: "Pen" }] - original was modified!

// The Fix: Create new copies
function addItemToCartImmutable(cart: Item[], newItem: Item) {
    return [...cart, newItem]; // Returns a *new* array
}

let userCartImmutable = [{ id: 1, name: "Book" }];
let updatedCartImmutable = addItemToCartImmutable(userCartImmutable, { id: 2, name: "Pen" });

console.log(userCartImmutable === updatedCartImmutable); // false - new reference
console.log(userCartImmutable); // [{ id: 1, name: "Book" }] - original is unchanged!
console.log(updatedCartImmutable); // [{ id: 1, name: "Book" }, { id: 2, name: "Pen" }]

Use spread syntax (...) for arrays and objects ({ ...obj, newProp: value }), map, filter, reduce for array transformations, and always default to creating a new reference when changing data that might be shared. Your future self (and colleagues) will thank you.

3. The `this` Conundrum & Scope Sorcery

Ah, this. The chameleon of JavaScript. Even in 2026, with arrow functions galore, understanding how this behaves—and more broadly, how scope and closures capture variables—is still a source of bewilderment.

The Mistake: Assuming this refers to what you think it does, especially in event handlers, callbacks, or methods passed around. Not understanding how closures "trap" variables.

Relatable Story: I was reviewing some legacy Node.js code that was migrating to a more modular structure. A class method was extracted and passed as a callback to an event emitter. The developer was scratching their head because this.config inside the callback was undefined. They expected it to refer to the class instance, but in the context of the event emitter, this was the emitter itself! It was a classic "lost this" problem.

Here’s the thing: this is dynamically scoped in regular functions, meaning its value depends on how the function is called, not where it's defined. Arrow functions, however, lexically bind this (they inherit this from their parent scope) which makes them behave more predictably, but doesn't solve the fundamental understanding problem.

// The Pitfall: Lost 'this' in a regular function callback
class MyLogger {
    prefix = "[App]";
    log(message: string) {
        console.log(`${this.prefix} ${message}`);
    }

    // This method will be passed as a callback
    logAfterDelay(message: string) {
        setTimeout(function() {
            // 'this' here refers to the global object (window/undefined in strict mode), NOT MyLogger
            // so this.prefix will be undefined
            this.log(message); // TypeError: this.log is not a function
        }, 100);
    }
}

const logger = new MyLogger();
// logger.logAfterDelay("Starting up..."); // This will break!

// The Fixes: Arrow functions, .bind(), or capturing 'this'
class MyLoggerFixed {
    prefix = "[App]";
    log(message: string) {
        console.log(`${this.prefix} ${message}`);
    }

    logAfterDelayArrow(message: string) {
        setTimeout(() => { // Arrow function binds 'this' lexically
            this.log(message); // Works! 'this' is MyLogger instance
        }, 100);
    }

    logAfterDelayBind(message: string) {
        setTimeout(this.log.bind(this, message), 100); // Explicitly bind 'this'
    }
}

const fixedLogger = new MyLoggerFixed();
fixedLogger.logAfterDelayArrow("Starting up with arrow function!");
fixedLogger.logAfterDelayBind("Starting up with bind method!");

// Scope/Closure Pitfall: Variable capture in loops
for (var i = 0; i < 3; i++) {
    setTimeout(function() {
        console.log(i); // Logs 3, 3, 3 (because 'var' is function-scoped, and by the time setTimeout runs, i is 3)
    }, 100);
}

// The Fix: Use 'let' for block-scoping
for (let j = 0; j < 3; j++) {
    setTimeout(function() {
        console.log(j); // Logs 0, 1, 2 (each 'j' is unique per loop iteration)
    }, 100);
}

Understanding this and scope isn't just academic; it directly impacts how you write robust classes, handle event listeners, and manage state in complex applications.

4. Error Handling Apathy: Silent Failures in the Production Wilderness

We’ve all been there: a feature suddenly stops working, but the UI gives no indication, and the logs are eerily silent. This often points to insufficient or misunderstood error handling.

The Mistake:

Not wrapping critical synchronous code in try...catch blocks.
Ignoring rejected Promises or not adding .catch() handlers to async functions that don't have an await caller.
"Swallowing" errors by just console.error(error) without re-throwing or notifying the user/system.

Relatable Story: On a project years ago, a backend API call failed silently because the catch block in our frontend async function just logged the error to the console. The user saw nothing, and the application continued as if the data had loaded, leading to a blank section. The client only discovered the issue because they reported a missing feature, not because our monitoring caught a problem. If we had thrown the error again or had a global error boundary, we would have known immediately.

Here’s the thing: Errors will happen. Network issues, malformed data, API changes—they're inevitable. Your application needs a strategy to gracefully handle them, inform the user, and log relevant details for debugging.

// The Pitfall: Silent failure in async code
async function fetchDataAndDisplay() {
    try {
        const response = await fetch("/api/data");
        const data = await response.json();
        displayData(data);
    } catch (error) {
        console.error("Error fetching data:", error); // Only logs, doesn't propagate or show UI error
        // What if displayData() also throws an error? It's not caught here.
    }
}

// The Fix: Robust error handling
async function fetchDataAndDisplayRobustly() {
    try {
        const response = await fetch("/api/data");
        if (!response.ok) {
            // Handle non-2xx responses as errors explicitly
            throw new Error(`HTTP error! Status: ${response.status}`);
        }
        const data = await response.json();
        displayData(data); // Assume displayData can also throw if data is malformed
    } catch (error) {
        console.error("A critical error occurred:", error);
        // Show an error message to the user
        showUserErrorMessage("Failed to load content. Please try again.");
        // Re-throw if an upstream caller should also be aware/handle it
        throw error;
    }
}

// Global unhandled promise rejection handler
// window.addEventListener('unhandledrejection', event => {
//     console.error('Unhandled Promise Rejection:', event.promise, event.reason);
//     // Send to error monitoring service
//     Sentry.captureException(event.reason);
// });

Always anticipate failures. Implement try...catch for synchronous blocks, add .catch() to promises, and consider global error boundaries or unhandledrejection listeners to catch anything that slips through. A good error handling strategy is a hallmark of a professional application.

5. Global Gotchas & Side Effect Sprawl

The allure of quick fixes with global variables or functions that unpredictably modify state is strong, especially for beginners. But it's a slippery slope to spaghetti code.

The Mistake:

Over-reliance on global variables to share state between modules or components.
Functions that produce side effects (e.g., modifying external state, DOM, network requests) without clear indications or control.
"Action at a distance," where a change in one part of the system unexpectedly affects a seemingly unrelated part.

Relatable Story: We had a legacy module that used a global configuration object. Different parts of the app would 'initialize' this object based on certain conditions. The problem was, if two parts of the app tried to initialize it slightly differently or at different times, they'd clobber each other's settings. It was a race condition waiting to happen, leading to features working on some pages but not others, all because of an undocumented global state modification.

Here’s the thing: Predictability is key to maintainable software. When a function or component depends on global state or produces hidden side effects, it becomes incredibly hard to test, reuse, and reason about.

// The Pitfall: Global variable for state
// In global scope or imported directly everywhere
let appConfig = {}; 

function initializeConfig(settings: any) {
    Object.assign(appConfig, settings); // Mutates global config
}

function getConfigValue(key: string) {
    return appConfig[key]; // Depends on global config
}

// Elsewhere in the app
initializeConfig({ theme: "dark" });

// In another module, later on
initializeConfig({ language: "en" }); // Unintentionally overwrites/merges
console.log(getConfigValue("theme")); // Might still be "dark" or gone, depending on merge logic. Hard to track.


// The Fix: Encapsulate state, pass explicit dependencies
class AppConfigManager {
    private config: Record<string, any> = {};

    constructor(initialConfig: Record<string, any> = {}) {
        this.config = { ...initialConfig }; // Initialize with a copy
    }

    setConfig(settings: Record<string, any>) {
        this.config = { ...this.config, ...settings }; // Create new config object
    }

    getConfigValue(key: string) {
        return this.config[key];
    }
}

// Instance created and passed down explicitly (e.g., via dependency injection, props)
const configManager = new AppConfigManager({ theme: "light" });
configManager.setConfig({ language: "es" });
console.log(configManager.getConfigValue("theme")); // "light"
console.log(configManager.getConfigValue("language")); // "es"

// Side Effect Pitfall: Function with hidden side effects
function processAndLogUser(user: User) {
    // Does some processing...
    // AND then reaches out and modifies a global UI element
    document.getElementById('last-processed-user').innerText = user.name; // Hidden side effect
    return user; // Function not purely transforming user, has external impact
}

// The Fix: Isolate side effects, make functions pure or explicit
function processUserPure(user: User): ProcessedUser {
    // Pure transformation, no external effects
    return { ...user, processedAt: new Date() };
}

function updateLastProcessedUserUI(userName: string) {
    // Dedicated function for the side effect
    document.getElementById('last-processed-user').innerText = userName;
}

const processedUser = processUserPure(user);
updateLastProcessedUserUI(processedUser.name); // Side effect is explicit

Minimize globals. Favor pure functions that take inputs and return outputs without modifying anything outside their scope. When side effects are necessary (and they always are!), encapsulate them and make them explicit. This makes your code modular, testable, and far easier to debug.

So, there you have it. These aren't obscure edge cases; they're fundamental challenges that JavaScript developers encounter daily. By deeply understanding these concepts and adopting best practices around them, you'll not only write cleaner, more resilient code but also spend less time chasing down elusive bugs. The future of JavaScript development isn't just about new features; it's about mastering the timeless principles that make our applications robust. Keep learning, keep refining, and keep building awesome stuff!

✨ Let's keep the conversation going!

If you found this interesting, I'd love for you to check out more of my work or just drop in to say hello.

✍️ Read more on my blog: bishoy-bishai.github.io

☕ Let's chat on LinkedIn: linkedin.com/in/bishoybishai

React Observer Hooks: 7 Ways to Watch the DOM Without the Boilerplate

Bishoy Bishai — Wed, 13 May 2026 12:45:45 +0000

React Observer Hooks: 7 Ways to Watch the DOM Without the Boilerplate

Working with React, we spend most of our time in a beautiful, declarative world. We describe what our UI should look like, and React handles the messy details of making it happen in the DOM. But sometimes, just sometimes, we need to peek behind the curtain. We need to know: "Is this element visible right now?", "Has its size changed?", or even "Did some external script just modify this specific data attribute?"

If you've ever found yourself asking these questions, you've probably reached for useEffect, slapped on an addEventListener, and then immediately started thinking about cleanup, performance, and how this will scale across your components. I've been there countless times, and let me tell you, it quickly becomes a boilerplate nightmare.

Here's the thing: the browser offers incredibly powerful, performant APIs designed specifically for watching the DOM: IntersectionObserver, ResizeObserver, MutationObserver, and a few others. The challenge isn't the APIs themselves, but integrating them seamlessly into React's component lifecycle. That's where custom React Observer Hooks shine. They let us harness these native powers with the elegance and reusability we expect from React.

Let's dive into how we can turn these low-level browser APIs into clean, reusable React hooks, drastically reducing boilerplate and boosting performance. We'll cover 3 core browser APIs and then look at how to build robust hooks around them, culminating in about 7 distinct ways to tackle DOM observation.

The Core Problem: React's Declarative World vs. DOM Imperatives

React thrives on reconciliation – it decides when to touch the DOM. Directly manipulating or constantly polling the DOM from within a useEffect often leads to:

Performance issues: Frequent DOM queries or event handlers can be expensive.
Boilerplate fatigue: Setting up, tearing down, and managing event listeners for every scenario.
Race conditions: When exactly is the DOM node available? When does the observer need to be connected/disconnected?
Reusability headaches: Copy-pasting the same logic everywhere.

Native browser Observers solve the performance and boilerplate issues by providing an asynchronous, highly optimized way to be notified of DOM changes. Our job is to wrap them in a React-friendly API.

The Building Block: `useCallbackRef` (Your Observer's Best Friend)

Before we jump into the observers themselves, there’s a foundational pattern that makes all these hooks robust: a stable way to get a reference to a DOM node and trigger a callback when it mounts or unmounts. This is often achieved with a useCallbackRef pattern or similar.

Here’s a simplified version:

import { useRef, useCallback, useState } from 'react';

type RefCallback<T> = (node: T | null) => void;

function useCallbackRef<T = HTMLElement>(): [T | null, RefCallback<T>] {
  const [node, setNode] = useState<T | null>(null);

  const setRef = useCallback((newNode: T | null) => {
    if (newNode !== node) {
      setNode(newNode);
    }
  }, [node]);

  return [node, setRef];
}

This hook gives you a node state variable (the actual DOM element) and a setRef callback. You assign setRef to your element's ref prop (<div ref={setRef}>). Crucially, setNode is only called when the node actually changes, making it stable. This node is what we'll pass to our native observers.

1. `useIntersectionObserver`: Knowing When Elements Enter or Exit View

The Problem: Lazy loading images, implementing infinite scroll, triggering animations when a component becomes visible, or sending analytics events when a section is seen.

The Solution: The IntersectionObserver API. It lets you know when an element "intersects" with its root (usually the viewport). It's incredibly performant because it doesn't run on the main thread and avoids constant scroll event listeners.

The Hook (useIntersectionObserver):

import { useEffect, useState, useRef } from 'react';
// Assuming you have useCallbackRef from above

interface UseIntersectionObserverOptions extends IntersectionObserverInit {
  freezeOnceVisible?: boolean;
}

function useIntersectionObserver<T extends HTMLElement = HTMLDivElement>(
  options: UseIntersectionObserverOptions = {}
): [T | null, IntersectionObserverEntry | undefined] {
  const [node, setRef] = useCallbackRef<T>();
  const [entry, setEntry] = useState<IntersectionObserverEntry>();

  const observer = useRef<IntersectionObserver | null>(null);
  const frozen = entry?.isIntersecting && options.freezeOnceVisible;

  const { root, rootMargin, threshold, freezeOnceVisible } = options;

  useEffect(() => {
    if (!node || frozen) return;

    // Disconnect previous observer if options change
    if (observer.current) {
      observer.current.disconnect();
    }

    observer.current = new IntersectionObserver(([entry]) => {
      setEntry(entry);
    }, { root, rootMargin, threshold });

    observer.current.observe(node);

    return () => {
      observer.current?.disconnect();
    };
  }, [node, root, rootMargin, threshold, frozen, freezeOnceVisible]);

  return [node, entry];
}

How to Use It:

```typescript jsx
function LazyImage({ src, alt }: { src: string; alt: string }) {
const [imgRef, entry] = useIntersectionObserver({
threshold: 0.1, // Trigger when 10% of the image is visible
freezeOnceVisible: true, // Stop observing once it's visible
});

const isVisible = entry?.isIntersecting;

return (
ref={imgRef}
src={isVisible ? src : undefined} // Only load src when visible
alt={alt}
style={{ minHeight: '200px', background: '#eee' }} // Placeholder
/>
);
}



This hook is a game-changer for performance. I’ve found that using `freezeOnceVisible` significantly reduces unnecessary re-renders once an element has served its purpose (e.g., loaded an image).

## 2. `useResizeObserver`: Reacting to Element Size Changes

**The Problem:** You need to adjust the layout of a component based on its *own* rendered size, not just the viewport. Think responsive charts, dynamically fitting text, or custom canvas resizing. `window.resize` isn't enough; you need to know when *an element* resizes.

**The Solution:** The `ResizeObserver` API. It asynchronously notifies you when the content rectangle of an element changes. It's incredibly efficient because it batches updates and avoids layout thrashing.

**The Hook (`useResizeObserver`):**



```typescript
import { useEffect, useState } from 'react';
// Assuming useCallbackRef from above

function useResizeObserver<T extends HTMLElement = HTMLDivElement>(): [
  T | null,
  DOMRectReadOnly | undefined
] {
  const [node, setRef] = useCallbackRef<T>();
  const [dimensions, setDimensions] = useState<DOMRectReadOnly>();

  useEffect(() => {
    if (!node) return;

    const observer = new ResizeObserver((entries) => {
      if (entries[0]) {
        setDimensions(entries[0].contentRect);
      }
    });

    observer.observe(node);

    return () => {
      observer.disconnect();
    };
  }, [node]);

  return [node, dimensions];
}

How to Use It:

```typescript jsx
function ResponsiveSquare() {
const [squareRef, dimensions] = useResizeObserver();
const size = dimensions ? Math.min(dimensions.width, dimensions.height) : 0;

return (

ref={squareRef}
style={{
width: '50%', // Occupy half of parent's width
height: '300px', // Fixed height
backgroundColor: 'lightblue',
display: 'flex',
justifyContent: 'center',
alignItems: 'center',
fontSize: '24px',
border: '2px solid blue',
boxSizing: 'border-box',
resize: 'both', // Allows manual resizing in some browsers
overflow: 'auto',
}}
>
Width: {dimensions?.width.toFixed(0)}px

Height: {dimensions?.height.toFixed(0)}px

);
}



This hook has saved me from so many `setTimeout` hacks and recalculation woes, especially when dealing with dynamic content or third-party components that might change their own size.

## 3. `useMutationObserver`: Monitoring DOM Tree Changes

**The Problem:** You need to detect when an element's attributes change, its text content is modified, or its children are added/removed. This is particularly useful for integrating with older libraries, monitoring third-party widgets, or even debugging unexpected DOM mutations.

**The Solution:** The `MutationObserver` API. It's a powerful but often misunderstood API, allowing you to watch specific changes to a DOM tree.

**The Hook (`useMutationObserver`):**



```typescript
import { useEffect, useState } from 'react';
// Assuming useCallbackRef from above

interface UseMutationObserverOptions extends MutationObserverInit {}

function useMutationObserver<T extends HTMLElement = HTMLDivElement>(
  options: UseMutationObserverOptions = {
    attributes: true,
    childList: true,
    subtree: true,
  }
): [T | null, MutationRecord[] | undefined] {
  const [node, setRef] = useCallbackRef<T>();
  const [mutations, setMutations] = useState<MutationRecord[]>();

  useEffect(() => {
    if (!node) return;

    const observer = new MutationObserver((mutationsList) => {
      setMutations(mutationsList);
    });

    observer.observe(node, options);

    return () => {
      observer.disconnect();
    };
  }, [node, options]); // Re-run if options change

  return [node, mutations];
}

How to Use It:

```typescript jsx
function ThirdPartyWidgetWrapper() {
const [widgetRef, mutations] = useMutationObserver({
attributes: true,
attributeFilter: ['data-status'], // Only watch 'data-status' attribute
childList: false, // Don't care about children for this example
subtree: false,
});

useEffect(() => {
if (mutations) {
console.log('DOM mutations detected:', mutations);
mutations.forEach(mutation => {
if (mutation.type === 'attributes' && mutation.attributeName === 'data-status') {
console.log(data-status changed from "${mutation.oldValue}" to "${(mutation.target as HTMLElement).dataset.status}");
// Trigger some React state update based on this
}
});
}
}, [mutations]);

return (

{/* Imagine a third-party script injecting content or changing attributes here */}

Content that might change

{

if (widgetRef) {

widgetRef.dataset.status = widgetRef.dataset.status === 'initial' ? 'active' : 'initial';

}

}}>

Change Status (Simulated)

);

}



`MutationObserver` is the most "powerful" but also the one you need to use with care. In my experience, it's easy to create an overly chatty observer that triggers too many updates if you watch for too many types of changes on a large subtree. Be specific with your `options`!

## Beyond the Big Three: More Observer Flavors

While the above three are the most common for *watching the DOM itself*, you can extend the "Observer" pattern in React to other areas:

4.  **`useMediaQuery`:** Not a DOM observer in the same sense, but `matchMedia` is an "observer" for CSS media queries.


    ```typescript
    import { useState, useEffect } from 'react';

    function useMediaQuery(query: string) {
      const [matches, setMatches] = useState(() => window.matchMedia(query).matches);

      useEffect(() => {
        const mediaQueryList = window.matchMedia(query);
        const listener = (event: MediaQueryListEvent) => setMatches(event.matches);
        mediaQueryList.addEventListener('change', listener);
        return () => mediaQueryList.removeEventListener('change', listener);
      }, [query]);

      return matches;
    }
    ```


    This is fantastic for responsive components that need to adapt based on JS logic, not just CSS.

5.  **`useIdleCallback` (or `useScheduler` for finer control):** While not strictly a DOM observer, `requestIdleCallback` allows you to observe when the browser is idle and perform low-priority, non-essential work without impacting user experience. It's observing the *browser's state*.

6.  **`usePerformanceObserver`:** This one is a bit more niche but incredibly powerful for monitoring application performance. It allows you to observe various performance metrics like paint times, resource loading, and long tasks. While not directly DOM-watching, it's observing events *related* to DOM rendering and user interaction.

7.  **Custom Event Observer (`useCustomEvent`):** Sometimes, you have custom events bubbling up through the DOM or emitted by other libraries. A generic `useCustomEvent` hook can be a clean way to subscribe to these without cluttering `useEffect`.

## Key Insights and Pitfalls to Avoid

*   **Performance is King:** Native observers are optimized. They run asynchronously, often off the main thread, and batch changes. This is almost always superior to manual `scroll` or `resize` event listeners with debouncing.
*   **Disconnect is Crucial:** Always, always, *always* ensure your observers are disconnected in the `useEffect` cleanup function. Forgetting this leads to memory leaks and zombie observers.
*   **Specificity with `MutationObserver`:** As mentioned, `MutationObserver` can be very noisy. Use `attributeFilter`, `childList`, `subtree` options wisely to only observe what you truly need.
*   **`root` and `rootMargin` for `IntersectionObserver`:** Don't forget these powerful options to define the intersection context. `root` can be any scrollable ancestor element, not just the viewport. `rootMargin` allows you to expand or shrink the root's bounding box.
*   **`useLayoutEffect` vs. `useEffect`:** For observer setup, `useEffect` is usually fine because observers are asynchronous. However, if your observer callback *directly* needs to read layout or make layout-affecting changes *synchronously* before the browser paints, `useLayoutEffect` might be necessary, but this is rare with observers.
*   **Dependencies of Observer Hooks:** Pay close attention to the `useEffect` dependencies within your custom observer hooks. Ensure they only re-create the observer when genuinely necessary (e.g., `node` changes, or observer `options` change).

## Wrapping Up

By embracing native browser Observer APIs and wrapping them in elegant, reusable React hooks, you can significantly reduce boilerplate, improve performance, and build more robust and maintainable applications. Gone are the days of manual event listeners and `setInterval` hacks for DOM changes.

These hooks move you from an imperative "check the DOM constantly" mindset to a declarative "tell me when this changes" approach, aligning perfectly with React's philosophy. Give them a try in your next project; I guarantee you'll find countless scenarios where they simplify your code and make your life as a developer a lot easier. Happy observing!

---

**✨ Let's keep the conversation going!**

If you found this interesting, I'd love for you to check out more of my work or just drop in to say hello.

✍️ **Read more on my blog:** [bishoy-bishai.github.io](https://bishoy-bishai.github.io/portfolio/blog/)  
☕ **Let's chat on LinkedIn:** [linkedin.com/in/bishoybishai](https://www.linkedin.com/in/bishoybishai/)

---

React Hooks in 2026: Not Just What They Do — When to Reach for Each One

Bishoy Bishai — Mon, 11 May 2026 12:32:06 +0000

Every hook is a solution to a specific problem. The senior developer's skill isn't knowing the API — it's knowing the problem.

Let me tell you the moment I knew I'd finally understood React Hooks.

It was 2019; I was building the first mobile app from scratch. No templates. No prior codebase. A blank React Native project and a deadline that didn't care about my learning curve.

I had a form with six steps. Each step had its own state. State from step two affected validation in step five. The user could jump backwards. Progress had to persist. Errors had to be per-field, not per-form.

My first instinct was to reach for useState. Six calls, one per step, plus more for errors, plus more for the current step index. By the time I had a working draft, I had thirteen useState calls that couldn't talk to each other without me writing the coordination logic manually.

I stared at it for a long time. Then I deleted all of it and wrote one useReducer.

Everything became cleaner. The state transitions were explicit. The debugging was straightforward. The tests were obvious. The next developer who opened that file — including future me, three months later — could understand the form's state machine in five minutes.

That's when I understood the real question. Not "What does useReducer do?" — I knew that from the docs. The real question was: "how do I know I need useReducer instead of useState?" And that question doesn't live in any documentation.

Before We Start: The One Question That Changes Everything

Before reaching for any hook, ask: "What changes, and what needs to respond to that change?"

This sounds simple. It isn't. Most over-engineered React components exist because someone added a hook first and figured out the problem second. The hook then created its own complexity, which required another hook, which created more complexity.

The question forces you to define the problem before you pick the tool. A few minutes spent answering it correctly saves hours of debugging the wrong abstraction.

Let me show you what I mean as we go through each hook.

`useState` — The Entry Point and Its Limits

What changes: A single, independent piece of data within one component.

"If this value changes, does anything else in this component need to know about it or react to it?"

If the answer is "no" — useState is correct. If the answer is "yes, something else changes too" — you might be building a state machine that needs useReducer.

// useState is correct here:
// The count changes. Nothing else in the component needs to respond to that change.
// It's truly independent.

function LikeButton({ postId }: { postId: string }) {
  const [isLiked, setIsLiked] = useState(false);
  const [likeCount, setLikeCount] = useState(0);

  const handleLike = async () => {
    // Functional update form — non-negotiable when new state depends on previous
    // Without this, rapid clicks create stale closure bugs:
    // you click twice fast, both callbacks read isLiked = false,
    // both set it to true — the second click doesn't unlike
    setIsLiked(prev => !prev);
    setLikeCount(prev => prev + (isLiked ? -1 : 1));
    await toggleLike(postId);
  };

  return (
    <button onClick={handleLike}>
      {isLiked ? '❤️' : '🤍'} {likeCount}
    </button>
  );
}

Where useState starts to struggle:

// 🚩 The smell: multiple useState calls that always change together
// If you find yourself writing this, you're managing a state machine manually

function MultiStepForm() {
  const [step, setStep] = useState(1);
  const [isSubmitting, setIsSubmitting] = useState(false);
  const [errors, setErrors] = useState<Record<string, string>>({});
  const [formData, setFormData] = useState<FormData>({});
  const [isValid, setIsValid] = useState(false);

  // Now every handler needs to coordinate all five of these.
  // Welcome to the coordination tax.
  const handleNext = () => {
    // Validate current step
    const newErrors = validateStep(step, formData);
    setErrors(newErrors);
    setIsValid(Object.keys(newErrors).length === 0);
    if (Object.keys(newErrors).length === 0) {
      setStep(prev => prev + 1);
    }
  };
  // This is already fragile and we haven't written the submit handler yet.
}

When you see multiple pieces of state that always change together, or when one state change conditionally triggers another — that's useReducer territory.

`useReducer` — State Machines, Not Just Complex State

What changes: Multiple related pieces of state with explicit transitions between them.

"Can I describe this component's state as a set of named states with named transitions between them?"

If yes — useReducer. The reducer IS the state machine definition.

// Six steps of state. Now it's one reducer.
// Every possible state transition is named and explicit.

type FormStep = 1 | 2 | 3 | 4 | 5 | 6;

interface FormState {
  currentStep: FormStep;
  data: Partial<FormData>;
  errors: Record<string, string>;
  isSubmitting: boolean;
  isComplete: boolean;
}

type FormAction =
  | { type: 'NEXT_STEP'; payload: { stepData: Partial<FormData>; errors: Record<string, string> } }
  | { type: 'PREV_STEP' }
  | { type: 'UPDATE_FIELD'; payload: { field: string; value: unknown } }
  | { type: 'SUBMIT_START' }
  | { type: 'SUBMIT_SUCCESS' }
  | { type: 'SUBMIT_ERROR'; payload: string };

const initialFormState: FormState = {
  currentStep: 1,
  data: {},
  errors: {},
  isSubmitting: false,
  isComplete: false,
};

function formReducer(state: FormState, action: FormAction): FormState {
  switch (action.type) {
    case 'NEXT_STEP': {
      // State transition is explicit: you can only go to next step if no errors
      const hasErrors = Object.keys(action.payload.errors).length > 0;
      if (hasErrors) {
        return { ...state, errors: action.payload.errors };
      }
      return {
        ...state,
        currentStep: Math.min(6, state.currentStep + 1) as FormStep,
        data: { ...state.data, ...action.payload.stepData },
        errors: {},
      };
    }

    case 'PREV_STEP':
      return {
        ...state,
        currentStep: Math.max(1, state.currentStep - 1) as FormStep,
        errors: {}, // Clear errors when going back — intentional UX decision
      };

    case 'UPDATE_FIELD':
      return {
        ...state,
        data: { ...state.data, [action.payload.field]: action.payload.value },
        // Clear the error for this field as the user types — live validation
        errors: { ...state.errors, [action.payload.field]: '' },
      };

    case 'SUBMIT_START':
      return { ...state, isSubmitting: true, errors: {} };

    case 'SUBMIT_SUCCESS':
      return { ...state, isSubmitting: false, isComplete: true };

    case 'SUBMIT_ERROR':
      return {
        ...state,
        isSubmitting: false,
        // Show a general error at the current step
        errors: { form: action.payload },
      };

    default:
      return state;
  }
}

// The component is now clean.
// All the coordination logic is in the reducer — testable in isolation.
function MultiStepForm() {
  const [state, dispatch] = useReducer(formReducer, initialFormState);

  const handleNext = () => {
    const stepData = getCurrentStepData(state.currentStep, state.data);
    const errors = validateStep(state.currentStep, stepData);
    dispatch({ type: 'NEXT_STEP', payload: { stepData, errors } });
  };

  return (
    <div>
      <StepIndicator current={state.currentStep} total={6} />
      <StepContent
        step={state.currentStep}
        data={state.data}
        errors={state.errors}
        onFieldChange={(field, value) =>
          dispatch({ type: 'UPDATE_FIELD', payload: { field, value } })
        }
      />
      <FormNavigation
        onNext={handleNext}
        onBack={() => dispatch({ type: 'PREV_STEP' })}
        isSubmitting={state.isSubmitting}
        currentStep={state.currentStep}
        totalSteps={6}
      />
    </div>
  );
}

The test that tells you if your reducer is well-designed: Can you test every state transition without mounting a component? If yes — you've separated your logic from your UI correctly. The reducer is pure. The component is dumb.

// Test the reducer in isolation — no React, no render, no DOM
describe('formReducer', () => {
  it('does not advance to next step when errors exist', () => {
    const state = formReducer(initialFormState, {
      type: 'NEXT_STEP',
      payload: {
        stepData: {},
        errors: { name: 'Name is required' },
      },
    });

    expect(state.currentStep).toBe(1); // Stayed on step 1
    expect(state.errors.name).toBe('Name is required');
  });

  it('clears errors when going back', () => {
    const stateWithErrors: FormState = {
      ...initialFormState,
      currentStep: 2,
      errors: { email: 'Invalid email' },
    };

    const state = formReducer(stateWithErrors, { type: 'PREV_STEP' });
    expect(state.errors).toEqual({});
    expect(state.currentStep).toBe(1);
  });
});

`useEffect` — The Most Misused Hook in React

What changes: Something outside React's rendering model needs to synchronize with your component's state.

"Am I synchronizing with something external — DOM, API, timer, subscription, browser API? Or am I just computing a value?"

If you're computing a value — don't use useEffect. Compute it inline or use useMemo. useEffect is for synchronization, not computation.

// 🚩 The most common useEffect mistake: using it for derived state
function UserGreeting({ user }: { user: User }) {
  const [greeting, setGreeting] = useState('');

  // Wrong: This is not synchronization. It's computation.
  // Every render: compute greeting → trigger re-render → compute greeting again
  // That's a render cycle for zero reason.
  useEffect(() => {
    setGreeting(`Hello, ${user.name.split(' ')[0]}!`);
  }, [user.name]);

  return <h1>{greeting}</h1>;
}

// ✅ Correct: Compute inline. No useEffect needed.
function UserGreeting({ user }: { user: User }) {
  const greeting = `Hello, ${user.name.split(' ')[0]}!`;
  return <h1>{greeting}</h1>;
}

// ✅ useEffect is correct here: synchronizing with an external system (browser API)
function useDocumentTitle(title: string) {
  useEffect(() => {
    const previousTitle = document.title;
    document.title = title;

    // Cleanup: restore the previous title when component unmounts
    // or when title changes. This is the cleanup function doing real work.
    return () => {
      document.title = previousTitle;
    };
  }, [title]);
}

// ✅ useEffect is correct here: subscribing to an external event
function useOnlineStatus() {
  const [isOnline, setIsOnline] = useState(navigator.onLine);

  useEffect(() => {
    const handleOnline = () => setIsOnline(true);
    const handleOffline = () => setIsOnline(false);

    window.addEventListener('online', handleOnline);
    window.addEventListener('offline', handleOffline);

    // Cleanup: remove listeners when component unmounts.
    // Without this, the handlers remain attached to the window
    // even after the component is gone — a memory leak.
    return () => {
      window.removeEventListener('online', handleOnline);
      window.removeEventListener('offline', handleOffline);
    };
  }, []); // Empty array: subscribe once on mount, unsubscribe on unmount

  return isOnline;
}

The AbortController pattern — the one most tutorials skip:

// Data fetching in useEffect — the complete, production-safe version
function useUserData(userId: string) {
  const [user, setUser] = useState<User | null>(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    // AbortController lets us cancel the request if:
    // 1. The component unmounts before the request completes
    // 2. userId changes before the first request completes
    // Without this, a fast userId change causes a race condition:
    // request for user A resolves AFTER request for user B,
    // and you render user A's data for user B's profile.
    const controller = new AbortController();

    const fetchUser = async () => {
      setIsLoading(true);
      setError(null);

      try {
        const response = await fetch(`/api/users/${userId}`, {
          signal: controller.signal, // Link this request to the AbortController
        });

        if (!response.ok) throw new Error('Failed to fetch');

        const data: User = await response.json();
        setUser(data);
      } catch (err) {
        // AbortError is expected and not a real error — the component
        // unmounted or userId changed. Don't show an error for this.
        if (err instanceof Error && err.name === 'AbortError') return;
        setError(err instanceof Error ? err.message : 'Unknown error');
      } finally {
        setIsLoading(false);
      }
    };

    fetchUser();

    // Cleanup: abort the in-flight request
    return () => controller.abort();
  }, [userId]);

  return { user, isLoading, error };
}

`useContext` — Sharing State Without Prop Drilling

The diagnostic question: "Is this value needed by components that are far apart in the tree AND changes infrequently?"

Both conditions matter. useContext is efficient for infrequently changing values. For highly dynamic state that changes on every keystroke, it causes performance issues — every consumer re-renders when the context value changes.

// ✅ Good useContext usage: theme changes rarely, needed everywhere
// ThemeContext.tsx

type Theme = 'light' | 'dark';

interface ThemeContextValue {
  theme: Theme;
  toggleTheme: () => void;
}

const ThemeContext = createContext<ThemeContextValue | null>(null);

export function ThemeProvider({ children }: { children: ReactNode }) {
  const [theme, setTheme] = useState<Theme>(() => {
    // Initialize from localStorage — the inline script handles first paint
    try {
      return (localStorage.getItem('theme') as Theme) ?? 'light';
    } catch {
      return 'light';
    }
  });

  const toggleTheme = useCallback(() => {
    setTheme(prev => {
      const next = prev === 'light' ? 'dark' : 'light';
      try { localStorage.setItem('theme', next); } catch {}
      document.documentElement.setAttribute('data-theme', next);
      return next;
    });
  }, []);

  // Memoize the context value to prevent unnecessary re-renders of all consumers
  // when the ThemeProvider's parent re-renders but theme hasn't changed
  const value = useMemo(() => ({ theme, toggleTheme }), [theme, toggleTheme]);

  return <ThemeContext.Provider value={value}>{children}</ThemeContext.Provider>;
}

// Always wrap useContext in a custom hook — two reasons:
// 1. Throws a clear error if used outside the provider (beats a cryptic undefined error)
// 2. Hides the Context implementation — consumers don't need to import ThemeContext
export function useTheme() {
  const context = useContext(ThemeContext);
  if (!context) throw new Error('useTheme must be used within ThemeProvider');
  return context;
}

// 🚩 useContext performance trap: high-frequency updates in context
// This causes EVERY consumer to re-render on every keystroke

const SearchContext = createContext<{ query: string; setQuery: (q: string) => void } | null>(null);

function SearchProvider({ children }: { children: ReactNode }) {
  const [query, setQuery] = useState('');
  // Every time query changes (every keystroke), ALL consumers re-render.
  // If there are 20 components consuming SearchContext, that's 20 re-renders per keystroke.
  return (
    <SearchContext.Provider value={{ query, setQuery }}>
      {children}
    </SearchContext.Provider>
  );
}

// ✅ Better: keep high-frequency state local, pass callbacks up deliberately
// Or use a state management library (Zustand) that supports selective subscriptions

`useCallback` and `useMemo` — Performance Tools, Not Default Habits

I've seen codebases where every function was wrapped in useCallback "for performance." The profiler showed zero improvement in re-render counts. What it showed was slightly longer render times — from the dependency array comparisons on every render.

"Is this function passed as a prop to a component wrapped in React.memo? Or used as a dependency in a useEffect?"

If neither — useCallback adds overhead with no benefit.

"Is this computation genuinely expensive (sorting thousands of items, complex math), AND does it run on every render?"

If the computation is cheap (string concatenation, simple filtering of small arrays) — useMemo adds overhead with no benefit.

// 🚩 useCallback that helps nothing
function ParentComponent() {
  const [count, setCount] = useState(0);

  // This function is memoized — but Child is not wrapped in React.memo.
  // React.memo is what makes stable references matter.
  // Without it, Child re-renders whenever Parent re-renders regardless.
  // You're paying the memoization cost for zero benefit.
  const handleClick = useCallback(() => {
    console.log('clicked', count);
  }, [count]);

  return <Child onClick={handleClick} />; // Child is NOT React.memo
}

// ✅ useCallback that earns its place
const Child = React.memo(({ onClick }: { onClick: () => void }) => {
  // React.memo: only re-render if props change reference.
  // Now the stable reference from useCallback actually prevents re-renders.
  console.log('Child rendered');
  return <button onClick={onClick}>Click</button>;
});

function ParentComponent() {
  const [count, setCount] = useState(0);
  const [unrelated, setUnrelated] = useState(0);

  // useCallback is justified here:
  // - Child is wrapped in React.memo
  // - stable reference → Child doesn't re-render when `unrelated` changes
  const handleClick = useCallback(() => {
    console.log('clicked', count);
  }, [count]);

  return (
    <div>
      <button onClick={() => setUnrelated(u => u + 1)}>
        Change unrelated ({unrelated})
      </button>
      <Child onClick={handleClick} />
      {/* Child does NOT re-render when unrelated changes */}
    </div>
  );
}

// useMemo: the right use case
function ProductList({ products, filters }: { products: Product[]; filters: Filters }) {
  // Filtering 10,000 products on every render is expensive.
  // useMemo ensures this only runs when products or filters actually change.
  const filteredProducts = useMemo(() => {
    return products
      .filter(p => !filters.category || p.category === filters.category)
      .filter(p => p.price >= filters.minPrice && p.price <= filters.maxPrice)
      .sort((a, b) => {
        if (filters.sortBy === 'price') return a.price - b.price;
        return a.name.localeCompare(b.name);
      });
  }, [products, filters]); // Only recalculate when these change

  return (
    <div>
      {filteredProducts.map(product => (
        <ProductCard key={product.id} product={product} />
      ))}
    </div>
  );
}

The rule: profile first. Optimize second. React DevTools Profiler shows you which components re-render and how expensive they are. Every optimization decision should be backed by a profile, not a feeling.

`useRef` — Escaping React Without Losing Your Mind

What changes: Something that needs to persist between renders but should NOT trigger a re-render when it changes.

"Do I need to access a DOM element directly, OR do I need to store a mutable value that shouldn't cause re-renders?"

// Use case 1: DOM access
function VideoPlayer({ src }: { src: string }) {
  const videoRef = useRef<HTMLVideoElement>(null);

  const handlePlay = () => {
    // Direct DOM access — can't be done with state
    videoRef.current?.play();
  };

  const handlePause = () => {
    videoRef.current?.pause();
  };

  return (
    <div>
      <video ref={videoRef} src={src} />
      <button onClick={handlePlay}>Play</button>
      <button onClick={handlePause}>Pause</button>
    </div>
  );
}

// Use case 2: Storing a mutable value without re-render
function useInterval(callback: () => void, delay: number) {
  const savedCallback = useRef(callback);

  // Keep the ref up to date without causing re-renders
  useEffect(() => {
    savedCallback.current = callback;
  }, [callback]);

  useEffect(() => {
    const id = setInterval(() => savedCallback.current(), delay);
    // Cleanup: clear the interval when the component unmounts or delay changes
    return () => clearInterval(id);
  }, [delay]);
}

// Use case 3: Tracking previous values
function usePreview<T>(value: T): T | undefined {
  const ref = useRef<T>();

  useEffect(() => {
    ref.current = value; // Store current value after render
  });

  return ref.current; // Return the value from the PREVIOUS render
}

`useTransition` — Making the UI Lie (In the Best Way)

What changes: A state update that's expensive to compute, AND the user needs the input to remain responsive.

"Is there a fast interaction (typing, clicking) that triggers a slow render? And is it okay to show the old UI briefly while the new one computes?"

This is where the mental model matters. useTransition doesn't make the computation faster. It makes React deprioritize it — keeping the input responsive while the heavy update runs in the background. The UI briefly shows "stale" data, which is usually fine.

// Without useTransition: typing in the search input feels laggy
// because every keystroke triggers an expensive filter of 50,000 items
// and the browser hangs until it's done.

// With useTransition: typing is instant. The results update a moment later.
// The user sees smooth input. The results follow. That's the right UX.

function ProductSearch({ products }: { products: Product[] }) {
  const [inputValue, setInputValue] = useState('');
  const [searchQuery, setSearchQuery] = useState('');
  const [isPending, startTransition] = useTransition();

  const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    // This update is instant — input stays responsive
    setInputValue(e.target.value);

    // This update is a transition — React can deprioritize it
    // if there are more urgent updates (like the next keystroke)
    startTransition(() => {
      setSearchQuery(e.target.value);
    });
  };

  // This expensive computation only runs when searchQuery changes
  // (which is deferred), not when inputValue changes (which is instant)
  const results = useMemo(() => {
    if (!searchQuery) return products;
    return products.filter(p =>
      p.name.toLowerCase().includes(searchQuery.toLowerCase()) ||
      p.description.toLowerCase().includes(searchQuery.toLowerCase())
    );
  }, [products, searchQuery]);

  return (
    <div>
      <input
        value={inputValue}
        onChange={handleChange}
        placeholder="Search products..."
      />
      {/* isPending = the deferred update is still computing */}
      {/* Don't use a full loading spinner here — it's jarring for fast transitions */}
      {/* A subtle opacity change communicates "updating" without disrupting the user */}
      <div style={{ opacity: isPending ? 0.6 : 1, transition: 'opacity 0.1s' }}>
        <p>{results.length} results</p>
        {results.map(product => (
          <ProductCard key={product.id} product={product} />
        ))}
      </div>
    </div>
  );
}

The difference between useTransition and useDeferredValue:

Both solve the "fast input, slow render" problem. The difference is where you apply the optimization:

useTransition — you control when the expensive state update happens. Use when you own the state update.
useDeferredValue — you defer a value you received (from props or state). Use when you don't control the update.

// useDeferredValue: when you receive a value from outside and can't control when it changes
function SearchResults({ query }: { query: string }) {
  // query comes from a parent — we don't control when it changes.
  // useDeferredValue gives us a version of query that React will
  // deprioritize updating, keeping the parent's UI responsive.
  const deferredQuery = useDeferredValue(query);

  const results = useMemo(() => expensiveSearch(deferredQuery), [deferredQuery]);

  // isStale = the deferred value hasn't caught up to the real value yet
  const isStale = query !== deferredQuery;

  return (
    <div style={{ opacity: isStale ? 0.7 : 1 }}>
      {results.map(r => <SearchResult key={r.id} result={r} />)}
    </div>
  );
}

`useOptimistic` — Telling the User "Done" Before It Is

What changes: The UI should reflect a user action immediately — before the server confirms it.

"If the server call takes 1 second, should the user wait for the UI to update, or should the UI update immediately and roll back if it fails?"

Almost always the answer is "update immediately." Waiting for server confirmation before showing feedback is a UX pattern from 2010. Modern users expect instant feedback.

// A like button that feels instant — because it is

interface Post {
  id: string;
  content: string;
  likeCount: number;
  isLikedByUser: boolean;
}

async function toggleLikeApi(postId: string, currentlyLiked: boolean): Promise<void> {
  const response = await fetch(`/api/posts/${postId}/like`, {
    method: currentlyLiked ? 'DELETE' : 'POST',
  });
  if (!response.ok) throw new Error('Failed to toggle like');
}

function LikeButton({ post }: { post: Post }) {
  const [actualPost, setActualPost] = useState(post);

  // useOptimistic takes:
  // 1. The actual state (what the server knows)
  // 2. A function to compute the optimistic state (what we show immediately)
  const [optimisticPost, setOptimisticLike] = useOptimistic(
    actualPost,
    (currentPost, isLiking: boolean) => ({
      ...currentPost,
      isLikedByUser: isLiking,
      likeCount: currentPost.likeCount + (isLiking ? 1 : -1),
    })
  );

  const handleLike = async () => {
    const isCurrentlyLiked = optimisticPost.isLikedByUser;

    // Step 1: Show the result immediately in the UI
    setOptimisticLike(!isCurrentlyLiked);

    try {
      // Step 2: Tell the server
      await toggleLikeApi(post.id, isCurrentlyLiked);

      // Step 3: Update the actual state to match
      setActualPost(prev => ({
        ...prev,
        isLikedByUser: !isCurrentlyLiked,
        likeCount: prev.likeCount + (isCurrentlyLiked ? -1 : 1),
      }));
    } catch {
      // Step 4 (on failure): useOptimistic automatically reverts to actualPost
      // The UI snaps back to the actual state. User sees a brief flash of the revert.
      // Show a toast notification explaining the failure.
      console.error('Like failed — UI reverted automatically');
    }
  };

  return (
    <button
      onClick={handleLike}
      aria-label={optimisticPost.isLikedByUser ? 'Unlike post' : 'Like post'}
    >
      {optimisticPost.isLikedByUser ? '❤️' : '🤍'} {optimisticPost.likeCount}
    </button>
  );
}

The mental model for useOptimistic: think of it as a temporary overlay on your real state. You apply the overlay immediately. The real state catches up when the server responds. If the server fails, the overlay is removed and you're back to real state. The "magic" is that you never have to write the revert logic — it's built in.

Custom Hooks — The Real Power Move

Everything above becomes dramatically more powerful when you extract it into custom hooks. A custom hook is just a function that uses hooks — but it's the architectural tool that makes React logic reusable, testable, and composable.

// usePostActions.ts
// Encapsulates all the logic for interacting with a post.
// The component that uses this doesn't know about API calls,
// optimistic state, error handling, or state management.
// It just calls functions and reads state.

interface UsePostActionsReturn {
  post: Post;
  handleLike: () => Promise<void>;
  handleBookmark: () => Promise<void>;
  isLiking: boolean;
  isBookmarking: boolean;
}

export function usePostActions(initialPost: Post): UsePostActionsReturn {
  const [actualPost, setActualPost] = useState(initialPost);
  const [isLiking, setIsLiking] = useState(false);
  const [isBookmarking, setIsBookmarking] = useState(false);

  const [optimisticPost, applyOptimistic] = useOptimistic(
    actualPost,
    (post, action: { type: 'like' | 'bookmark'; value: boolean }) => {
      if (action.type === 'like') {
        return {
          ...post,
          isLikedByUser: action.value,
          likeCount: post.likeCount + (action.value ? 1 : -1),
        };
      }
      return { ...post, isBookmarkedByUser: action.value };
    }
  );

  const handleLike = async () => {
    const newValue = !optimisticPost.isLikedByUser;
    setIsLiking(true);
    applyOptimistic({ type: 'like', value: newValue });
    try {
      await toggleLikeApi(initialPost.id, !newValue);
      setActualPost(prev => ({
        ...prev,
        isLikedByUser: newValue,
        likeCount: prev.likeCount + (newValue ? 1 : -1),
      }));
    } catch {
      // Optimistic state reverts automatically
    } finally {
      setIsLiking(false);
    }
  };

  const handleBookmark = async () => {
    const newValue = !optimisticPost.isBookmarkedByUser;
    setIsBookmarking(true);
    applyOptimistic({ type: 'bookmark', value: newValue });
    try {
      await toggleBookmarkApi(initialPost.id, !newValue);
      setActualPost(prev => ({ ...prev, isBookmarkedByUser: newValue }));
    } catch {
      // Optimistic state reverts automatically
    } finally {
      setIsBookmarking(false);
    }
  };

  return {
    post: optimisticPost,
    handleLike,
    handleBookmark,
    isLiking,
    isBookmarking,
  };
}

// The component is now trivially simple.
// All complexity is in the hook — testable without mounting a component.
function PostCard({ post }: { post: Post }) {
  const { post: postState, handleLike, handleBookmark } = usePostActions(post);

  return (
    <article>
      <p>{postState.content}</p>
      <button onClick={handleLike}>
        {postState.isLikedByUser ? '❤️' : '🤍'} {postState.likeCount}
      </button>
      <button onClick={handleBookmark}>
        {postState.isBookmarkedByUser ? '🔖' : '📄'}
      </button>
    </article>
  );
}

Here's the thing nobody says at the end of a hooks guide:

Most React performance problems I've seen in production are not solved by hooks. They're solved by moving state closer to where it's used.

The single most impactful architectural change in most React codebases isn't "add useCallback here" or "wrap this in useMemo."This state is being managed three levels up when it's only used one level down move it."

A state that lives too high in the tree re-renders too many components. Before reaching for useCallback "to prevent re-renders," ask, "Why does this parent re-render when this child's data changes?" The answer is usually "because the state is in the wrong place."

State colocation—keeping state as close as possible to where it's used—is the optimization that costs nothing and delivers the most. It's not a hook. It's a thinking habit.

Master the hooks. But don't forget the thinking habit.

Always remember > "The best code is no code at all." > — Jeff Atwood > > Why this stays with me: Every hook you add is code. The best React components are the ones that reach for the simplest hook that solves the problem — and stop there.

The Unfinished Chapter

Here's what I'm still working through:

The line between "use useOptimistic" and "use a proper state management solution with optimistic update support" is blurry to me in practice. For a simple case, a like button and a single field update useOptimistic is clean and sufficient. For complex cases, a multi-field form that updates a nested data structure with partial success handling, I've found myself reinventing things that libraries like Zustand or React Query handle better.

My current heuristic: if the optimistic update involves more than one data entity, or if failure recovery is complex, reach for a library. If it's a single action with a clear success/failure boundary, useOptimistic is enough.

But I've been wrong about this heuristic at least twice. Where do you draw the line?

I built the multi-step form six years ago. The useReducerrefactor was the moment hooks stopped being a feature I used and started being a way I thought.

That's what I want for you. Not memorization of the API. A change in how you think about problems before you write the first line. The diagnostic questions in this article are the questions I ask now automatically — not because I'm smart, but because I've shipped enough broken components to have learned which question to ask first.

Use the hook that fits the problem. Use the simplest hook that fits the problem. And know when not to use a hook at all.

Simple? Yes. Takes years to feel natural. Welcome to the craft.

✨ Let's keep the conversation going!

If you found this interesting, I'd love for you to check out more of my work or just drop in to say hello.

✍️ Read more on my blog: bishoy-bishai.github.io

☕ Let's chat on LinkedIn: linkedin.com/in/bishoybishai

📘 Curious about AI?: You can also check out my book. Surrounded by AI

Next.js App Router Complete Guide: From Basics to Advanced Patterns

Bishoy Bishai — Mon, 04 May 2026 12:13:54 +0000

Navigating the Future: A Complete Guide to Next.js App Router for Professional Teams

Remember the days of wrestling with complex data fetching, managing API calls on the client, and constantly optimizing bundle sizes? We've all been there. It's a familiar challenge for any team building ambitious web applications. When Next.js introduced the App Router, I've heard everything from "this is a game-changer" to "just another thing to learn." But in my experience, especially working with larger engineering teams, it's undeniably the path forward for building truly performant, scalable, and maintainable React applications.

Here's the thing about the App Router: it’s not just a tweak; it’s a paradigm shift. It brings React Server Components (RSC) to the forefront, pushing us towards a more server-centric mental model that deeply impacts how we structure, fetch data, and ultimately deliver user experiences. If you've been on the fence, or felt overwhelmed, consider this your practical, real-world guide from someone who's shipped complex features with it.

The Core Shift: Server vs. Client Components – It’s Not Just an Optimization, It’s an Architecture

The most fundamental concept to grasp is the clear delineation between Server Components and Client Components. This isn't just about rendering speed; it's about responsibilities.

Server Components (Default): These are rendered on the server, have direct access to backend resources (databases, file system), zero bundle size, and never re-render in the browser. They're perfect for fetching data, complex business logic, or static content. Think of them as your backend for UI, running just before the HTML is streamed to the user.

Client Components ('use client'): These are rendered on the client, allow for interactivity (hooks like useState, useEffect, event listeners), and send their JavaScript to the browser. They are your interactive UI elements.

My Key Insight: Don't think of 'use client' as an opt-in for interactivity; think of it as an opt-out from server-side superpowers. Your default should always be a Server Component. Only mark a component as a Client Component if it absolutely needs browser APIs, state, or interactivity. This small mental flip will save you from shipping unnecessary JavaScript.

// app/page.tsx (Server Component by default)
import { fetchProducts } from '../lib/data'; // Server-side data fetching

export default async function HomePage() {
  const products = await fetchProducts(); // Direct database query or API call

  return (
    <div>
      <h1>Welcome to our store!</h1>
      <ProductList products={products} /> {/* This can be a Server Component too */}
      <AddToCartButton productId="123" /> {/* This *needs* to be a Client Component */}
    </div>
  );
}

// components/AddToCartButton.tsx (Client Component)
'use client';

import { useState } from 'react';

export default function AddToCartButton({ productId }: { productId: string }) {
  const [quantity, setQuantity] = useState(1);

  const handleClick = () => {
    // Logic to add to cart, maybe a client-side API call
    console.log(`Adding ${quantity} of product ${productId} to cart`);
  };

  return (
    <div>
      <input
        type="number"
        value={quantity}
        onChange={(e) => setQuantity(Number(e.target.value))}
        min="1"
      />
      <button onClick={handleClick}>Add to Cart</button>
    </div>
  );
}

Data Fetching: A New Horizon of Performance

This is where the App Router truly shines. With Server Components, data fetching moves to where it belongs: the server.

async/await in Server Components: You can now directly await promises in your components. No more useEffect for initial data loads! This means less boilerplate, clearer data flow, and no waterfall requests between client and server.
Automatic Caching and De-duping: Next.js automatically caches fetch requests and de-duplicates them across components, even parallel requests. This is a massive performance win you get out of the box.
Streaming UI: Imagine sending parts of your HTML as soon as they're ready, rather than waiting for all data to load. With loading.tsx and React's Suspense boundaries, you can achieve this effortlessly, improving perceived performance significantly.

Lesson Learned: Initially, I saw teams reach for client-side data fetching libraries like SWR or React Query out of habit. While these still have their place for client-side mutations or real-time updates, for initial server-rendered data, embrace the async/await pattern. It simplifies your stack dramatically.

// app/dashboard/page.tsx
import { Suspense } from 'react';
import UserProfile from './UserProfile';
import RecentOrders from './RecentOrders';
import { SkeletonCard } from '@/components/ui/skeleton-card'; // Example loading state

export default async function DashboardPage() {
  return (
    <main>
      <h1>Your Dashboard</h1>
      <Suspense fallback={<SkeletonCard title="Loading Profile..." />}>
        <UserProfile /> {/* Fetches user data on server */}
      </Suspense>
      <Suspense fallback={<SkeletonCard title="Loading Orders..." />}>
        <RecentOrders /> {/* Fetches order data on server */}
      </Suspense>
    </main>
  );
}

Routing and Layouts: Nested and Powerful

The file-system based routing of the App Router is incredibly intuitive, promoting discoverable, maintainable code.

layout.tsx: Defines shared UI for a segment and its children.
page.tsx: The unique UI of a route segment.
loading.tsx: Provides an immediate loading state for a segment, shown while its children load.
error.tsx: Catches errors in a route segment and renders a fallback UI.
template.tsx: Similar to layout.tsx but creates a new instance for each navigation, useful for specific transition animations.

Pitfall to Avoid: Over-nesting layouts without clear purpose. While powerful, too many nested layouts can make it harder to reason about the overall structure. Plan your UI hierarchy carefully, identifying truly shared components versus those that simply happen to be present on multiple pages.

Advanced Patterns & Pitfalls

Passing Props from Server to Client Components: You can pass serializable props from a Server Component to a Client Component. This is your primary mechanism for hydrating client-side interactivity with server-fetched data. Just be mindful of what you pass – functions, dates, or complex objects that aren't JSON-serializable won't work without specific serialization.

use server for Server Actions: This is a huge one for building truly full-stack apps. use server lets you define server-side functions that can be directly called from Client Components without explicitly creating an API route. It's like RPC (Remote Procedure Call) for your React components. I've found this pattern to drastically reduce boilerplate for form submissions and mutations.

// app/actions.ts
'use server';

import { revalidatePath } from 'next/cache';

export async function createPost(formData: FormData) {
  const title = formData.get('title');
  const content = formData.get('content');
  // ... save to database
  console.log('Post created:', { title, content });
  revalidatePath('/blog'); // Revalidate the blog page cache
}

```typescript
// components/PostForm.tsx
'use client';

import { createPost } from '@/app/actions';

export default function PostForm() {
  return (
    <form action={createPost}>
      <input type="text" name="title" placeholder="Title" required />
      <textarea name="content" placeholder="Content" required />
      <button type="submit">Create Post</button>
    </form>
  );
}
```

Hydration Errors: This often happens when the server-rendered HTML doesn't match what the client-side JavaScript tries to render. A common culprit is client-side code that relies on browser APIs (like window or localStorage) during the initial render. Always wrap such code in useEffect or ensure the component is a Client Component and any non-matching content is conditionally rendered after hydration.

Wrapping Up: Embrace the New Mindset

The Next.js App Router, powered by React Server Components, is a powerful leap forward. It redefines the mental model for building React applications, pushing more logic to the server, and in doing so, significantly enhances performance, reduces client-side JavaScript, and simplifies data fetching.

It will require a shift in how your team thinks about component responsibilities. Start small, experiment, and constantly ask yourself: "Does this component really need client-side interactivity?" If not, keep it a Server Component. Embrace the async/await data fetching, leverage Suspense for streaming, and explore Server Actions for powerful RPC-like mutations. The learning curve is real, but the benefits – a faster, more robust, and easier-to-maintain application – are immense. Your users (and your future self) will thank you.

✨ Let's keep the conversation going!

If you found this interesting, I'd love for you to check out more of my work or just drop in to say hello.

✍️ Read more on my blog: bishoy-bishai.github.io

☕ Let's chat on LinkedIn: linkedin.com/in/bishoybishai

How React Works (Part 2)? Why React Had to Build Its Own Execution Engine

Bishoy Bishai — Sat, 02 May 2026 11:30:51 +0000

Decoding React's Engine: Why It Built Its Own Scheduler

Ever built a React app that, despite all your best efforts, just felt a little… janky? Maybe a complex animation stutters, or a rapid state update feels less than immediate. We've all been there. It’s frustrating when you know you’re using a "fast" framework, yet the user experience isn't quite buttery smooth. The truth is, sometimes the bottleneck isn't your code logic, but a fundamental challenge React faces when interacting with the browser itself.

In my experience, many developers understand React's component model, props, state, and hooks. That’s "Part 1" of how React works. But understanding why React had to build its own sophisticated execution engine – the Fiber reconciler – and how it orchestrates updates, is "Part 2." It's where the real magic, and the deepest insights into performance, lie.

The Browser's Dilemma: Why React Needed Its Own Path

Here's the thing: browsers were not initially designed for the highly dynamic, component-driven UIs we build today. Their DOM (Document Object Model) API, while functional, is inherently slow and blocking. Every time you manipulate the DOM directly – adding an element, changing a style, updating text – the browser might have to perform costly operations like recalculating layouts (reflows) and redrawing pixels (repaints). Do too much of this in quick succession, and your JavaScript execution thread gets tied up, blocking user input, freezing animations, and leading to that dreaded "jank."

Imagine you have a complex dashboard with many widgets updating simultaneously. If each widget tried to update the DOM independently and immediately, the browser would be overwhelmed, constantly reflowing and repainting. The UI would flicker and become unresponsive. This is the core problem React set out to solve: how to manage these updates efficiently and non-blockingly.

Enter the Virtual DOM: A Necessary Abstraction

React's initial answer was the Virtual DOM (VDOM). Instead of directly manipulating the browser's DOM, React builds a lightweight, in-memory JavaScript representation of your UI. When state changes, React builds a new VDOM tree and compares it to the previous one. This process, known as diffing or reconciliation, identifies the minimal set of changes required to update the actual browser DOM.

The genius here is that diffing the VDOM is incredibly fast because it's just plain JavaScript objects. Only after it figures out exactly what needs to change does it apply those changes in a single, optimized batch to the real DOM. This dramatically reduces costly browser operations.

But simply knowing what to change isn’t enough. The when and how those changes are applied is equally crucial, especially for complex applications. This is where React's custom execution engine truly shines.

The Heart of the Engine: React Fiber

The reconciliation algorithm itself underwent a massive re-architecture in React 16, moving from the "Stack" reconciler to Fiber. Fiber is the literal re-implementation of React's core algorithm. It’s an "execution engine" because it takes control of how and when your component updates are processed.

Think of React's update process in two main phases:

Render Phase (Reconciliation):
- React starts traversing your component tree, creating a new Fiber tree (a fancy internal representation of your UI).
- It calls your render methods (or functional component bodies) to figure out what should be on the screen.
- Crucially, this phase is interruptible. React can pause this work, yield control back to the browser (so it can process user input or perform animations), and then pick up where it left off. This cooperative scheduling is the superpower of Fiber.
- During this phase, side effects like DOM mutations should not happen, as the work might be aborted or re-done.
Commit Phase:
- Once the Render Phase completes and all changes are calculated, React moves to the Commit Phase.
- This phase is uninterruptible. React takes the calculated changes and applies them to the actual browser DOM.
- This is when effects like those in useEffect and useLayoutEffect are run, allowing you to interact with the real DOM.

Why Interruptible Work Matters

Imagine a user types rapidly into an input field while a large data fetch completes and triggers a massive UI update. With the old Stack reconciler, React would have to process the entire UI update before the browser could respond to the user's keystrokes. This leads to a noticeable delay.

With Fiber, React can process a chunk of the UI update, then check if there's any higher-priority work (like a user typing). If so, it pauses the UI update, lets the browser handle the input, and then resumes the UI update when the browser is idle again. This ensures that user interactions feel immediate and the UI remains responsive, even during heavy processing.

// A simple component to illustrate the concept
import React, { useState, useTransition } from 'react';

function BigList() {
  const [items, setItems] = useState(Array.from({ length: 10000 }, (_, i) => `Item ${i}`));
  const [filter, setFilter] = useState('');
  const [isPending, startTransition] = useTransition();

  const filteredItems = items.filter(item => item.includes(filter));

  const handleFilterChange = (event: React.ChangeEvent<HTMLInputElement>) => {
    // This part of the state update is "urgent" (for the input value)
    setFilter(event.target.value);

    // This part of the state update can be deferred (for filtering a large list)
    // React can pause this work if higher priority tasks (like more typing) come in.
    startTransition(() => {
      // Potentially expensive calculation here if it were inside the handler directly
      // With useTransition, React can prioritize rendering the input value first.
    });
  };

  return (
    <div>
      <input type="text" value={filter} onChange={handleFilterChange} placeholder="Filter items..." />
      {isPending && <span>Loading filtered items...</span>}
      <ul>
        {filteredItems.map(item => (
          <li key={item}>{item}</li>
        ))}
      </ul>
    </div>
  );
}

export default BigList;

In this example, useTransition explicitly tells React that the update to filteredItems can be deferred. React's Fiber engine will intelligently schedule this work, prioritizing immediate UI feedback (like updating the input field) over the potentially expensive list filtering, ensuring a smoother user experience.

The "Why": React Had to Build Its Own Execution Engine

So, why not just use existing browser APIs? The answer is granular control and fine-tuned scheduling. While browsers offer APIs like requestIdleCallback, they don't provide the level of control React needs to build its internal "Fiber tree," manage priorities, and flawlessly coordinate updates across a complex component hierarchy.

React built its own scheduler because:

JavaScript is single-threaded: It can only do one thing at a time. To prevent long-running tasks from blocking the UI, React needed a way to break up work and yield control back to the browser.
Browser APIs are too high-level: They don't expose the primitives needed for React's specific reconciliation and scheduling needs (e.g., pausing a component's render mid-way).
Cross-platform consistency: React aims to work consistently across web, mobile (React Native), and even VR. A custom engine allows for this unified approach.

Pitfalls and Practical Takeaways

Understanding Fiber and the two phases isn't just theoretical. It has real implications:

useEffect vs. useLayoutEffect: useEffect runs after the Commit Phase (after the browser has painted), making it non-blocking. useLayoutEffect runs synchronously after DOM mutations but before the browser paints, which is critical for measuring DOM elements or performing calculations that need to affect layout immediately. Misusing the latter can reintroduce jank.
Unnecessary Re-renders: While Fiber is efficient, calling setState too often with identical data still triggers the Render Phase, causing React to do unnecessary diffing. Tools like React.memo, useMemo, and useCallback are your allies here to help React skip work.
Keys in Lists: Forgetting key props on list items isn't just a warning; it directly impacts the diffing algorithm. Without stable keys, React can't efficiently identify moved, added, or removed items, leading to less optimal DOM updates and potential state bugs.
Batching: React often batches multiple setState calls that happen within the same event loop tick into a single update. This is an optimization powered by its scheduler, preventing multiple redundant re-renders.

Wrapping Up

React's custom execution engine, powered by Fiber, is a marvel of engineering. It's React’s way of saying, "The browser's default tools aren't quite enough for the rich UIs we want to build, so we're building our own highly optimized orchestrator." It ensures that even when your application is doing heavy lifting, the user experience remains responsive and delightful. By understanding this foundation, you gain a deeper appreciation for React’s magic and, more importantly, the knowledge to build truly high-performance, resilient applications.

✨ Let's keep the conversation going!

If you found this interesting, I'd love for you to check out more of my work or just drop in to say hello.

✍️ Read more on my blog: bishoy-bishai.github.io

☕ Let's chat on LinkedIn: linkedin.com/in/bishoybishai

I Let GitHub Copilot Define My React Standards for Six Months. Here's the Damage It Did.

Bishoy Bishai — Fri, 01 May 2026 11:43:30 +0000

AI doesn't invent bad code. It invents averageness — confidently, quickly, and at scale.

There's a specific kind of technical debt that doesn't show up in your linter.

It's not a bug. It's not a performance issue. It's not something your CI pipeline catches. It's the kind of debt where six months into a project, two developers open components that do the same thing — and neither can understand the other's approach. Both are "correct." Both would pass code review. But they feel like they were written by people who never spoke to each other.

In 2022, during the early months of the Passbase design system work, I watched this happen in real time. We had Copilot. We loved Copilot. We used Copilot for everything. And slowly, invisibly, Copilot became the de facto architect of our component patterns — not because we decided that, but because we never decided anything else.

A button component in one feature used interface for props. Another used type. One used React.FC<Props>. Another used the function signature directly. One had a Button/ folder with an index file. Another was just ButtonComponent.tsx sitting flat in components. All of them passed TypeScript. All of them worked. None of them felt like they belonged to the same codebase.

Copilot didn't cause this. We did. By treating every AI suggestion as a decision rather than an input, we outsourced our architectural thinking to a model trained on the average of the internet. And the internet's average is not your team's standard.

What you'll be able to DO after reading this:

Understand the specific psychological trap that makes AI tools drift toward architectural chaos
Build a React standard document that Copilot actually reinforces instead of undermines
Know which decisions must be made by humans and which ones AI can safely handle
Walk away with a folder structure, naming convention, and component pattern system you can ship to your team tomorrow

This is Pillar 2 content — for the senior developer who's been on the team long enough to see the drift, and wants to fix it before it becomes a rewrite.

The Psychological Trap Nobody Names

I want to spend time on the mechanism before the solution, because if you don't understand why this happens, you'll implement standards and watch them erode anyway.

Here's the trap: a suggestion that arrives pre-formed is harder to reject than a blank page.

When you open a new file and need to decide how to structure a component, you have a moment of creative friction. You think about the codebase. You think about the pattern used in the last three components you touched. You make a decision that's connected to context.

When Copilot opens that same file and immediately suggests a complete component structure, that friction disappears. The suggestion looks reasonable. It compiles. You accept it and move on.

What just happened? You didn't make a decision. You approved a default. And defaults, repeated across a team of five developers over six months, become the de facto standard — not because anyone chose it, but because nobody rejected it.

Picasso said: "Computers are useless. They can only give you answers."

He was being provocative, but the insight is precise. Copilot is extraordinarily good at answers. It will give you A valid component structure. A valid prop pattern. A valid hook. But "valid" is not "right for your context." Only you know your context. Only your team has the history of decisions that make one pattern better than another for your specific product.

The moment you stop asking "what should our standard be?" and start asking "what did Copilot suggest?" — you've given the architect's chair to a model that has never seen your codebase, never attended your design reviews, and never had to maintain the code it generated.

At Passbase, when I finally named this pattern to the team, the reaction was immediate recognition. Everyone had felt the drift. Nobody had named what was causing it.

What "Averageness at Scale" Looks Like

Let me show you the actual damage before I show you the fix.

This is what organic Copilot-driven drift looks like after six months on a real team:

src/components/
├── Button.tsx                    ← Developer A, month 1
├── ButtonComponent.tsx           ← Developer B, month 2 (same thing, different name)
├── PrimaryButton/
│   └── PrimaryButton.tsx         ← Developer C, month 3 (folder style)
├── ui/
│   └── button.tsx                ← Developer D, month 4 (shadcn influence)
└── IconButton.tsx                ← Developer A again, month 5 (forgot the folder pattern)

Five developers. Five buttons. Zero decisions. All of them "correct."

Now multiply this across forms, modals, inputs, cards, hooks, services, and API layers. You don't have a codebase. You have a collection of individually reasonable files that happen to be in the same repository.

The cost isn't the inconsistency itself — developers can read inconsistent code. The cost is the cognitive overhead of uncertainty. Every developer who opens a new file asks: "How should I do this?" And without a standard, the answer is always: "I'll see what Copilot suggests." Which perpetuates the problem.

This is Sultan Ibrahim in the cage. Not locked in by force — locked in by comfort. Why struggle with the decision when the suggestion is right there?

The Standard Document: What It Contains and Why

The solution isn't to turn off Copilot. It's to give Copilot something to accelerate.

A standard document is a decision record — the output of the architectural conversations your team should be having explicitly, written down so they don't have to be re-litigated every time someone opens a new file.

Here's ours. Not as a template to copy — as a worked example to understand.

1. Folder Structure — The First Decision That Shapes Everything

Your folder structure is an architectural statement. It says: "This is how we think about our application." Get this wrong and every subsequent decision builds on a shaky foundation.

src/
├── app/                    # App shell — routing, global layout, providers
│   ├── layout.tsx          # Root layout
│   ├── router.tsx          # Route definitions
│   └── providers.tsx       # Context providers stacked here, not scattered
│
├── components/             # Shared UI primitives — NO business logic here
│   ├── Button/
│   │   ├── Button.tsx      # The component
│   │   ├── Button.test.tsx # Tests live next to what they test
│   │   └── index.ts        # Re-export for clean imports
│   ├── Input/
│   ├── Modal/
│   └── index.ts            # Barrel export for all shared components
│
├── features/               # Domain features — business logic lives here
│   ├── Auth/
│   │   ├── components/     # Components only used inside Auth
│   │   ├── hooks/          # Hooks only used inside Auth
│   │   ├── services/       # API calls only used inside Auth
│   │   ├── types.ts        # Types only used inside Auth
│   │   └── AuthPage.tsx    # The page component
│   ├── UserProfile/
│   └── Dashboard/
│
├── hooks/                  # Reusable hooks — NO feature-specific logic
├── services/               # API layer — all fetch calls go through here
├── types/                  # Global TypeScript types
├── utils/                  # Pure helper functions
└── main.tsx

The decision this encodes: business logic belongs in features/, not in components/. A button doesn't know about authentication. An auth form doesn't belong in components/. This boundary is the single most important architectural decision in the document — because it determines where every future file goes.

Why Copilot violates this without guidance: Copilot looks at the nearest files for context. If you're in features/Auth/ and ask for a button, it might generate a button component right there — not because it's wrong, but because it doesn't know your folder structure convention. Without the standard, the developer accepts it. With the standard, the developer knows to reach for components/Button/ instead.

2. Naming Conventions — The Decisions That Eliminate a Thousand Arguments

// ✅ Our conventions — written down once, never debated again

// Components: PascalCase, noun-based
// ✅ UserProfileCard.tsx
// ✅ AuthenticationForm.tsx
// ❌ userProfileCard.tsx
// ❌ UserProfileCardComponent.tsx  ← "Component" suffix is redundant
// ❌ UPCard.tsx  ← Abbreviations are hidden knowledge

// Props interfaces: ComponentNameProps
// ✅ interface ButtonProps {}
// ✅ interface UserProfileCardProps {}
// ❌ interface IButtonProps {}  ← I-prefix is hungarian notation, we don't use it
// ❌ interface Props {}  ← Too generic, hard to search

// Custom hooks: always useNoun or useNounVerb
// ✅ useAuth
// ✅ useUserProfile
// ✅ useProductFilter
// ❌ useFetchUser  ← The "fetch" is an implementation detail, not the hook's identity

// Event handlers: always handleEventName
// ✅ handleSubmit, handleClick, handleFilterChange
// ❌ onSubmit (that's for the prop name, not the handler variable)
// ❌ submitForm, clickButton (verbs without "handle" prefix)

Why this matters more than it looks: naming conventions are how your team searches the codebase. If half your props are onX and half are handleX, your grep results are always incomplete. If some components have I prefix and some don't, TypeScript autocomplete is inconsistent. These are tiny individual decisions that compound into daily friction.

3. Component Architecture — The Three Patterns We Use and When

This is the hardest part to standardize, because it requires actual architectural judgment. Here's ours:

Pattern A: Simple Presentational Component

Use when: the component receives data and renders it. No fetching. No complex state. No side effects.

// components/UserAvatar/UserAvatar.tsx
// This component has one reason to change: the avatar's visual design.
// It doesn't know where the user came from or how their data is structured globally.

interface UserAvatarProps {
  name: string;
  imageUrl?: string;
  size?: 'sm' | 'md' | 'lg';
}

// We use function declaration over React.FC — team decision.
// Reason: React.FC has implicit children prop in older React versions,
// and the function declaration makes the return type clearer.
export function UserAvatar({ name, imageUrl, size = 'md' }: UserAvatarProps) {
  const initials = name
    .split(' ')
    .map(part => part[0])
    .join('')
    .toUpperCase()
    .slice(0, 2);

  const sizeClasses = {
    sm: 'w-8 h-8 text-xs',
    md: 'w-10 h-10 text-sm',
    lg: 'w-14 h-14 text-base',
  };

  if (imageUrl) {
    return (
      <img
        src={imageUrl}
        alt={`${name}'s avatar`}
        className={`rounded-full object-cover ${sizeClasses[size]}`}
      />
    );
  }

  return (
    <div
      className={`rounded-full bg-blue-500 text-white flex items-center justify-center font-medium ${sizeClasses[size]}`}
      aria-label={`${name}'s avatar`}
    >
      {initials}
    </div>
  );
}

Pattern B: Container Component with Custom Hook

Use when: the component needs data fetching or complex state logic.

// features/UserProfile/hooks/useUserProfile.ts
// The hook owns the data logic. The component owns the rendering.
// If the API changes, you touch the hook. If the design changes, you touch the component.
// They have separate reasons to change — separate files.

import { useState, useEffect } from 'react';

interface User {
  id: string;
  name: string;
  email: string;
  avatarUrl?: string;
  bio: string;
}

interface UseUserProfileReturn {
  user: User | null;
  isLoading: boolean;
  error: string | null;
  refetch: () => void;
}

export function useUserProfile(userId: string): UseUserProfileReturn {
  const [user, setUser] = useState<User | null>(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState<string | null>(null);

  const fetchUser = async () => {
    setIsLoading(true);
    setError(null);
    try {
      const response = await fetch(`/api/users/${userId}`);
      if (!response.ok) throw new Error('Failed to fetch user');
      const data: User = await response.json();
      setUser(data);
    } catch (err) {
      setError(err instanceof Error ? err.message : 'Unknown error');
    } finally {
      setIsLoading(false);
    }
  };

  useEffect(() => {
    fetchUser();
  }, [userId]);

  return { user, isLoading, error, refetch: fetchUser };
}

// features/UserProfile/components/UserProfileCard.tsx
// This component is dumb on purpose. It renders what it receives.
// The complexity lives in the hook — this stays readable.

import { useUserProfile } from '../hooks/useUserProfile';
import { UserAvatar } from '../../../components/UserAvatar';

interface UserProfileCardProps {
  userId: string;
}

export function UserProfileCard({ userId }: UserProfileCardProps) {
  const { user, isLoading, error } = useUserProfile(userId);

  if (isLoading) return <UserProfileCardSkeleton />;
  if (error) return <ErrorMessage message={error} />;
  if (!user) return null;

  return (
    <div className="rounded-lg border border-gray-200 p-6">
      <div className="flex items-center gap-4">
        <UserAvatar name={user.name} imageUrl={user.avatarUrl} size="lg" />
        <div>
          <h2 className="text-lg font-semibold">{user.name}</h2>
          <p className="text-gray-500 text-sm">{user.email}</p>
        </div>
      </div>
      {user.bio && <p className="mt-4 text-gray-700">{user.bio}</p>}
    </div>
  );
}

Pattern C: Compound Components

Use when: the component has multiple configurable sub-parts with shared state.

// components/Tabs/Tabs.tsx
// The compound pattern gives consumers flexibility without prop explosion.
// Compare:

// ❌ Prop explosion — rigid, hard to extend, impossible to compose
<Tabs
  activeTab={currentTab}
  onTabChange={handleChange}
  tabTitles={['Overview', 'Details', 'Settings']}
  tabContents={[<Overview />, <Details />, <Settings />]}
  tabIcons={[overviewIcon, detailsIcon, settingsIcon]}
  tabDisabled={[false, false, true]}
/>

// ✅ Compound — flexible, composable, clear ownership
<Tabs value={currentTab} onChange={handleChange}>
  <Tabs.List>
    <Tabs.Trigger value="overview">Overview</Tabs.Trigger>
    <Tabs.Trigger value="details">Details</Tabs.Trigger>
    <Tabs.Trigger value="settings" disabled>Settings</Tabs.Trigger>
  </Tabs.List>
  <Tabs.Content value="overview"><Overview /></Tabs.Content>
  <Tabs.Content value="details"><Details /></Tabs.Content>
  <Tabs.Content value="settings"><Settings /></Tabs.Content>
</Tabs>

// The implementation — compound components use Context to share state
// without prop drilling between the sub-components

import { createContext, useContext, useState, ReactNode } from 'react';

interface TabsContextValue {
  activeTab: string;
  onChange: (value: string) => void;
}

const TabsContext = createContext<TabsContextValue | null>(null);

function useTabsContext() {
  const context = useContext(TabsContext);
  if (!context) {
    throw new Error('Tabs compound components must be used within <Tabs>');
  }
  return context;
}

interface TabsProps {
  value: string;
  onChange: (value: string) => void;
  children: ReactNode;
}

// The root component — owns the context
export function Tabs({ value, onChange, children }: TabsProps) {
  return (
    <TabsContext.Provider value={{ activeTab: value, onChange }}>
      <div className="tabs-root">{children}</div>
    </TabsContext.Provider>
  );
}

// Sub-components — consume the context
Tabs.List = function TabsList({ children }: { children: ReactNode }) {
  return <div role="tablist" className="flex border-b">{children}</div>;
};

Tabs.Trigger = function TabsTrigger({
  value,
  disabled = false,
  children,
}: {
  value: string;
  disabled?: boolean;
  children: ReactNode;
}) {
  const { activeTab, onChange } = useTabsContext();
  const isActive = activeTab === value;

  return (
    <button
      role="tab"
      aria-selected={isActive}
      disabled={disabled}
      onClick={() => !disabled && onChange(value)}
      className={`px-4 py-2 text-sm font-medium border-b-2 transition-colors
        ${isActive ? 'border-blue-500 text-blue-600' : 'border-transparent text-gray-500'}
        ${disabled ? 'opacity-40 cursor-not-allowed' : 'hover:text-gray-700'}`}
    >
      {children}
    </button>
  );
};

Tabs.Content = function TabsContent({
  value,
  children,
}: {
  value: string;
  children: ReactNode;
}) {
  const { activeTab } = useTabsContext();
  if (activeTab !== value) return null;
  return <div role="tabpanel" className="py-4">{children}</div>;
};

4. State Management Decision Tree

This is the decision that Copilot gets wrong most often — because the right answer depends on context that Copilot doesn't have.

When you need state, ask in this order:

1. Can this be derived from existing state or props?
   YES → Don't add state. Compute it inline.
   NO  → Continue.

2. Is this state used by only ONE component?
   YES → useState (or useReducer if the logic is complex)
   NO  → Continue.

3. Is this state used by a small, bounded component tree?
   YES → useContext within that feature
   NO  → Continue.

4. Is this state genuinely global (user session, theme, cart)?
   YES → Zustand store
   NO  → Go back to step 2. You probably answered wrong.

// ✅ The decision tree in practice:

// Step 1 — derived state: don't store it
function UserGreeting({ user }: { user: User }) {
  // Don't useState for displayName — it's derived from user.name
  const displayName = user.name.split(' ')[0]; // Compute inline
  return <h1>Hello, {displayName}</h1>;
}

// Step 2 — single component: useState
function SearchInput() {
  const [query, setQuery] = useState('');
  return <input value={query} onChange={e => setQuery(e.target.value)} />;
}

// Step 2 — complex single-component logic: useReducer
type FilterAction =
  | { type: 'SET_CATEGORY'; payload: string }
  | { type: 'SET_PRICE_RANGE'; payload: [number, number] }
  | { type: 'RESET' };

interface FilterState {
  category: string;
  priceRange: [number, number];
}

function filterReducer(state: FilterState, action: FilterAction): FilterState {
  switch (action.type) {
    case 'SET_CATEGORY':
      return { ...state, category: action.payload };
    case 'SET_PRICE_RANGE':
      return { ...state, priceRange: action.payload };
    case 'RESET':
      return { category: '', priceRange: [0, 1000] };
  }
}

// Step 3 — feature-scoped shared state: useContext
// See the compound Tabs example above — TabsContext is step 3.

// Step 4 — global state: Zustand
// (Lives in src/store/ — not shown here to keep focus)

Making Copilot Enforce Your Standard

Here's the part that changes everything: once you have a written standard, Copilot becomes significantly better — because you've given it context.

Method 1: .github/copilot-instructions.md

GitHub Copilot reads this file and uses it to inform suggestions across your repository.

# Copilot Instructions — YourProject React Standard

## Component Structure
- Use function declarations, not React.FC
- Props interface named ComponentNameProps
- Export named, not default
- Each component in its own folder with index.ts re-export

## File Location Rules
- Shared UI with no business logic → src/components/
- Feature-specific components → src/features/FeatureName/components/
- Never create components directly in src/components/ that import from src/features/

## State Management
- Derived state: compute inline, never useState
- Single-component state: useState or useReducer
- Feature-scoped shared state: useContext within the feature
- Global state: Zustand in src/store/

## Naming
- Components: PascalCase noun (UserProfileCard not UserProfileCardComponent)
- Event handlers: handleEventName (handleSubmit not onSubmit or submitForm)
- Custom hooks: useNoun or useNounVerb (useAuth not useFetchAuth)
- Props interfaces: ComponentNameProps (no I prefix)

## TypeScript
- Always type props explicitly — no implicit any
- Prefer interface for props, type for unions and utility types
- Avoid type assertions (as X) unless absolutely necessary

Method 2: Annotated Example Files

Create a _examples/ folder in your repository with heavily commented reference implementations. Copilot learns from nearby files — give it the right nearby files.

// src/_examples/ExampleFeatureComponent.tsx
// THIS IS A REFERENCE EXAMPLE — not production code.
// Copilot uses this as a pattern reference for new components.

// STANDARD: function declaration, not React.FC
// STANDARD: props interface named ComponentNameProps
// STANDARD: named export, not default

interface ExampleFeatureComponentProps {
  // STANDARD: required props first, optional props last
  userId: string;
  // STANDARD: optional props have explicit defaults in the signature
  variant?: 'compact' | 'full';
}

// STANDARD: component name matches filename
export function ExampleFeatureComponent({
  userId,
  variant = 'full', // STANDARD: default here, not in the interface
}: ExampleFeatureComponentProps) {
  // STANDARD: hook for data fetching — never fetch in the component body
  const { user, isLoading, error } = useUserProfile(userId);

  // STANDARD: early returns for loading and error states
  // before the main render — keeps the happy path clean
  if (isLoading) return <Skeleton />;
  if (error) return <ErrorMessage message={error} />;
  if (!user) return null;

  return (
    <div>
      {/* STANDARD: conditional rendering with ternary for two states,
          short-circuit && for one state */}
      {variant === 'full' ? (
        <FullUserCard user={user} />
      ) : (
        <CompactUserCard user={user} />
      )}
    </div>
  );
}

Method 3: ESLint Rules That Enforce the Standard

The standard isn't just a document — it's code. Anything you can automate, automate.

// .eslintrc.js
module.exports = {
  rules: {
    // Enforce named exports — no default exports from component files
    'import/no-default-export': 'error',

    // Enforce consistent function component style
    'react/function-component-definition': [
      'error',
      { namedComponents: 'function-declaration' }
    ],

    // Prevent prop-types (we use TypeScript)
    'react/prop-types': 'off',

    // Enforce hook naming convention
    'react-hooks/rules-of-hooks': 'error',

    // Custom rule: warn when useState is used for values derivable from props
    // (This requires a custom ESLint plugin — the team built one)
    'custom/no-derived-state': 'warn',
  }
};

The Uncomfortable Truth About Standards

Here's what I want to say that most "coding standards" articles avoid:

A standards document that lives in Notion is worth less than no standard.

I've watched teams spend two days writing a beautiful standards document, put it in Notion, link it in the README, and then watch it be completely ignored within three weeks. Not from malice — from friction. Opening Notion is friction. Remembering the document exists is friction. The blank file with the Copilot suggestion is zero friction.

Your standard must live where developers work. That means:

In the repository — a Markdown file that's versioned alongside the code
In the linter — rules that enforce it automatically
In example files — reference implementations that Copilot reads
In code review — a checklist that reviewers actively use

The standard that requires no effort to follow is the one that survives.

And the other uncomfortable truth: your standard will be wrong in some places. Accept this upfront. The goal isn't a perfect standard — it's a shared standard. A team that consistently does the same slightly-suboptimal thing is more productive than a team that inconsistently does the theoretically-optimal thing five different ways.

Document the decisions. Include the reasoning. Make it easy to update. And revisit it every quarter — not to rewrite it, but to capture the decisions the team has been making implicitly, and make them explicit.

But

** "This is too much overhead for a small team. We don't need a standards document."**

A standards document for a three-person team takes half a day to write. The inconsistency that builds without one takes weeks to untangle six months later — and those weeks come at the worst possible time, when the team is scaling or a critical deadline is approaching. The overhead is front-loaded. The cost of not doing it is back-loaded and much higher.

"Copilot will just get better. Won't this be solved by the next model?"

Better models will give better suggestions — but "better" still means "better at the average." The average of all React codebases on the internet is not your codebase. No model, however good, knows the specific tradeoffs your team made in sprint three. The need for explicit team standards is not a temporary gap that AI will close. It's the permanent requirement of working with other humans.

"Standards slow down development. We move fast and break things."

Inconsistency slows down development. Standards speed it up. The developer who doesn't have to decide "should I use interface or type here?" every single time they open a new file makes that file faster. The developer who knows exactly where to put a new hook doesn't spend ten minutes deciding on folder structure. The code reviewer who isn't arguing about naming conventions is reviewing logic. Standards are a speed investment, not a speed cost.

📚 my notes

Copilot gives you answers. Your team has to ask the right questions first. The standard document is the list of questions your team has already answered — so Copilot can answer the new ones correctly.

✨ Let's keep the conversation going!

If you found this interesting, I'd love for you to check out more of my work or just drop in to say hello.

✍️ Read more on my blog: bishoy-bishai.github.io

☕ Let's chat on LinkedIn: linkedin.com/in/bishoybishai

📘 Curious about AI?: You can also check out my book: Surrounded by AI

How React + Vite Actually Works Behind the Scenes Breakdown

Bishoy Bishai — Sun, 26 Apr 2026 11:26:27 +0000

Missing

✨ Let's keep the conversation going!

If you found this interesting, I'd love for you to check out more of my work or just drop in to say hello.

✍️ Read more on my blog: bishoy-bishai.github.io

☕ Let's chat on LinkedIn: linkedin.com/in/bishoybishai

Mastering Navigation with React Router: A Comprehensive Guide

Bishoy Bishai — Sat, 25 Apr 2026 11:25:54 +0000

Mastering Navigation with React Router: A Comprehensive Guide

Let's be real for a moment. Building a single-page application (SPA) is exhilarating, but the moment you start thinking about navigation – how users move from one view to another, how the URL updates, how data is passed – it can quickly feel like you've stumbled into a labyrinth. I've been there, wrangling with conditional rendering based on URL segments, passing props through layers of components just to get a path parameter, and ultimately creating an unmanageable mess.

This is where React Router steps in, not just as a library, but as a philosophy for managing your application's state through its URL. It offers a declarative, component-based approach that, once truly understood, makes building complex navigation feel almost effortless. In my experience, a solid grasp of React Router isn't just a "nice-to-have"; it's foundational for building scalable, maintainable, and user-friendly React applications.

Why Does Navigation Matter So Much?

Think about it: navigation isn't just about changing the page; it's the core interaction model for your users. A smooth, predictable navigation experience leads to happy users. For developers, a well-structured routing solution simplifies state management, enables deep linking, and dramatically improves code organization. Without it, you're constantly fighting against the browser's native navigation patterns while trying to mimic them poorly.

The Core Building Blocks: A Quick Refresher

At its heart, React Router (specifically v6 and above, which is what I'll focus on) provides a set of components and hooks that let you map URLs to your React components.

Here's a basic setup that you'll see in almost every project:

// App.tsx
import React from 'react';
import { BrowserRouter, Routes, Route, Link } from 'react-router-dom';
import HomePage from './pages/HomePage';
import AboutPage from './pages/AboutPage';
import ProductPage from './pages/ProductPage';
import NotFoundPage from './pages/NotFoundPage';
import './App.css'; // Assume some basic styling

const App: React.FC = () => {
  return (
    <BrowserRouter>
      <nav>
        <Link to="/">Home</Link> | <Link to="/about">About</Link> | <Link to="/products/123">Product 123</Link>
      </nav>
      <Routes>
        <Route path="/" element={<HomePage />} />
        <Route path="/about" element={<AboutPage />} />
        <Route path="/products/:productId" element={<ProductPage />} />
        <Route path="*" element={<NotFoundPage />} /> {/* Catch-all for 404s */}
      </Routes>
    </BrowserRouter>
  );
};

export default App;

BrowserRouter: This is the top-level wrapper that uses the HTML5 history API to keep your UI in sync with the URL. It's almost always where you start.
Routes: This component defines a region where Route components are matched and rendered. It picks the best match, making route ordering less critical than in older versions.
Route: Maps a path to an element (your React component). The path can include dynamic segments like :productId.
Link: Your declarative way to navigate. It renders an <a> tag but prevents a full page reload, letting React Router handle the transition.

Diving Deeper: Power with Hooks

The real magic, the flexibility that makes React Router so powerful in complex scenarios, comes from its hooks. These are the tools you'll reach for when Link isn't enough.

`useNavigate`: Programmatic Navigation

Sometimes, a user action isn't just a simple click on a Link. Maybe they submit a form, and you need to redirect them. Or perhaps an API call fails, and you want to send them back to a safe page. That's where useNavigate shines.

// components/AuthForm.tsx
import React, { useState } from 'react';
import { useNavigate } from 'react-router-dom';

const AuthForm: React.FC = () => {
  const [username, setUsername] = useState('');
  const [password, setPassword] = useState('');
  const navigate = useNavigate(); // Get the navigate function

  const handleSubmit = (e: React.FormEvent) => {
    e.preventDefault();
    // In a real app, you'd send this to an API
    if (username === 'admin' && password === 'password') {
      alert('Login successful!');
      navigate('/dashboard', { replace: true }); // Redirect to dashboard, replacing current history entry
    } else {
      alert('Invalid credentials!');
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      <input type="text" value={username} onChange={(e) => setUsername(e.target.value)} placeholder="Username" />
      <input type="password" value={password} onChange={(e) => setPassword(e.target.value)} placeholder="Password" />
      <button type="submit">Login</button>
      <button type="button" onClick={() => navigate(-1)}>Go Back</button> {/* Navigate back */}
    </form>
  );
};

export default AuthForm;

navigate can take a path string, or even a number to go back/forward in the browser history (e.g., navigate(-1)). The replace: true option is crucial when you don't want the user to be able to hit "back" to return to the previous page (like after a successful login).

`useParams` and `useSearchParams`: Dynamic Data

When your routes need to accept dynamic values, like an item ID or a filter, these hooks are your best friends.

useParams: For path segments (e.g., /products/:id).

// pages/ProductPage.tsx
import React from 'react';
import { useParams } from 'react-router-dom';

const ProductPage: React.FC = () => {
  const { productId } = useParams<{ productId: string }>(); // TypeScript magic!

  // In a real app, you'd fetch product data based on productId
  if (!productId) {
    return <div>Product ID not found in URL.</div>;
  }

  return (
    <div>
      <h1>Product Details</h1>
      <p>Displaying details for product ID: <strong>{productId}</strong></p>
      {/* ... more product details */}
    </div>
  );
};

export default ProductPage;

useSearchParams: For URL query parameters (e.g., /search?query=react&page=1).

// pages/SearchPage.tsx
import React, { useEffect, useState } from 'react';
import { useSearchParams } from 'react-router-dom';

const SearchPage: React.FC = () => {
  const [searchParams, setSearchParams] = useSearchParams();
  const query = searchParams.get('query') || '';
  const page = searchParams.get('page') || '1';
  const [results, setResults] = useState<string[]>([]);

  useEffect(() => {
    if (query) {
      console.log(`Searching for "${query}" on page ${page}`);
      // Simulate API call
      setResults([`Result 1 for "${query}"`, `Result 2 for "${query}"`]);
    } else {
      setResults([]);
    }
  }, [query, page]);

  const handleSearch = (newQuery: string) => {
    setSearchParams(prev => {
      prev.set('query', newQuery);
      prev.set('page', '1'); // Reset page on new search
      return prev;
    });
  };

  const handleNextPage = () => {
    setSearchParams(prev => {
      prev.set('page', String(parseInt(page) + 1));
      return prev;
    });
  };

  return (
    <div>
      <h1>Search Results</h1>
      <input
        type="text"
        value={query}
        onChange={(e) => handleSearch(e.target.value)}
        placeholder="Search..."
      />
      {results.length > 0 ? (
        <ul>
          {results.map((res, index) => <li key={index}>{res}</li>)}
        </ul>
      ) : (
        <p>No results found for "{query}"</p>
      )}
      {query && <button onClick={handleNextPage}>Next Page (Current: {page})</button>}
    </div>
  );
};

export default SearchPage;

useSearchParams is particularly powerful because it gives you both the current search parameters and a setter function (setSearchParams) that works just like useState. This allows you to easily update query parameters while maintaining the rest, triggering re-renders only when relevant.

Advanced Insights and Lessons Learned

Here's the thing: most tutorials cover the basics. But from real-world projects, I've found a few areas that often get overlooked or cause headaches.

Nested Routes and Layouts with Outlet: This is a game-changer for complex applications. Instead of defining every single route explicitly, you can define a parent route that handles a common layout, and then use Outlet to render child routes within it. This dramatically reduces boilerplate and keeps your UI consistent.

// layouts/DashboardLayout.tsx
import React from 'react';
import { Outlet, Link } from 'react-router-dom';

const DashboardLayout: React.FC = () => {
  return (
    <div style={{ display: 'flex' }}>
      <aside style={{ width: '200px', borderRight: '1px solid #ccc' }}>
        <nav>
          <ul>
            <li><Link to="profile">Profile</Link></li> {/* Relative path! */}
            <li><Link to="settings">Settings</Link></li>
          </ul>
        </nav>
      </aside>
      <main style={{ flexGrow: 1, padding: '20px' }}>
        <Outlet /> {/* Renders the matched child route here */}
      </main>
    </div>
  );
};

// App.tsx (excerpt)
<Routes>
  <Route path="/" element={<HomePage />} />
  <Route path="/dashboard" element={<DashboardLayout />}>
    <Route path="profile" element={<ProfilePage />} />
    <Route path="settings" element={<SettingsPage />} />
    {/* /dashboard/profile and /dashboard/settings */}
  </Route>
  <Route path="*" element={<NotFoundPage />} />
</Routes>

Notice the relative paths in Link within DashboardLayout. This is a subtle but powerful feature that keeps your nested navigation self-contained.

Protected Routes (Authentication/Authorization): This is almost guaranteed in any real application. Instead of littering if (!user) checks everywhere, create a wrapper component.

// components/ProtectedRoute.tsx
import React from 'react';
import { Navigate, Outlet } from 'react-router-dom';

interface ProtectedRouteProps {
  isAuthenticated: boolean;
  redirectPath?: string;
}

const ProtectedRoute: React.FC<ProtectedRouteProps> = ({
  isAuthenticated,
  redirectPath = '/login', // Default redirect
}) => {
  if (!isAuthenticated) {
    return <Navigate to={redirectPath} replace />; // Redirect if not authenticated
  }
  return <Outlet />; // Render child routes if authenticated
};

// App.tsx (excerpt)
const isAuthenticated = /* your auth logic here, e.g., from context/redux */;
<Routes>
  <Route path="/login" element={<LoginPage />} />
  <Route element={<ProtectedRoute isAuthenticated={isAuthenticated} />}>
    {/* All routes within this element are protected */}
    <Route path="/dashboard/*" element={<DashboardLayout />} />
    <Route path="/profile" element={<UserProfilePage />} />
  </Route>
  <Route path="*" element={<NotFoundPage />} />
</Routes>

By nesting routes under ProtectedRoute, you centralize your auth logic, keeping your actual page components clean.

Error Boundaries for Route-Specific Errors: While not strictly a React Router feature, combining React's error boundaries with your routes can provide a much better user experience when a specific page or component crashes. Wrap individual Route elements or even the Routes component itself.

Common Pitfalls to Avoid

Forgetting BrowserRouter: Your entire routing setup won't work without it (or HashRouter for specific use cases).
Mixing Link and <a> tags: Always use Link for internal navigation. Regular <a> tags will trigger a full page reload, defeating the purpose of an SPA.
Over-complexifying path matching: V6's Routes component does smart matching. Avoid creating overly specific path values unless truly necessary. Simpler paths are often better.
Not handling 404s: Always include a Route path="*" element={<NotFoundPage />} /> as the last Route within your Routes to gracefully handle unknown URLs.
Mismanaging replace in navigate: Understand when you want to replace the current history entry versus pushing a new one. replace: true is crucial for post-form submissions or logout flows to prevent users from navigating back to stale/inaccessible pages.

Bringing it All Together

Mastering React Router isn't about memorizing every prop or hook, but understanding the declarative way it allows you to connect your application's UI to its URL. It's about thinking in terms of routes as states, and navigation as state transitions. Once you embrace this mindset, you'll find yourself building more robust, intuitive, and enjoyable user experiences.

So, next time you're mapping out your application's flow, remember these tools. They're designed to empower you, not to complicate things. Go forth, build amazing things, and navigate with confidence!

✨ Let's keep the conversation going!

If you found this interesting, I'd love for you to check out more of my work or just drop in to say hello.

✍️ Read more on my blog: bishoy-bishai.github.io

☕ Let's chat on LinkedIn: linkedin.com/in/bishoybishai

The Frontend World Just Changed: 5 Shifts for 2026

Bishoy Bishai — Tue, 21 Apr 2026 11:44:49 +0000

The Frontend World Just Changed: 5 Shifts Professional Devs Need to Master for 2026

Remember that feeling when your app's Lighthouse score just wouldn't budge, no matter how much you minified or lazy-loaded? Or perhaps the endless debate about client-side rendering versus server-side rendering, each with its own set of trade-offs? For years, we've been operating within certain boundaries, defining "frontend" as primarily what happens in the browser. Well, that definition is getting a radical overhaul.

The frontend world, as we know it, is undergoing a profound transformation. We’re not just talking about new frameworks or libraries; we’re seeing fundamental shifts in architecture, deployment, and even the very purpose of what we build. As we hurtle towards 2026, I’ve identified five critical shifts that professional developers and engineering teams absolutely need to understand and embrace. Ignore them at your peril, because these aren't just trends – they're the new bedrock.

1. The Server-First Frontend (and the Edge): Beyond SSR, Welcome Server Components

For a long time, the client-server boundary was pretty clear-cut. Data was fetched from an API, usually on the client, and then rendered. SSR offered a performance boost, but often came with its own hydration costs and complexity. The big shift now? Server Components are fundamentally redefining where and how we render.

Next.js App Router, for example, heavily leans into this paradigm. You're no longer just fetching data from the server; you're rendering on the server, allowing your components to directly access backend resources. This isn’t just SSR with a fancy name; it’s about making your backend and frontend feel like one cohesive unit, without shipping unnecessary server-side logic or data fetching code to the client.

Why this matters:
In my experience, this has been a game-changer for initial page load performance and reducing client-side JavaScript bundles. Imagine a component that fetches user data directly from a database or an internal API without ever touching a client-side API layer.

// app/dashboard/page.tsx - A Server Component
import { getUserData } from '@/lib/server-db'; // Direct database access from server!

export default async function DashboardPage() {
  const user = await getUserData(); // Fetched directly on the server

  return (
    <main>
      <h1>Welcome, {user.name}!</h1>
      <p>Your email: {user.email}</p>
      {/* Client components can be imported and rendered here,
          but their interactivity code only loads when needed */}
      <ClientOnlyChart data={user.activityGraph} />
    </main>
  );
}

What most tutorials miss: It's not about abandoning client-side JavaScript entirely. It’s about intentionality. You split your components into Server Components (for static, data-fetching, or secure logic) and Client Components (for interactivity, hooks, and browser APIs). The trick is to identify the right boundary and minimize the "hydration tax" – the cost of JavaScript taking over static HTML. Overusing use client is a common pitfall that negates many of the benefits. Remember, Client Components still fetch data, Server Components access data.

The "Edge" extends this further, pushing computation and data fetching closer to the user, dramatically reducing latency for global audiences. Think about how much faster a personalized content feed can load when it’s generated just miles from the user, rather than across a continent.

2. Hyper-Personalization & AI Integration: Beyond Chatbots

AI has been a buzzword, but in frontend, it's quickly moving beyond chatbots into genuinely transformative applications. We're talking about dynamic UI generation, context-aware user experiences, and predictive interfaces that adapt in real-time.

Imagine an e-commerce site where product descriptions are subtly re-phrased to match a user's known preferences, or a landing page that dynamically re-arranges its sections based on inferred user intent – all orchestrated by AI models running either at the edge or through serverless functions.

Practical application:
Integrating AI often means interacting with APIs from services like OpenAI or custom models. But the magic happens when we use this to influence our frontend. For instance, an edge function could detect a user's location and preferred language, then use an LLM to generate localized content variations for a hero section on the fly, before the main page even loads.

// Example: Edge function (pseudo-code)
export async function generatePersonalizedHero(request) {
  const userGeo = getUserGeo(request); // Get user's location
  const prompt = `Generate a compelling hero headline for a tech conference
                  in ${userGeo.city}, highlighting AI and developer experience.`;

  const aiResponse = await openai.generateText({ prompt }); // Call AI API

  return new Response(JSON.stringify({ headline: aiResponse.text }), {
    headers: { 'Content-Type': 'application/json' },
  });
}

Insights: This isn't just about calling an API; it's about intelligent data plumbing. Focus on prompt engineering for UI elements, efficient data streaming, and most critically, ethical AI design. Pitfalls include over-automating leading to generic or even biased experiences, and neglecting the performance overhead of external AI calls. Always consider fallback content.

3. Performance as a Core Feature, Not an Afterthought

Core Web Vitals aren't going anywhere; they're becoming the baseline for what constitutes a "good" user experience. The good news is that modern frameworks and deployment platforms are baking performance into their very foundations, rather than making it an optimization step at the end.

Features like streaming HTML, partial hydration, advanced image optimization, and font loading strategies are now often handled automatically. Tools like Next.js's built-in Image component or the <Suspense> boundary for lazy-loading sections of your UI are perfect examples.

// Using Suspense for streaming UI
import { Suspense } from 'react';
import Loading from './loading'; // A simple loading spinner

async function BigDataComponent() {
  const data = await fetchExpensiveData(); // Imagine a slow API call
  return <div>{JSON.stringify(data)}</div>;
}

export default function Page() {
  return (
    <main>
      <h1>Your Dashboard</h1>
      <Suspense fallback={<Loading />}>
        {/* This component will render only when its data is ready */}
        <BigDataComponent />
      </Suspense>
      {/* Other parts of the page can render immediately */}
      <SomeOtherFastComponent />
    </main>
  );
}

Lessons learned from real projects: Don't just rely on default optimizations; understand them. While your framework might handle image optimization, choosing the right image format or understanding priority on Next.js's Image component can still make a huge difference. Architect for performance from the beginning by thinking about component boundaries and data dependencies. A common pitfall is to introduce a blocking script or huge client-side library where a Server Component could have done the job, or an optimized static asset.

4. Developer Experience (DX) is Paramount: Beyond Just Speed

It’s easy to focus on end-user experience, but developer experience (DX) is increasingly recognized as a key differentiator for successful teams. This isn’t just about hot module reloading (though we love that!), it’s about a holistic approach to making development intuitive, enjoyable, and less prone to errors.

This shift manifests in several ways:

Type Safety: TypeScript is now virtually non-negotiable for professional teams. It catches errors early, provides incredible IDE support, and improves code readability and maintainability.
Integrated Tooling: Modern frameworks often come with opinionated, integrated build systems, linters, and testing environments, reducing configuration fatigue.
Standardized Patterns: Best practices are often codified into the framework itself, guiding developers towards scalable and maintainable solutions (e.g., app directory structure in Next.js).

In my experience, investing in DX pays dividends in developer happiness, fewer bugs, and faster iteration cycles. When developers aren't fighting their tools or guessing at data shapes, they can focus on delivering value. Pitfalls here often involve trying to fight the framework's opinions or not fully embracing type safety, which leads to slower development and more runtime errors down the line.

5. The Rise of the "Frontend Platform": Your New Backend is a Service

The lines are blurring not just between client and server, but also between development and operations. Platforms like Vercel, Netlify, and Cloudflare Pages are no longer just hosting providers; they've evolved into comprehensive "frontend clouds."

They integrate deployment, CI/CD, serverless functions (for API routes or edge logic), database integrations, asset optimization, and analytics into a seamless, managed experience. This "platformization" means frontend teams can now deploy full-stack applications with serverless backends and edge functions without needing dedicated DevOps engineers or complex infrastructure management.

Relatable example: Deploying a full-stack Next.js application that fetches data from a serverless database (like Vercel Postgres or Supabase), uses edge functions for A/B testing, and automatically scales globally – all with a simple git push. This dramatically shrinks the cognitive load of managing infrastructure and frees up teams to focus purely on product features.

Key takeaway: This isn't about giving up control; it's about strategic outsourcing of undifferentiated heavy lifting. The pitfall is becoming too reliant on a single vendor without understanding the underlying concepts, or conversely, reinventing the wheel when a robust platform solution already exists. Embrace these platforms, but always strive to understand the underlying architecture and how to leverage their unique capabilities.

Embracing the Future

The frontend isn't just growing; it's evolving into something more powerful, integrated, and impactful than ever before. These five shifts represent not just technological advancements, but a fundamental re-imagining of what frontend development entails. For professional developers, it's an incredibly exciting time – a period ripe with opportunities to build richer, faster, and more intelligent user experiences. The key is continuous learning, challenging old assumptions, and actively participating in shaping this new world. Get ready to build the future!

✨ Let's keep the conversation going!

If you found this interesting, I'd love for you to check out more of my work or just drop in to say hello.

✍️ Read more on my blog: bishoy-bishai.github.io

☕ Let's chat on LinkedIn: linkedin.com/in/bishoybishai

Why Every Link You Share Shows Your Homepage Logo

Bishoy Bishai — Tue, 21 Apr 2026 09:19:12 +0000

Picture this. Someone finds your product. They're excited. They share it on LinkedIn.

The preview that appears: your site's generic homepage logo, the default title "My App — Build Something Great," and a description that reads "The best platform for modern developers."

Not the product they found. Not the image. Not the name. Not the price.

The person they shared it with clicks — or they don't. Usually they don't. Because the preview looked like spam.

That's not a marketing failure. That's a technical failure that happened because somewhere in the codebase, the <head> was treated as a special zone outside the normal component architecture. Someone hardcoded the meta tags in index.html once, and nobody thought to make them dynamic, because "the head" felt different from "the component tree."

It isn't. And the moment you stop treating it as different, a whole category of SEO and social sharing problems disappears.

I've worked on products where fixing the meta tag architecture, taking three days of careful implementation, measurably improved the click-through rate on shared links. Not from any new feature. Not from any marketing campaign. From making the preview show the right thing.

The Mental Model Shift: Two UIs, One Page

Here's the frame that changed everything for me.

Your React application has two user interfaces. The one your human users see — the <body>. And the one your non-human users see — the <head>.

The non-human users are: Googlebot, Bingbot, the LinkedIn link preview crawler, the Twitter card parser, the Slack unfurler, the WhatsApp link expander. Every time someone pastes your URL somewhere, one of these crawlers visits your page, reads the <head>, and uses that data to build a preview. That preview is often the first impression a new user gets of your content — before they even click.

Your <body> UI is beautifully component-driven. Data flows down. Props are explicit. Every product page shows the right product. Every user profile shows the right user.

Your <head> UI, in most codebases I've seen, is one of three things:

Hardcoded in index.html — same title, same description, same og:image for every single page
Managed by a library that feels complex — react-helmet, set up once, then inconsistently maintained
Done correctly in some pages and forgotten in others — the product of three different developers implementing it differently across six months

None of these are what you'd accept for your <body> UI. So why accept it for the <head>?

The answer is simple: <head> is just a React component. Feed it data. Render it conditionally. Test it. Treat it like any other piece of your component tree.

Why Static Meta Tags Are a Product Bug

Let me be specific about what goes wrong

Scenario 1 — The Social Share Problem

Your e-commerce site has 5,000 product pages. Every product has a unique name, unique description, unique image. You have one og:image tag in your index.html: your company logo.

Every time anyone shares any product anywhere, the preview shows your logo and your site name. Not the product. Not the price. Not the image that would make someone click.

Your competitors' links preview with the product photo, the name, and the price. Their click-through rate on shared links is significantly higher than yours. You'll never know this from your analytics because you're not tracking it as a separate failure mode.

Scenario 2 — The Search Result Problem

Google uses the <title> and <meta name="description"> to populate search results. If every page has the same title and description, Google has no basis for showing different descriptions per page — it will either generate them from page content (inconsistent) or show the same one for everything (terrible UX).

A user searching for "waterproof hiking boots size 10" sees your result: "My Outdoor Store — The Best Gear for Modern Adventurers." They see your competitor's result: "Men's Waterproof Hiking Boots — Size 10 Available | Free Shipping." They click the competitor.

Scenario 3 — The Duplicate Content Signal

When hundreds of your pages share the same title and description, Google may interpret this as thin content or duplicate content — signals that negatively affect your domain's overall authority. This is a slow, invisible damage to your rankings that compounds over time.

None of these problems are dramatic. They're all slow and invisible. And they all have the same root cause: the <head> was never treated as data-driven.

The Pattern: RouteHeadMeta

The core pattern is simple. Every route that has unique data should have a component responsible for translating that data into head meta tags. That component is just a React component — it receives props, it returns markup.

Let's build it properly, starting with the shared SEO interface that every framework approach will use:

// types/seo.ts
// Define the SEO data shape separately from your domain data.
// Your product has a name. The SEO builder decides how that name
// becomes a page title. Keep the transformation logic in one place.

export interface SEOMeta {
  title: string;
  description: string;
  canonicalUrl: string;
  ogImage?: string;
  ogType?: 'website' | 'article' | 'product';
  noIndex?: boolean;
  structuredData?: Record<string, unknown>;
}

interface Product {
  id: string;
  name: string;
  description: string;
  tagline?: string;
  seoDescription?: string;
  slug: string;
  price: number;
  inStock: boolean;
  images: Array<{ url: string; ogUrl?: string }>;
  category?: { defaultImage?: string };
}

// Builder function — transforms domain data into SEO data.
// Single responsibility: knows how products become meta tags.
// Framework-agnostic — used by all four approaches below.
export function buildProductSEO(product: Product, baseUrl: string): SEOMeta {
  return {
    title: buildPageTitle(product.name, 'YourBrand'),
    description: buildDescription(product),
    canonicalUrl: `${baseUrl}/products/${product.slug}`,
    ogImage: buildOgImage(product, baseUrl),
    ogType: 'product',
    structuredData: {
      '@context': 'https://schema.org',
      '@type': 'Product',
      name: product.name,
      description: product.description,
      image: product.images.map(img => img.url),
      offers: {
        '@type': 'Offer',
        price: product.price,
        priceCurrency: 'USD',
        availability: product.inStock
          ? 'https://schema.org/InStock'
          : 'https://schema.org/OutOfStock',
      },
    },
  };
}

// Title: max 60 chars for search results. Cut at word boundary.
function buildPageTitle(productName: string, brandName: string): string {
  const full = `${productName} — ${brandName}`;
  if (full.length <= 60) return full;

  const maxNameLen = 60 - ` — ${brandName}`.length;
  const cut = productName.slice(0, maxNameLen).trimEnd();
  const lastSpace = cut.lastIndexOf(' ');
  const clean = lastSpace > 0 ? cut.slice(0, lastSpace) : cut;
  return `${clean}... — ${brandName}`;
}

// Description: lead with the most important detail. Max 155 chars.
function buildDescription(product: Product): string {
  const sources = [
    product.seoDescription,
    product.tagline,
    product.description,
  ];
  const raw = sources.find(s => s && s.trim().length > 0);

  if (!raw) {
    // No description exists — use a generic fallback.
    // In production, this should also trigger a CMS content alert.
    return `Discover ${product.name} at YourBrand. Free shipping on orders over $50.`;
  }

  if (raw.length <= 155) return raw;
  return raw.slice(0, 152).trimEnd() + '...';
}

// og:image: never undefined for a product page.
// Use the first available image source from priority list.
function buildOgImage(product: Product, baseUrl: string): string {
  if (product.images[0]?.ogUrl) return product.images[0].ogUrl;
  if (product.images[0]?.url) return product.images[0].url;
  if (product.category?.defaultImage) return product.category.defaultImage;
  return `${baseUrl}/images/og-product-default.jpg`;
}

Now the framework-specific implementations — all using the same buildProductSEO function.

Approach 1: Next.js App Router (The Current Standard)

In Next.js App Router, the framework handles meta tag injection via generateMetadata. You export a function that returns a metadata object — Next.js puts it in the <head> on the server before the HTML leaves.

// app/products/[slug]/page.tsx

import type { Metadata } from 'next';
import { notFound } from 'next/navigation';
import { buildProductSEO } from '@/types/seo';
import { getProduct } from '@/lib/api';

interface PageProps {
  params: { slug: string };
}

// generateMetadata runs server-side before the page renders.
// Meta tags are baked into the HTML — Googlebot reads them in Wave 1.
// No JavaScript required. No flash. No client-side injection.
export async function generateMetadata({ params }: PageProps): Promise<Metadata> {
  try {
    const product = await getProduct(params.slug);

    if (!product) {
      // Missing product — return minimal metadata, tell Google not to index
      return {
        title: 'Product Not Found — YourBrand',
        robots: { index: false, follow: false },
      };
    }

    const seo = buildProductSEO(product, 'https://yourbrand.com');

    return {
      title: seo.title,
      description: seo.description,
      alternates: { canonical: seo.canonicalUrl },
      openGraph: {
        title: seo.title,
        description: seo.description,
        url: seo.canonicalUrl,
        type: 'website',
        images: seo.ogImage
          ? [{ url: seo.ogImage, width: 1200, height: 630, alt: product.name }]
          : undefined,
      },
      twitter: {
        card: 'summary_large_image',
        title: seo.title,
        description: seo.description,
        images: seo.ogImage ? [seo.ogImage] : undefined,
      },
      robots: seo.noIndex ? { index: false, follow: false } : undefined,
    };
  } catch (error) {
    // Network error or database down — return safe defaults
    console.error('generateMetadata failed:', error);
    return { title: 'YourBrand' };
  }
}

// Next.js deduplicates fetch calls within the same request.
// Both generateMetadata and the page component can call getProduct(params.slug)
// — only ONE network request is made. Trust the framework.
export default async function ProductPage({ params }: PageProps) {
  const product = await getProduct(params.slug);
  if (!product) notFound();

  const seo = buildProductSEO(product, 'https://yourbrand.com');

  return (
    <main>
      {/* Structured data as a script tag in the component —
          generateMetadata handles title/og/twitter, this handles JSON-LD */}
      {seo.structuredData && (
        <script
          type="application/ld+json"
          dangerouslySetInnerHTML={{ __html: JSON.stringify(seo.structuredData) }}
        />
      )}
      <h1>{product.name}</h1>
      <p>{product.description}</p>
    </main>
  );
}

Approach 2: Remix (The `meta` Export)

Remix's meta export is a function at the route level that returns an array of meta descriptors. It runs server-side. Same philosophy, different API.

// routes/products.$slug.tsx

import type { MetaFunction, LoaderFunctionArgs } from '@remix-run/node';
import { json } from '@remix-run/node';
import { useLoaderData } from '@remix-run/react';
import { buildProductSEO } from '~/types/seo';

export async function loader({ params }: LoaderFunctionArgs) {
  const product = await getProduct(params.slug!);
  if (!product) throw new Response('Not Found', { status: 404 });
  // One fetch — both meta and component use this same data.
  // No double-fetching. No extra network request.
  return json({ product });
}

export const meta: MetaFunction<typeof loader> = ({ data }) => {
  if (!data?.product) {
    return [
      { title: 'Product Not Found — YourBrand' },
      { name: 'robots', content: 'noindex' },
    ];
  }

  const seo = buildProductSEO(data.product, 'https://yourbrand.com');

  return [
    { title: seo.title },
    { name: 'description', content: seo.description },
    { tagName: 'link', rel: 'canonical', href: seo.canonicalUrl },
    { property: 'og:title', content: seo.title },
    { property: 'og:description', content: seo.description },
    { property: 'og:url', content: seo.canonicalUrl },
    { property: 'og:type', content: seo.ogType ?? 'website' },
    ...(seo.ogImage ? [{ property: 'og:image', content: seo.ogImage }] : []),
    { name: 'twitter:card', content: 'summary_large_image' },
    { name: 'twitter:title', content: seo.title },
    { name: 'twitter:description', content: seo.description },
    ...(seo.ogImage ? [{ name: 'twitter:image', content: seo.ogImage }] : []),
  ];
};

export default function ProductPage() {
  const { product } = useLoaderData<typeof loader>();
  return (
    <main>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
    </main>
  );
}

Approach 3: Next.js Pages Router

Still fully valid and widely used. Meta tags go via next/head inside the component.

// pages/products/[slug].tsx

import Head from 'next/head';
import type { GetStaticProps, GetStaticPaths } from 'next';
import { buildProductSEO } from '@/types/seo';

interface PageProps {
  product: Product;
}

export const getStaticProps: GetStaticProps<PageProps> = async ({ params }) => {
  const product = await getProduct(params!.slug as string);
  if (!product) return { notFound: true };
  return { props: { product }, revalidate: 3600 };
};

export const getStaticPaths: GetStaticPaths = async () => {
  const slugs = await getAllProductSlugs();
  return {
    paths: slugs.map(slug => ({ params: { slug } })),
    fallback: 'blocking',
  };
};

export default function ProductPage({ product }: PageProps) {
  const seo = buildProductSEO(product, 'https://yourbrand.com');

  return (
    <>
      {/* next/head with SSG/ISR = server-rendered meta tags.
          Same SEO benefit as App Router's generateMetadata. */}
      <Head>
        <title>{seo.title}</title>
        <meta name="description" content={seo.description} />
        <link rel="canonical" href={seo.canonicalUrl} />
        <meta property="og:title" content={seo.title} />
        <meta property="og:description" content={seo.description} />
        <meta property="og:url" content={seo.canonicalUrl} />
        <meta property="og:type" content={seo.ogType ?? 'website'} />
        {seo.ogImage && <meta property="og:image" content={seo.ogImage} />}
        <meta name="twitter:card" content="summary_large_image" />
        <meta name="twitter:title" content={seo.title} />
        <meta name="twitter:description" content={seo.description} />
        {seo.ogImage && <meta name="twitter:image" content={seo.ogImage} />}
        {seo.structuredData && (
          <script
            type="application/ld+json"
            dangerouslySetInnerHTML={{ __html: JSON.stringify(seo.structuredData) }}
          />
        )}
      </Head>
      <main>
        <h1>{product.name}</h1>
        <p>{product.description}</p>
      </main>
    </>
  );
}

Approach 4: Bare React SPA with react-helmet-async

For client-side only apps — internal tools, dashboards, SPAs without SSR. Use react-helmet-async, not react-helmet (the original is no longer maintained).

// npm install react-helmet-async

// src/main.tsx — wrap your entire app
import { HelmetProvider } from 'react-helmet-async';

function App() {
  return (
    <HelmetProvider>
      <Router>
        <Routes>
          <Route path="/products/:slug" element={<ProductPage />} />
        </Routes>
      </Router>
    </HelmetProvider>
  );
}

// src/pages/ProductPage.tsx

import { Helmet } from 'react-helmet-async';
import { useProduct } from '@/hooks/useProduct';
import { buildProductSEO } from '@/types/seo';

export function ProductPage() {
  const { slug } = useParams<{ slug: string }>();
  const { product, loading, error } = useProduct(slug!);

  // Render meta in loading state too — prevents title flash to "undefined"
  if (loading) {
    return (
      <>
        <Helmet><title>Loading... — YourBrand</title></Helmet>
        <ProductSkeleton />
      </>
    );
  }

  if (error || !product) {
    return (
      <>
        <Helmet>
          <title>Product Not Found — YourBrand</title>
          <meta name="robots" content="noindex" />
        </Helmet>
        <NotFoundMessage />
      </>
    );
  }

  const seo = buildProductSEO(product, window.location.origin);

  return (
    <>
      <Helmet>
        <title>{seo.title}</title>
        <meta name="description" content={seo.description} />
        <link rel="canonical" href={seo.canonicalUrl} />
        <meta property="og:title" content={seo.title} />
        <meta property="og:description" content={seo.description} />
        <meta property="og:url" content={seo.canonicalUrl} />
        {seo.ogImage && <meta property="og:image" content={seo.ogImage} />}
        <meta name="twitter:card" content="summary_large_image" />
        <meta name="twitter:title" content={seo.title} />
        <meta name="twitter:description" content={seo.description} />
        {seo.ogImage && <meta name="twitter:image" content={seo.ogImage} />}
      </Helmet>
      <main>
        <h1>{product.name}</h1>
        <p>{product.description}</p>
      </main>
    </>
  );
}

Important caveat: react-helmet-async injects meta tags client-side, after JavaScript runs. For public-facing pages where SEO matters, this means you're back in two-wave indexing territory. For internal tools where SEO is irrelevant — completely fine.

The Uncomfortable Truth About Meta Tags

Here's what most implementation guides don't say:

Meta tags without content strategy are decoration.

You can implement the most elegant, perfectly fallback-handled, SSR-rendered meta tag system in the world. If the content team hasn't written unique descriptions for your 5,000 product pages, your meta description will be auto-generated from page content — and Google will probably generate its own anyway, because yours isn't compelling enough.

The technical implementation is the container. What goes in it is what matters.

Two questions that actually determine whether your meta tags help:

Is the title unique per page, specific, and under 60 characters? If your product names in the database are 80+ characters, you have a content problem that truncation logic only partially solves.
Is the description compelling for a human reading a search result or a social preview? "A great product with amazing features" is a placeholder someone forgot to replace.

The developer's job is to make the system capable of showing the right thing. The content team's job is to ensure the right thing exists. Both jobs are required. Only one of them is in this article.

Real Objections

** "react-helmet-async is fine for my Next.js project, why bother with generateMetadata?"**

If your pages are server-rendered (SSG, ISR, or SSR), react-helmet-async injects meta tags client-side — after React hydrates. This creates a brief window where the server HTML has different meta content than what React inserts, which can cause hydration mismatches. Some crawlers are HTML-only and will miss client-injected meta tags entirely. generateMetadata and next/head with SSR inject server-side. That's the correct behavior for a server-rendered app.

** "Won't both generateMetadata and the page component double-fetch the product?"**

No — Next.js deduplicates fetch calls within the same request. If both generateMetadata and your page component call getProduct(params.slug), only one network request is made. This is by design. Don't try to pass data between generateMetadata and the page component directly — the API doesn't support it. Call the same function from both; trust the deduplication.

"What about ISR — does the meta get stale when the product data changes?"

Yes — ISR regenerates the page including meta tags at the revalidation interval. If a product's price changes between revalidations, the structured data price might be stale for up to revalidate seconds. For price-sensitive data, use cache: 'no-store' on that specific fetch, or shorten the revalidation window. The tradeoff between freshness and performance is real — know where you land on it per page type.

For more

📄 "The Open Graph protocol" — Official Spec at ogp.me
📄 "Sharing Debugger" — Meta for Developers
🎥 "Next.js Metadata API Deep Dive" by Lee Robinson on YouTube
💬

"Content is king, but distribution is queen. And she wears the pants."
— Jonathan Perelman, BuzzFeed

The <head> is a React component. Feed it data. Give it fallbacks. Treat it with the same care you give the rest of your component tree.

The user who shares your product page on LinkedIn deserves a preview that shows the right product. The Googlebot that crawls your page deserves a title that describes what it found. The developer who comes after you deserves a system predictable enough to maintain without fear.

All three of those requirements are met by the same thing: treating the <head> as data.

Simple? Yes. Easy? Only after the fallbacks. Welcome to the craft.

✨ Let's keep the conversation going!

If you found this interesting, I'd love for you to check out more of my work or just drop in to say hello.

✍️ Read more on my blog: bishoy-bishai.github.io

☕ Let's chat on LinkedIn: linkedin.com/in/bishoybishai

📘 Curious about AI?: You can also check out my book: Surrounded by AI

DEV Community: Bishoy Bishai

Beyond useEffect: Specialized Effect Hooks for Async, Deep Comparisons, and SSR

Top Shadcn Blocks Libraries Released in April 2026

Unlocking Velocity: My Top Shadcn Blocks Libraries from April 2026

1. @shadcn/dashboard-blocks: The Powerhouse for Admin Panels

Our Latest Products

5 JavaScript Mistakes Beginners Still Make in 2026

The Persistent Perils: 5 JavaScript Mistakes Beginners (Still) Make in 2026

1. The Async Abyss: Mismanaging Promises & async/await

2. Mutation Mayhem: Forgetting Immutability in Data Structures

3. The this Conundrum & Scope Sorcery

4. Error Handling Apathy: Silent Failures in the Production Wilderness

5. Global Gotchas & Side Effect Sprawl

React Observer Hooks: 7 Ways to Watch the DOM Without the Boilerplate

React Observer Hooks: 7 Ways to Watch the DOM Without the Boilerplate

The Core Problem: React's Declarative World vs. DOM Imperatives

The Building Block: useCallbackRef (Your Observer's Best Friend)

1. useIntersectionObserver: Knowing When Elements Enter or Exit View

React Hooks in 2026: Not Just What They Do — When to Reach for Each One

Before We Start: The One Question That Changes Everything

useState — The Entry Point and Its Limits

useReducer — State Machines, Not Just Complex State

useEffect — The Most Misused Hook in React

useContext — Sharing State Without Prop Drilling

useCallback and useMemo — Performance Tools, Not Default Habits

useRef — Escaping React Without Losing Your Mind

useTransition — Making the UI Lie (In the Best Way)

useOptimistic — Telling the User "Done" Before It Is

Custom Hooks — The Real Power Move

Here's the thing nobody says at the end of a hooks guide:

The Unfinished Chapter

Next.js App Router Complete Guide: From Basics to Advanced Patterns

Navigating the Future: A Complete Guide to Next.js App Router for Professional Teams

The Core Shift: Server vs. Client Components – It’s Not Just an Optimization, It’s an Architecture

Data Fetching: A New Horizon of Performance

Routing and Layouts: Nested and Powerful

Advanced Patterns & Pitfalls

Wrapping Up: Embrace the New Mindset

How React Works (Part 2)? Why React Had to Build Its Own Execution Engine

Decoding React's Engine: Why It Built Its Own Scheduler

The Browser's Dilemma: Why React Needed Its Own Path

Enter the Virtual DOM: A Necessary Abstraction

The Heart of the Engine: React Fiber

Why Interruptible Work Matters

The "Why": React Had to Build Its Own Execution Engine

Pitfalls and Practical Takeaways

Wrapping Up

I Let GitHub Copilot Define My React Standards for Six Months. Here's the Damage It Did.

The Psychological Trap Nobody Names

What "Averageness at Scale" Looks Like

The Standard Document: What It Contains and Why

1. Folder Structure — The First Decision That Shapes Everything

2. Naming Conventions — The Decisions That Eliminate a Thousand Arguments

3. Component Architecture — The Three Patterns We Use and When

4. State Management Decision Tree

Making Copilot Enforce Your Standard

The Uncomfortable Truth About Standards

But

📚 my notes

How React + Vite Actually Works Behind the Scenes Breakdown

Mastering Navigation with React Router: A Comprehensive Guide

Mastering Navigation with React Router: A Comprehensive Guide

Why Does Navigation Matter So Much?

The Core Building Blocks: A Quick Refresher

Diving Deeper: Power with Hooks

useNavigate: Programmatic Navigation

useParams and useSearchParams: Dynamic Data

Advanced Insights and Lessons Learned

Common Pitfalls to Avoid

Bringing it All Together

The Frontend World Just Changed: 5 Shifts for 2026

The Frontend World Just Changed: 5 Shifts Professional Devs Need to Master for 2026

1. The Server-First Frontend (and the Edge): Beyond SSR, Welcome Server Components

2. Hyper-Personalization & AI Integration: Beyond Chatbots

3. Performance as a Core Feature, Not an Afterthought

4. Developer Experience (DX) is Paramount: Beyond Just Speed

5. The Rise of the "Frontend Platform": Your New Backend is a Service

Embracing the Future

Why Every Link You Share Shows Your Homepage Logo

The Mental Model Shift: Two UIs, One Page

1. `@shadcn/dashboard-blocks`: The Powerhouse for Admin Panels

1. The Async Abyss: Mismanaging Promises & `async/await`

3. The `this` Conundrum & Scope Sorcery

The Building Block: `useCallbackRef` (Your Observer's Best Friend)

1. `useIntersectionObserver`: Knowing When Elements Enter or Exit View

`useState` — The Entry Point and Its Limits

`useReducer` — State Machines, Not Just Complex State

`useEffect` — The Most Misused Hook in React

`useContext` — Sharing State Without Prop Drilling

`useCallback` and `useMemo` — Performance Tools, Not Default Habits

`useRef` — Escaping React Without Losing Your Mind

`useTransition` — Making the UI Lie (In the Best Way)

`useOptimistic` — Telling the User "Done" Before It Is

`useNavigate`: Programmatic Navigation

`useParams` and `useSearchParams`: Dynamic Data

Approach 2: Remix (The `meta` Export)