DEV Community: Bishoy Bishai

# Single Page Applications and SEO: How to Rank React & Next.js Apps in 2026

Bishoy Bishai — Wed, 08 Apr 2026 11:39:04 +0000

Decoding SPA SEO in 2026: Ranking React & Next.js Apps

I remember the early days of building beautiful, dynamic Single Page Applications (SPAs) with React. We’d craft these incredible user experiences, complete with smooth transitions and real-time updates. Then came the inevitable question from the marketing team: "Why can't Google see our content?" It was a valid, painful question. We were building for humans, but search engines, at the time, were still largely text-sniffing dogs, often struggling with JavaScript-rendered content. The battle between SPA dynamism and SEO discoverability felt like an uphill climb.

Fast forward to 2026, and a lot has changed. Google’s crawlers are incredibly sophisticated, often capable of rendering JavaScript-heavy applications. So, does that mean the SPA SEO problem is dead? Not quite. In my experience, while Google can render JavaScript, relying solely on client-side rendering for critical content is still playing with fire. For robust, reliable, and performant SEO, especially as competition intensifies, we need a strategy that puts content front and center for crawlers and users, right from the first byte. This is where frameworks like Next.js shine, transforming our React SPAs into SEO powerhouses.

Why This Still Matters: Beyond Just "Can Google See It?"

Here’s the thing: SEO isn't just about whether a crawler eventually sees your content. It’s about:

Reliability: Even in 2026, there are still edge cases or potential delays where purely client-side content might be missed or indexed incorrectly. Why risk it for your most important pages?
Performance: Core Web Vitals (LCP, FID, CLS) are massive ranking factors. A page that takes a long time to load and become interactive because it relies on client-side fetching and rendering will perform poorly, regardless of whether Google can eventually parse it. Pre-rendered content is inherently faster.
Crawl Budget: For very large sites, search engines allocate a "crawl budget." If your pages are slow to render, crawlers might spend less time on your site, potentially missing new or updated content.
Social Sharing & Other Bots: While Google is smart, other services (Twitter, Facebook, Slack) aren't as advanced and often rely on basic HTML meta tags for rich previews.

Next.js: Your SEO Supercharger for React

Next.js gives us a spectrum of rendering options, each with its SEO benefits. The key is understanding when to use each:

1. Server-Side Rendering (SSR) with `getServerSideProps`

For dynamic content that changes frequently or needs to be personalized per request, SSR is your best friend. The server fetches data and renders the full HTML page on each request, sending it directly to the browser (and the crawler).

// pages/products/[id].tsx
import { GetServerSideProps } from 'next';

interface Product {
  id: string;
  name: string;
  description: string;
  price: number;
}

interface ProductPageProps {
  product: Product;
}

const ProductPage: React.FC<ProductPageProps> = ({ product }) => {
  return (
    <div>
      <h1>{product.name}</h1>
      <p>{product.description}</p>
      <span>${product.price}</span>
    </div>
  );
};

export const getServerSideProps: GetServerSideProps<ProductPageProps> = async (context) => {
  const { id } = context.params as { id: string };
  // In a real app, fetch from an API
  const res = await fetch(`https://api.example.com/products/${id}`);
  const product: Product = await res.json();

  if (!product) {
    return {
      notFound: true,
    };
  }

  return {
    props: {
      product,
    },
  };
};

export default ProductPage;

Insight: Don't overuse SSR. While powerful, it can increase server load and initial response time compared to static alternatives. Reserve it for truly dynamic, user-specific, or frequently updated content where the latest data is crucial on every page load.

2. Static Site Generation (SSG) with `getStaticProps` & `getStaticPaths`

For content that doesn't change frequently (blog posts, marketing pages, product listings with stable data), SSG is gold. Pages are pre-rendered at build time, resulting in lightning-fast load times and virtually no server overhead per request.

// pages/blog/[slug].tsx
import { GetStaticProps, GetStaticPaths } from 'next';

interface Post {
  slug: string;
  title: string;
  content: string;
}

interface PostPageProps {
  post: Post;
}

const BlogPost: React.FC<PostPageProps> = ({ post }) => {
  return (
    <div>
      <h1>{post.title}</h1>
      <div dangerouslySetInnerHTML={{ __html: post.content }} />
    </div>
  );
};

export const getStaticPaths: GetStaticPaths = async () => {
  // In a real app, fetch all post slugs from your CMS/API
  const slugs = ['my-first-post', 'understanding-nextjs-seo'];
  const paths = slugs.map((slug) => ({ params: { slug } }));

  return {
    paths,
    fallback: 'blocking', // or true, or false
  };
};

export const getStaticProps: GetStaticProps<PostPageProps> = async (context) => {
  const { slug } = context.params as { slug: string };
  // Fetch specific post data
  const res = await fetch(`https://api.example.com/posts/${slug}`);
  const post: Post = await res.json();

  if (!post) {
    return {
      notFound: true,
    };
  }

  return {
    props: {
      post,
    },
    revalidate: 60, // Incremental Static Regeneration (ISR)
  };
};

export default BlogPost;

Insight: fallback: 'blocking' is powerful. If a path isn't pre-generated, Next.js will SSR it on the first request and then cache it for subsequent requests, effectively combining the benefits of SSR and SSG for dynamic routes. And don't forget revalidate for Incremental Static Regeneration (ISR), allowing you to update static pages without a full rebuild.

3. Metadata Management with `next/head`

This is fundamental. Every page needs a unique title, description, and Open Graph/Twitter card tags for social sharing. Next.js's next/head component makes this straightforward.

import Head from 'next/head';

const MyPage = () => {
  return (
    <>
      <Head>
        <title>My Awesome Page Title | Your Brand</title>
        <meta name="description" content="A compelling description for search engines and users." />
        <meta property="og:title" content="My Awesome Page Title" />
        <meta property="og:description" content="A compelling description for social media." />
        <meta property="og:image" content="https://yourbrand.com/social-image.jpg" />
        <meta property="og:url" content="https://yourbrand.com/my-page" />
        <meta name="twitter:card" content="summary_large_image" />
        {/* Add JSON-LD for structured data */}
        <script type="application/ld+json">
          {`
            {
              "@context": "https://schema.org",
              "@type": "WebPage",
              "name": "My Awesome Page",
              "description": "A compelling description for search engines and users."
            }
          `}
        </script>
      </Head>
      {/* Rest of your page content */}
    </>
  );
};

export default MyPage;

Insight: JSON-LD structured data is often overlooked but incredibly powerful for rich snippets. Use a validator to ensure it's correct.

The Next Evolution: React Server Components and the App Router

Looking towards 2026, the Next.js App Router (introduced in v13) and its integration with React Server Components are game-changers. This architecture blurs the lines between server and client, allowing you to fetch data and render parts of your UI entirely on the server before sending any JavaScript to the client. This means:

Zero JavaScript for static content: Less JavaScript to download, parse, and execute, leading to faster LCP and TBT (Total Blocking Time).
Automatic data fetching optimization: Server Components integrate seamlessly with async/await and handle data fetching on the server.
Enhanced SEO: More content is rendered directly into the initial HTML, making it instantly available to crawlers without any JavaScript execution.

It's a paradigm shift that fundamentally improves the SEO and performance story for React applications, pushing more work to the server by default.

Common Pitfalls I've Learned to Avoid

Forgetting next/image: A huge mistake. Next.js's Image component handles lazy loading, responsive sizing, and modern formats like WebP/AVIF automatically. This is critical for LCP.
Over-fetching on the client after SSR/SSG: Don't render an empty shell with SSR/SSG only to fetch all critical content via useEffect on the client. The goal is meaningful HTML first.
Ignoring your Lighthouse scores: Regularly audit your pages. Performance metrics are directly correlated with SEO.
Missing robots.txt and Sitemaps: These are basic but essential. Ensure your robots.txt isn't blocking important content and your sitemap is up-to-date.
Lack of internal linking: A well-structured internal link profile helps crawlers discover content and passes "link juice" around your site.

Wrapping Up

Ranking React and Next.js apps in 2026 isn't about tricking search engines; it's about giving them exactly what they want: fast, accessible, well-structured content. By leveraging Next.js's rendering capabilities, optimizing your assets, and being meticulous with your metadata and structured data, you're not just building for bots – you're building a fundamentally better, faster, and more discoverable web experience for your users. Treat SEO as an ongoing conversation and an architectural concern, not just a marketing add-on. Your hard work in code will translate directly into visibility and success.

✨ 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

Implementing Dark Mode: CSS Variables, System Preference, and Persistence

Bishoy Bishai — Tue, 07 Apr 2026 12:13:19 +0000

Demystifying Dark Mode: The Elegant Path with CSS Variables, System Preference, and Persistence

Every modern web application eventually faces the dark mode dilemma. It's no longer just a "nice-to-have"; users expect it, often as a fundamental part of their browsing experience. But how often have you seen dark mode implementations that feel clunky, suffer from a "flash of unstyled content" (FOUC), or completely disregard your OS-level preferences? It's a common struggle, and honestly, it used to be a source of frustration for me too.

Early in my career, theming often meant complex JavaScript manipulating styles directly, or an endless array of Sass variables compiled into bulky stylesheets. It worked, but it was brittle, hard to maintain, and far from dynamic. Then, CSS Custom Properties—CSS Variables—landed, and the game changed entirely. It unlocked a truly elegant, performant, and user-friendly approach to dynamic theming.

In this deep dive, we'll build a dark mode solution for a React application that's resilient, respectful of user preferences, and persistent across sessions. We'll leverage the power of CSS variables, React's context API, and a touch of vanilla JavaScript for a seamless experience.

The Core Idea: CSS Variables as Theme Tokens

At the heart of a great dark mode implementation are CSS variables. Think of them as dynamic tokens for your styles. Instead of hardcoding color: #FFFFFF;, you'd use color: var(--color-text-primary);.

Here's why this is revolutionary: you define your variables once, and then you can change their values based on a parent selector.

/* default light theme */
:root {
  --color-background: #ffffff;
  --color-text-primary: #333333;
  --color-accent: #007bff;
}

/* dark theme overrides */
[data-theme='dark'] {
  --color-background: #1a1a1a;
  --color-text-primary: #f0f0f0;
  --color-accent: #6200ee;
}

/* Your component styles */
body {
  background-color: var(--color-background);
  color: var(--color-text-primary);
  transition: background-color 0.3s ease, color 0.3s ease; /* smooth transitions */
}

button {
  background-color: var(--color-accent);
  color: var(--color-text-primary); /* or white for contrast */
}

Notice the [data-theme='dark'] selector. This is the magic. By toggling a data-theme attribute on our body or html element, we can swap out all our theme-dependent CSS variable values instantly. No JavaScript style manipulation needed, just good old CSS cascading.

Respecting System Preferences with `prefers-color-scheme`

Before we even talk about toggles and persistence, the absolute first thing you should do is respect your user's operating system preference. Many users already have dark mode enabled at the OS level, and your application should honor that by default.

This is where the @media (prefers-color-scheme: dark) media query comes in:

/* default light theme (or just no media query for light) */
:root {
  --color-background: #ffffff;
  --color-text-primary: #333333;
  /* ... other light theme variables */
}

/* System preference for dark mode */
@media (prefers-color-scheme: dark) {
  :root {
    --color-background: #1a1a1a;
    --color-text-primary: #f0f0f0;
    /* ... other dark theme variables */
  }
}

/* Override system preference if user explicitly chooses light */
[data-theme='light'] {
  --color-background: #ffffff;
  --color-text-primary: #333333;
}

/* Override system preference if user explicitly chooses dark */
[data-theme='dark'] {
  --color-background: #1a1a1a;
  --color-text-primary: #f0f0f0;
}

With this setup, if a user's system is set to dark mode and they haven't explicitly chosen a theme on your site, they'll automatically see your dark theme. Beautiful, right?

Bringing it to React: Context and a Custom Hook

Now, how do we manage this data-theme attribute in a React app, provide a toggle, and ensure persistence? React's Context API is perfect for this.

First, let's define our theme types:

// src/types/theme.ts
export type Theme = 'light' | 'dark';

Next, our ThemeContext and ThemeProvider:

// src/contexts/ThemeContext.tsx
import React, { createContext, useContext, useState, useEffect, useCallback } from 'react';
import { Theme } from '../types/theme';

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

const ThemeContext = createContext<ThemeContextType | undefined>(undefined);

interface ThemeProviderProps {
  children: React.ReactNode;
}

export const ThemeProvider: React.FC<ThemeProviderProps> = ({ children }) => {
  const [theme, setThemeState] = useState<Theme>(() => {
    // 1. Check for stored preference
    const storedTheme = localStorage.getItem('theme') as Theme | null;
    if (storedTheme) return storedTheme;

    // 2. Check system preference
    return window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light';
  });

  const setTheme = useCallback((newTheme: Theme) => {
    setThemeState(newTheme);
    localStorage.setItem('theme', newTheme);
    document.documentElement.setAttribute('data-theme', newTheme);
  }, []);

  // Set initial theme and listen for system preference changes
  useEffect(() => {
    document.documentElement.setAttribute('data-theme', theme);

    const mediaQuery = window.matchMedia('(prefers-color-scheme: dark)');
    const handleChange = (e: MediaQueryListEvent) => {
      if (!localStorage.getItem('theme')) { // Only update if user hasn't made an explicit choice
        setThemeState(e.matches ? 'dark' : 'light');
        document.documentElement.setAttribute('data-theme', e.matches ? 'dark' : 'light');
      }
    };
    mediaQuery.addEventListener('change', handleChange);
    return () => mediaQuery.removeEventListener('change', handleChange);
  }, [theme, setTheme]); // Added setTheme to deps to satisfy linter, though it's memoized

  const toggleTheme = useCallback(() => {
    setTheme(theme === 'light' ? 'dark' : 'light');
  }, [theme, setTheme]);

  return (
    <ThemeContext.Provider value={{ theme, toggleTheme, setTheme }}>
      {children}
    </ThemeContext.Provider>
  );
};

export const useTheme = () => {
  const context = useContext(ThemeContext);
  if (context === undefined) {
    throw new Error('useTheme must be used within a ThemeProvider');
  }
  return context;
};

Wrap your application's root component with ThemeProvider:

```typescript jsx
// src/App.tsx
import React from 'react';
import { ThemeProvider } from './contexts/ThemeContext';
import MyComponent from './MyComponent';
import ThemeToggle from './ThemeToggle'; // We'll create this

const App: React.FC = () => {
return (

My Awesome App

);
};

export default App;



And a simple `ThemeToggle` component:



```typescript jsx
// src/components/ThemeToggle.tsx
import React from 'react';
import { useTheme } from '../contexts/ThemeContext';

const ThemeToggle: React.FC = () => {
  const { theme, toggleTheme } = useTheme();

  return (
    <button onClick={toggleTheme} aria-label={`Switch to ${theme === 'light' ? 'dark' : 'light'} theme`}>
      {theme === 'light' ? '🌙 Dark Mode' : '☀️ Light Mode'}
    </button>
  );
};

export default ThemeToggle;

The Crucial Detail: Preventing FOUC (Flash of Unstyled Content)

Here's a common pitfall: when your React app loads, it takes a moment for JavaScript to execute, fetch the theme from localStorage, and apply data-theme. In that brief moment, your page might render with the default (light) theme before flipping to dark, causing an unpleasant "flash."

To combat this, we inject a small, blocking script directly into the head of our index.html (or equivalent in your framework, like Next.js _document.tsx):

<!-- public/index.html (inside <head>) -->
<script>
  (function() {
    const getInitialTheme = () => {
      const storedTheme = localStorage.getItem('theme');
      if (storedTheme) {
        return storedTheme;
      }
      return window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light';
    };
    const initialTheme = getInitialTheme();
    document.documentElement.setAttribute('data-theme', initialTheme);
  })();
</script>

This tiny script runs before your React bundle loads. It checks localStorage first, then prefers-color-scheme, and immediately sets the data-theme attribute. By the time your CSS loads and React renders, the correct theme is already applied, eliminating the dreaded FOUC.

Real-World Insights and Lessons Learned

Semantic Naming is Key: Name your CSS variables semantically (--color-text-primary, --color-background-card) rather than based on their current value (--light-grey, --dark-blue). This makes theme swapping much more robust.
Accessibility First: Always test your dark mode (and light mode!) for sufficient contrast. Tools like Chrome's Lighthouse or even simple contrast checkers can help. Don't forget focus states for keyboard users.
Beyond Colors: Dark mode isn't just about colors. Sometimes, shadows need to be lighter or less pronounced, borders might need to change, or images might need slightly different overlays to maintain readability. Consider all visual aspects.
Transitions: Add transition properties to your background-color and color on body or html to ensure a smooth, pleasing fade when the theme changes, rather than an abrupt switch.
Server-Side Rendering (SSR): If you're using SSR (like Next.js), the FOUC prevention script needs to be handled carefully within your _document.tsx or similar file to ensure it's injected correctly into the server-rendered HTML.

Wrapping Up

Implementing dark mode gracefully no longer has to be a headache. By combining the power of CSS variables for dynamic styling, @media (prefers-color-scheme: dark) for respecting user preferences, localStorage for persistence, and a small, critical script to prevent FOUC, you can deliver a truly polished and user-centric experience. This approach is not just about aesthetics; it’s about providing choice and improving accessibility, all while keeping your codebase clean and maintainable. Go forth and build beautifully themed 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

Next.js vs React: When Should You Use Each?

Bishoy Bishai — Mon, 06 Apr 2026 11:34:33 +0000

Next.js vs. React: Stop Asking "Which Is Better?" Ask This Instead.

The question isn't about features. It's about who renders your app first — and why that changes everything.

Let me tell you about a mistake I've watched teams make more times than I can count.

They're starting a new project. Excitement is high. The tech discussion begins. Someone says "should we use React or Next.js?" Someone else opens a comparison article. The article has a bullet list of features. The team picks based on the longest list of features that match their current requirements.

Six months later, the product has grown. Requirements have shifted. And suddenly they're either:

A) Fighting Next.js's server/client boundaries because they built a deeply stateful, real-time dashboard that didn't need SSR at all — and now every new developer onboarding asks "wait, why is this a Server Component again?"

Or B) Trying to bolt SEO and performance onto a bare React SPA that was always meant to be public-facing, discovering that client-side rendering and Googlebot have a complicated relationship.

Both of these are expensive mistakes. Not because the technology is bad — React and Next.js are both excellent. But because the decision was made for the wrong reasons.

I've been building React applications since 2017. And the question I get asked most consistently by mid-level developers is: "When do I use Next.js and when do I not?"

The tutorials answer this with feature lists. I'm going to answer it with the question that actually matters.

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

Apply the one diagnostic question that cuts through every "React vs. Next.js" debate in under two minutes
Understand why the rendering model difference matters — not just that it exists
Recognize the two most expensive architectural mistakes teams make, and when you're about to make them
Walk away with a decision framework you can use on your next project kickoff, without needing to re-read a comparison article

This is Pillar 4 content — Tactical Analysis. Not a tutorial. Not a beginner guide. This is the thinking you need for architectural decisions, written for developers who've already built things and broken them.

The One Question That Settles It

Before we touch a single feature comparison, I want to give you the diagnostic tool that makes this decision fast and clear. Every time.

"Who is the first person to execute your code — the server or the browser?"

That's it. That's the question.

I know it sounds too simple. Stay with me.

When the browser executes your code first, you're in client-side rendering territory. The user receives an HTML shell — basically empty — and JavaScript that, once downloaded and parsed, builds the UI in the browser. React SPA. This is Vite + React. This is Create React App. The browser does the work.

When the server executes your code first, HTML with actual content is generated before anything hits the browser. The user receives a fully-formed page. The browser can display it before a single line of JavaScript runs. This is Next.js's default behavior — and it's not just an optimization, it's a fundamentally different architecture.

Every consequence of choosing one over the other flows from this distinction. Not from feature lists. From this.

Let me show you what I mean in concrete terms, because the abstraction matters less than what actually happens in practice.

What "Client Renders First" Means in Production

When you build a standard React SPA, here's the sequence of events every time a user opens your app:

Browser requests the page from your server
Server responds with a nearly empty HTML file — <div id="root"></div> and a script tag
Browser downloads your JavaScript bundle (could be 200KB, could be 2MB, depends on your dependencies)
Browser parses and executes the JavaScript
React initializes, renders your component tree
Your components call their useEffect hooks
API calls go out to fetch data
Data comes back
Components re-render with actual content
The user finally sees something meaningful

Steps 3 through 10 all happen in the user's browser. On a fast laptop in Berlin with fiber internet, this feels instant. On a mid-range Android phone in Cairo on a 4G connection that drops to 3G when the elevator doors close — this is a blank screen for 3 to 5 seconds. Sometimes longer.

And for Googlebot? Googlebot doesn't execute JavaScript the way a browser does. It's gotten better — Google now processes JavaScript — but it's slower, it's not guaranteed, and it puts your SEO at the mercy of a crawler's JavaScript budget. For internal tools where nobody cares about Google, this is fine. For a product where organic search is a revenue channel, this is a real problem that doesn't show up in development and shows up painfully in production.

// The standard React SPA data fetch
// What's actually happening: the user sees NOTHING until this whole sequence completes
import React, { useState, useEffect } from 'react';

function ProductListing() {
  const [products, setProducts] = useState<Product[]>([]);
  const [loading, setLoading] = useState(true);

  useEffect(() => {
    // Step 6-8 in the sequence above.
    // This runs AFTER the JS bundle downloaded and executed.
    // AFTER React initialized.
    // The user has been looking at a blank div (or a spinner) until this moment.
    fetch('/api/products')
      .then(res => res.json())
      .then(data => {
        setProducts(data);
        setLoading(false);
      });
  }, []);

  // The user sees this first: just a spinner.
  // No content. No products. Nothing for the search crawler to index.
  if (loading) return <div>Loading...</div>;

  return (
    <ul>
      {products.map(product => (
        <li key={product.id}>{product.name} — €{product.price}</li>
      ))}
    </ul>
  );
}

This works perfectly well for an internal dashboard where users are authenticated, the audience is known, and nobody is Googling their way to your CRM. But ship this as a public product catalog and you've built a performance and SEO problem that will require a framework migration to fully fix.

What "Server Renders First" Changes

Now the same scenario in Next.js with Server Components (App Router):

// app/products/page.tsx
// This is a React Server Component — it runs on the server, not in the browser.
// The user receives actual HTML with products already inside it.
// No loading state. No useEffect. No spinner for the initial load.

interface Product {
  id: string;
  name: string;
  price: number;
}

// Notice: no 'use client' directive. This runs on the server.
// Notice: no useEffect, no useState, no loading state.
// The data is fetched before the HTML is generated.
async function ProductsPage() {
  // This fetch runs on the server during the request.
  // It never runs in the browser.
  // The database (or API) response is baked into the HTML before it leaves the server.
  const response = await fetch('https://api.yourstore.com/products', {
    // Next.js extends fetch with caching control.
    // revalidate: 3600 means "cache this for an hour, then refresh"
    // This is ISR — Incremental Static Regeneration.
    // The user gets static speed WITH dynamic data. Chef's kiss.
    next: { revalidate: 3600 }
  });
  const products: Product[] = await response.json();

  // By the time this JSX reaches the browser, it's already HTML.
  // The browser renders it immediately — no JavaScript needed for the initial view.
  return (
    <ul>
      {products.map(product => (
        <li key={product.id}>{product.name} — €{product.price}</li>
      ))}
    </ul>
  );
}

export default ProductsPage;

Walk through what happens now from the user's perspective:

Browser requests the page
Server fetches data from the API
Server renders the React component tree to HTML — with products already in it
Browser receives HTML with actual content
User sees the product list immediately
JavaScript loads in the background for interactivity (adding to cart, filters, etc.)

The user sees content on step 5. In the SPA version, content appears on step 10. That gap — those missing steps — is what Lighthouse scores measure. That gap is what Googlebot indexes. That gap is what users feel on slow connections.

The Rendering Model Spectrum — This Is Not Binary

Here's where most comparison articles fail you. They present this as a binary choice: SPA (React) vs. SSR (Next.js). It's not. Next.js gives you a spectrum of rendering strategies that you can apply per page, per component, even per fetch call.

Understanding this spectrum is what separates developers who use Next.js correctly from developers who fight it constantly.

** The four strategies:**

Strategy 1: Static Site Generation (SSG)

The page is rendered at build time. HTML is generated once, stored, and served from a CDN. Zero server computation per request. Zero database calls per visitor.

// app/blog/[slug]/page.tsx
// generateStaticParams tells Next.js: "build HTML for all of these at compile time"
// Result: blazing fast, CDN-served pages with zero per-request overhead

export async function generateStaticParams() {
  const posts = await getAllBlogPosts(); // Runs once at build time
  return posts.map(post => ({ slug: post.slug }));
}

async function BlogPost({ params }: { params: { slug: string } }) {
  // This also runs at build time, not per request.
  const post = await getBlogPost(params.slug);
  return <article>{post.content}</article>;
}

Use this when: content doesn't change per user and doesn't change frequently. Blog posts. Marketing pages. Documentation.

Strategy 2: Incremental Static Regeneration (ISR)

Static generation, but with a revalidation window. The page is served statically (CDN speed) and regenerated in the background when the cache expires.

// This product page is generated statically but refreshes every hour.
// Users get static speed. Content stays reasonably fresh.
// No server computation per request — unless the cache is stale.
async function ProductPage({ params }: { params: { id: string } }) {
  const product = await fetch(`/api/products/${params.id}`, {
    next: { revalidate: 3600 } // Regenerate at most once per hour
  }).then(r => r.json());

  return <ProductDetails product={product} />;
}

Use this when: content changes occasionally but not per-user. Product catalogs. News articles. Pricing pages.

Strategy 3: Server-Side Rendering (SSR)

Generated fresh on every request. Full server computation per visit.

// This page is different for every logged-in user.
// It can't be cached — the data is user-specific.
// SSR is the right call here.
import { cookies } from 'next/headers';

async function DashboardPage() {
  const cookieStore = cookies();
  const sessionToken = cookieStore.get('session')?.value;

  // Fetch user-specific data on the server.
  // Sensitive. Can't be cached. Must be fresh.
  const userData = await fetchUserDashboard(sessionToken);

  return <Dashboard data={userData} />;
}

Use this when: content is user-specific, real-time, or can't be cached. User dashboards. Account pages. Personalized feeds.

Strategy 4: Client-Side Rendering (CSR) — still valid inside Next.js

Some parts of your app are highly interactive and genuinely belong in the browser.

// 'use client' tells Next.js: this component renders in the browser
// Use for: real-time interactions, browser APIs, complex local state
'use client';

import { useState } from 'react';

function AddToCartButton({ productId }: { productId: string }) {
  const [isAdding, setIsAdding] = useState(false);
  const [added, setAdded] = useState(false);

  const handleClick = async () => {
    setIsAdding(true);
    await addToCart(productId);
    setIsAdding(false);
    setAdded(true);
  };

  return (
    <button onClick={handleClick} disabled={isAdding}>
      {added ? '✓ Added to Cart' : isAdding ? 'Adding...' : 'Add to Cart'}
    </button>
  );
}

A real Next.js application uses all four of these strategies simultaneously. The product listing page is ISR. The product detail is ISR with a shorter window. The cart is CSR. The checkout is SSR (user-specific, must be fresh). The blog is SSG.

This is not complexity for its own sake. This is precision — matching the rendering strategy to the actual data requirements of each part of your application.

The Two Expensive Mistakes

I've seen both of these destroy project timelines. Not hypothetically — in real codebases.

Expensive Mistake #1 — Reaching for Next.js when you need a React SPA

This one is subtler than it looks.

You're building an internal analytics dashboard. Real-time charts. Complex filtering. Heavy client-side state. Users authenticate first — nobody is landing on these pages from Google. SEO is irrelevant. The data updates every 30 seconds via WebSocket.

Someone on the team suggests Next.js because "it's the standard now."

Six months in:

Every new component requires the 'use client' decision
The WebSocket connection logic is fighting the Server Component model
Real-time state is awkward to manage when half your tree is server-rendered
Developers keep hitting hydration mismatches that take hours to debug
Onboarding new developers requires explaining the client/server boundary before they can write their first component

Was Next.js wrong? Technically no. Was it the right tool for this job? Absolutely not. A Vite + React SPA with React Query for data fetching would have been faster to build, easier to reason about, and had zero hydration issues. The complexity of Next.js added zero value to a private, highly interactive, SEO-irrelevant application.

The diagnostic: Before reaching for Next.js, ask: "Does the server rendering this page first give ANY benefit to my users?" For authenticated-only dashboards where the content is entirely dynamic — the answer is usually no.

Expensive Mistake #2 — Building a public product with bare React

This one is more painful because you don't feel it immediately. You feel it at month four when marketing starts asking why your Core Web Vitals are tanking. You feel it when the product manager notices you're not appearing in Google search for your own product name. You feel it when a user on a slow connection tweets that your app feels broken.

I've watched teams spend three months building a public-facing e-commerce product in bare React and then spend another two months migrating to Next.js because the performance gap was affecting conversion rates. That's five months on what should have been three.

// The telltale sign you need Next.js and you're in a React SPA:
// You start adding libraries to solve problems Next.js solves natively.

// react-helmet for SEO meta tags (Next.js has this built-in)
import { Helmet } from 'react-helmet-async';

// You're pre-rendering with react-snap or similar tools
// You're adding react-query with complex cache configuration
// You're writing custom webpack config for code splitting

// When you're recreating the framework, it's time to use the framework.

The diagnostic: if your app is public-facing, content-heavy, or depends on search engine visibility — Next.js should be your starting point, not a migration destination.

The App Router Reality Check

Okay, I want to spend time on something the comparison articles either gloss over or get wrong: Next.js App Router is a paradigm shift, not just an API change.

The Pages Router (the "old" Next.js with getServerSideProps and getStaticProps) was familiar — it felt like React with some special export functions. The App Router with React Server Components is a genuinely different mental model.

What Most Developers Think: Server Components are just components that fetch data on the server. Basically getServerSideProps but cleaner.

What's Actually True in Production: Server Components don't run in the browser at all. They have no access to browser APIs. They can't use useState or useEffect. They can't have event handlers. They're not hydrated — the browser never receives their JavaScript. They exist only as HTML output from the server.

Why the Gap Exists: Because the tutorials show you a Server Component that fetches data and renders it, and it looks almost exactly like a Client Component. The difference isn't visible until you try to add interactivity and get an error, or until you try to access window and your server crashes.

// ⚠️ This will fail — and the error message isn't always clear about why

// app/some-page/page.tsx — this is a Server Component by default
// No 'use client' directive

import { useState } from 'react'; // ❌ ERROR: useState in a Server Component

async function SomePage() {
  const [count, setCount] = useState(0); // ❌ This doesn't exist on the server

  return <button onClick={() => setCount(c => c + 1)}>{count}</button>;
  // ❌ Event handlers don't work in Server Components either
}

// ✅ The correct pattern: Server Component + Client Component composition

// app/some-page/page.tsx — Server Component
// Fetches data on the server, passes it down
async function SomePage() {
  const initialData = await fetchInitialData();

  // InteractiveCounter is a Client Component — it gets hydrated in the browser
  // SomePage itself stays server-only — its JavaScript never ships to the browser
  return (
    <div>
      <h1>Static heading — rendered in HTML, no JS needed</h1>
      <InteractiveCounter initialValue={initialData.count} />
    </div>
  );
}

// components/InteractiveCounter.tsx
'use client'; // ← This component runs in the browser

import { useState } from 'react';

function InteractiveCounter({ initialValue }: { initialValue: number }) {
  const [count, setCount] = useState(initialValue);

  return (
    <button onClick={() => setCount(c => c + 1)}>
      Count: {count}
    </button>
  );
}

The mental model shift: in App Router, think of your component tree as two layers. The server layer handles data fetching and generates HTML. The client layer handles interactivity and browser APIs. The server layer wraps the client layer — not the other way around.

Once this clicks, App Router becomes powerful and intuitive. Before it clicks, it's a source of confusing errors and "why doesn't this work" moments that make teams question whether they should have stayed on Pages Router.

My honest advice: if your team is new to Next.js AND new to App Router — consider starting with Pages Router for your first project. It's still fully supported. It has a gentler learning curve. And it teaches you the "why" of server rendering in a way that makes App Router make more sense when you get to it.

A Decision Framework You Can Use Tomorrow

Stop asking "which is better?" Start asking these questions at your project kickoff:

Question 1: Who are your users and how do they arrive?

If users arrive via search engines, social shares, or direct links to content — the server needs to render that content before it reaches them. Next.js.

If users arrive via login and spend their time inside an authenticated application — the initial render can happen in the browser. React SPA is fine.

Question 2: How dynamic is your content, and for whom?

Content that's the same for everyone and changes rarely → Static generation. Next.js with SSG or ISR.

Content that's the same for everyone but changes frequently → Server rendering with short cache windows. Next.js with ISR.

Content that's different per user → Either SSR (in Next.js) or CSR (React SPA or 'use client' in Next.js).

Question 3: What is your team's relationship with the server/client boundary?

Teams with strong full-stack experience tend to find Next.js's model natural. Teams that have only done client-side React may find the App Router's server/client boundary genuinely confusing at first.

Factor in the learning curve. A slightly less optimal tool your team understands deeply ships faster than the perfect tool your team fights constantly.

Question 4: Will this application grow to need both?

Here's the thing about React SPAs: you can always add Next.js later. The migration is painful, but it's a known path. Many successful products started as React SPAs and migrated when SEO and performance became priorities.

But the reverse — migrating from Next.js to a React SPA because you don't need SSR — is almost never worth doing. You don't lose anything by using Next.js for an app that doesn't fully use SSR. The overhead is minimal.

When in doubt: if there's any chance this product will become public-facing, default to Next.js. The cost of migrating TO it later is higher than the learning curve of starting with it.

The Uncomfortable Truth

Here's what I want to say that nobody is saying loudly enough:

Next.js won. For production React applications, Next.js is the default. The question is no longer "React or Next.js?" — it's "which Next.js rendering strategy, and which parts of my app need client-side rendering?"

React without a framework is still absolutely valid — for SPAs, for dashboards, for internal tools, for learning. But when someone asks me "should I learn Next.js or just React?" my honest answer is: learn React first (you'll be writing React components regardless), then learn Next.js, because that's what you'll use in most production jobs.

The fact that we're still debating "React vs. Next.js" as equals in 2024 is a symptom of an industry that moves fast but talks slowly. The ecosystem has largely settled. Next.js ships with Vercel, with the React team's blessing, with RSC as the direction React itself is heading. Fighting this is like arguing about whether you should use TypeScript in 2024 — technically optional, practically the default.

That said — understand WHY Next.js makes sense before you default to it. Because developers who use Next.js without understanding the rendering model are the same developers who slap 'use client' on everything to make errors go away, effectively building a React SPA inside a Next.js wrapper. They've paid the complexity cost with zero benefit.

Know the model. Then use the tool.

Real Objections

Objection 1: "Next.js is overkill for a simple project. Vite + React is faster to set up."

Completely valid. If you're building a small side project, a prototype, or a learning exercise — the cognitive overhead of Next.js routing conventions and rendering strategies adds friction you don't need. Vite + React is fast, simple, and excellent for things that don't need SSR. The calculus changes the moment "going to production with real users" enters the picture.

Objection 2: "React Query / TanStack Query solves the same problems as SSR without changing your framework."

Partially true. React Query dramatically improves client-side data fetching — caching, background refetching, loading states. But it doesn't change when the browser receives content. The user still waits for JavaScript to load before seeing anything meaningful. React Query makes the SPA experience better. It doesn't change the fundamental rendering model. If initial load performance and SEO are requirements, React Query is not a substitute for SSR.

Objection 3: "Server Components add too much complexity. I'll just use Pages Router with getServerSideProps."

Legitimate choice and not a wrong one. Pages Router is stable, well-understood, and still fully supported. If your team is productive with it, there's no urgency to migrate to App Router. The main things you lose are automatic streaming, more granular caching control, and the performance benefits of shipping less JavaScript to the client. For many applications, those tradeoffs favor staying on Pages Router until App Router stabilizes further in your team's comfort zone.

That said — new projects should probably start on App Router. The ecosystem is moving there. The documentation is better now. And the performance benefits at scale are real.

📚 Nice to see too

📄 Article: "Rendering Patterns" by Addy Osmani & Lydia Hallie on patterns.dev
- Why it made my brain itch: The most comprehensive visual breakdown of every rendering strategy — SPA, SSR, SSG, ISR, Streaming — with performance implications for each. Bookmark this one. You'll come back to it every time someone asks you to justify an architecture choice.
📄 Article: "Understanding React Server Components" on the Next.js Blog
- Why it made my brain itch: Coming directly from the team building it, this explains the why behind RSC in a way that makes the constraints feel intentional rather than arbitrary. Read this before your first App Router project.
🎥 Video: "React Server Components from Scratch" by Theo Browne (t3.gg) on YouTube
- Skip to minute 6:30: Where he builds RSC from first principles. Watching it get built from scratch is the fastest way to truly understand what the boundary between server and client means.
"The best tool is the one that ships."
— Everyone who's survived a framework debate

✨ 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

Your React Component Isn't Too Big. It Has Too Many Reasons to Change.

Bishoy Bishai — Thu, 02 Apr 2026 11:31:47 +0000

And yes — there's a difference. A massive one.

I want to tell you something that took me an embarrassingly long time to learn.

In 2017, I shipped a feature I was proud of. A live order tracking component at Elemnus — real-time updates, smooth UI, clean-looking code by my standards at the time. My team lead reviewed it, nodded slowly, and said: "It works. But when the next requirement comes, we're going to regret this."

I thought he was being dramatic.

Three weeks later, a new requirement landed: "Add a cancellation reason modal when the user cancels an order." Simple, right? I opened the component. It was 340 lines long. It was fetching data, managing five different UI states, animating transitions, and handling form submissions — all in one place, all tangled together like earphones at the bottom of a backpack.

I spent two days on a change that should have taken two hours. I introduced three bugs fixing one. We shipped on Friday. Something broke on Saturday.

My team lead didn't say "I told you so." He just opened the component and said: "How many reasons does this thing have to change?"

I counted. Seven. At least seven different reasons this single component would need to be touched if anything in the system changed.

That question — how many reasons does this have to change? — is the one I want to answer with you today. Because if you've ever felt the specific dread of opening a component you wrote six months ago, if you've ever thought "I'll just add this one thing here" and immediately regretted it — this article is for Bishoy at 3 AM. The one staring at a 400-line component wondering where to even start.

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

Diagnose exactly why a component is hard to change (not just that it's "too big")
Apply the Change Isolation Test to any component in under 60 seconds
Refactor a bloated component into a structure that lets you sleep at night
Know when to memoize and when memoization is costing you more than it saves
Walk away with a mental model that makes every future component decision faster

This is not a "here's the before, here's the after" tutorial. Those exist. They're fine. This is the thinking behind the refactor — the stuff that actually stops you from recreating the same mess six months later in a different component with a different name.

The Uncomfortable Truth Nobody Says Out Loud

Here's what the React documentation won't tell you, what most tutorials gloss over, and what I got wrong for longer than I'd like to admit:

Single Responsibility Principle is not about size. It's about reasons to change.

I know. You've heard "keep your components small." You've nodded. You've maybe even split a big component into three smaller ones and felt good about yourself. But here's the trap: you can split a component into five pieces and still violate Single Responsibility completely if those pieces are coupled to the same reasons for change.

Let me be specific. Imagine you have a UserProfile component. You decide to be responsible and split it into UserAvatar, UserBio, and UserActions. Excellent. Three components now. But all three of them directly call the same API endpoint, and all three of them have their own loading state. Now you have three components, all of which need to change the moment the API contract changes. You've split the file. You haven't split the responsibilities.

This distinction is the whole game. Everything else is noise.

The question to ask about any component, large or small, is this: "If X changes, does this component need to change too?" Ask that for every X you can think of — API shape, UI design, business logic, error handling strategy, animation library. Count the yeses. That number is your responsibility score. The goal is not zero — one is fine, even two can be fine in context. But when you hit five, six, seven? You've built a component that is afraid of the future. And it should be. Because every future change is coming for it.

What "Doing Too Much" Actually Looks Like in Production

Let's build the actual broken thing first. Not Hello world. A real-world UserProfile component the way it grows organically in a real codebase under real deadline pressure.

// 🚫 The component that "just grew this way"
// Responsibility Score: 7 (fetching, loading state, error state, 
// display logic, edit mode toggle, form state, save logic)
// Time to understand cold: ~25 minutes
// Time to safely add a feature: "let me just try this and see"

import React, { useState, useEffect } from 'react';

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

// These would normally live in an API layer — but they ended up here
// because "it was faster at the time"
async function fetchUser(userId: string): Promise<User> {
  const response = await fetch(`/api/users/${userId}`);
  if (!response.ok) throw new Error('Failed to fetch');
  return response.json();
}

async function updateUser(userId: string, data: Partial<User>): Promise<User> {
  const response = await fetch(`/api/users/${userId}`, {
    method: 'PATCH',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(data),
  });
  if (!response.ok) throw new Error('Failed to update');
  return response.json();
}

const UserProfile: React.FC<{ userId: string }> = ({ userId }) => {
  // Responsibility 1: Fetched data
  const [user, setUser] = useState<User | null>(null);
  // Responsibility 2: Loading state (shared between fetch AND save — 
  // which means the spinner shows when you save, which blocks the form,
  // which you'll only notice in QA if you're lucky)
  const [loading, setLoading] = useState(true);
  // Responsibility 3: Error state (also shared — same problem)
  const [error, setError] = useState<string | null>(null);
  // Responsibility 4: Edit mode toggle
  const [isEditing, setIsEditing] = useState(false);
  // Responsibility 5 & 6: Form state for name and bio
  // (These will get out of sync with `user` in subtle ways)
  const [editName, setEditName] = useState('');
  const [editBio, setEditBio] = useState('');

  useEffect(() => {
    const loadUser = async () => {
      setLoading(true);
      setError(null);
      try {
        const userData = await fetchUser(userId);
        setUser(userData);
        // Syncing form state with fetched data — a sign that
        // these should not live in the same place
        setEditName(userData.name);
        setEditBio(userData.bio);
      } catch (err) {
        setError('Failed to fetch user.');
      } finally {
        setLoading(false);
      }
    };
    loadUser();
  }, [userId]);

  // Responsibility 7: Save logic
  const handleSave = async () => {
    if (!user) return;
    setLoading(true); // ← This disables the form AND shows the spinner.
                      // If you only wanted to show a spinner on the save button,
                      // you'd need ANOTHER state variable. This is how state multiplies.
    setError(null);
    try {
      const updatedUser = await updateUser(user.id, { name: editName, bio: editBio });
      setUser(updatedUser);
      setIsEditing(false);
    } catch (err) {
      setError('Failed to update user.');
    } finally {
      setLoading(false);
    }
  };

  if (loading) return <div>Loading profile...</div>;
  if (error) return <div style={{ color: 'red' }}>Error: {error}</div>;
  if (!user) return null;

  return (
    <div>
      <h2>{user.name}'s Profile</h2>
      {isEditing ? (
        <div>
          <label>
            Name:
            <input
              type="text"
              value={editName}
              // Every keystroke re-renders the ENTIRE UserProfile component.
              // Including the header. Including any siblings. 
              // This is invisible in development. Painful at scale.
              onChange={(e) => setEditName(e.target.value)}
            />
          </label>
          <label>
            Bio:
            <textarea
              value={editBio}
              onChange={(e) => setEditBio(e.target.value)}
            />
          </label>
          <button onClick={handleSave} disabled={loading}>Save</button>
          <button onClick={() => setIsEditing(false)} disabled={loading}>Cancel</button>
        </div>
      ) : (
        <div>
          <p><strong>Email:</strong> {user.email}</p>
          <p><strong>Bio:</strong> {user.bio}</p>
          <button onClick={() => setIsEditing(true)}>Edit Profile</button>
        </div>
      )}
    </div>
  );
};

Now let me apply the Change Isolation Test. I'll go through every realistic change request and ask: does this component need to change?

The API endpoint changes → Yes. The fetch functions are defined inside the file.
The loading spinner design changes → Yes. Loading state is here.
We want different loading behavior for fetch vs. save → Yes. And it's painful — you need to add a whole new state variable.
The display design changes (new layout, colors, added avatar) → Yes.
The form validation rules change → Yes.
We add a new editable field (phone number) → Yes. And it touches every section of this component.
The error handling strategy changes (toast instead of inline error) → Yes.

Seven reasons. Seven. Every one of those is a future regression waiting to happen. Every one of those is a code review comment waiting to become a heated discussion. Every one of those is a bug that shows up in production on a Friday.

Open your React DevTools Profiler right now and record a session while typing in the edit form. You'll see UserProfile lighting up on every single keystroke. The entire component tree underneath it re-renders. For a name input. Because the form state, the display state, and the data state are all the same state in the same component.

The Refactor: Change Isolation, Not Just Code Splitting

here's the approach. We're not just moving code around. We're identifying each reason to change and giving it its own home.

Reason to change #1 & #7: Data fetching and saving → Custom Hook

The hook's only job is to know about the user. It fetches. It saves. It knows nothing about forms, nothing about edit mode, nothing about what the UI looks like. If the API contract changes tomorrow, you touch exactly one file.

// useUser.ts
// Responsibility: ONE — managing the user data lifecycle
// Reason to change: ONLY when the data fetching or update logic changes
// Time to understand cold: ~5 minutes

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

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

async function fetchUser(userId: string): Promise<User> {
  const response = await fetch(`/api/users/${userId}`);
  if (!response.ok) throw new Error('Network response was not ok');
  return response.json();
}

async function saveUserToApi(userId: string, data: Partial<User>): Promise<User> {
  const response = await fetch(`/api/users/${userId}`, {
    method: 'PATCH',
    headers: { 'Content-Type': 'application/json' },
    body: JSON.stringify(data),
  });
  if (!response.ok) throw new Error('Failed to save');
  return response.json();
}

interface UseUserReturn {
  user: User | null;
  isFetching: boolean;     // ← Separate loading states. Intentional.
  isSaving: boolean;       // ← Now the form can show a save spinner
  fetchError: string | null; // without blocking the entire UI.
  saveError: string | null;
  saveUser: (data: Partial<User>) => Promise<User | undefined>;
  refetch: () => void;
}

export function useUser(userId: string): UseUserReturn {
  const [user, setUser] = useState<User | null>(null);
  // Notice: two separate loading states.
  // This solves the "spinner blocks the form during save" bug
  // that you'd only catch in QA — or production.
  const [isFetching, setIsFetching] = useState(true);
  const [isSaving, setIsSaving] = useState(false);
  const [fetchError, setFetchError] = useState<string | null>(null);
  const [saveError, setSaveError] = useState<string | null>(null);

  const loadUser = useCallback(async () => {
    setIsFetching(true);
    setFetchError(null);
    try {
      const userData = await fetchUser(userId);
      setUser(userData);
    } catch (err) {
      setFetchError('Could not load profile. Please try again.');
    } finally {
      setIsFetching(false);
    }
  }, [userId]);

  // saveUser is separate from loadUser.
  // It has its own loading state, its own error state.
  // If the product team asks "can we show a spinner only on the save button?"
  // the answer is: already done.
  const saveUser = useCallback(async (data: Partial<User>) => {
    if (!user) return;
    setIsSaving(true);
    setSaveError(null);
    try {
      const updatedUser = await saveUserToApi(user.id, data);
      setUser(updatedUser); // Update local state on success
      return updatedUser;
    } catch (err) {
      setSaveError('Could not save changes. Please try again.');
      throw err; // Re-throw so the calling component can react (e.g., keep form open)
    } finally {
      setIsSaving(false);
    }
  }, [user]);

  useEffect(() => {
    loadUser();
  }, [loadUser]);

  return {
    user,
    isFetching,
    isSaving,
    fetchError,
    saveError,
    saveUser,
    refetch: loadUser,
  };
}

Reason to change #5 & #6: Form state and validation → UserEditForm

This component knows nothing about the API. It knows nothing about the user data structure beyond what it receives as props. Its only job: manage the inputs, validate them locally, and call onSave when the user is done.

// UserEditForm.tsx
// Responsibility: ONE — managing the edit form experience
// Reason to change: ONLY when form fields, validation, or form UX changes
// Note: Every keystroke now re-renders ONLY this component.
// UserDisplay, UserProfileContainer — completely unaffected.

import React, { useState } from 'react';

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

interface UserEditFormProps {
  // We pass the initial values explicitly so the form owns its state fully.
  // The form doesn't know what the "current user" is — it just knows
  // what it started with and what the user wants to change it to.
  initialName: string;
  initialBio: string;
  // isSaving comes from the hook via the container.
  // The form doesn't know WHY it's saving — just that it is.
  isSaving: boolean;
  onSave: (name: string, bio: string) => Promise<void>;
  onCancel: () => void;
}

export const UserEditForm: React.FC<UserEditFormProps> = React.memo(({
  initialName,
  initialBio,
  isSaving,
  onSave,
  onCancel,
}) => {
  const [name, setName] = useState(initialName);
  const [bio, setBio] = useState(initialBio);
  // Local form error — separate from the API save error.
  // "Name is required" is a form concern. "Server rejected the request" is an API concern.
  // They live in different places.
  const [validationError, setValidationError] = useState<string | null>(null);

  const handleSubmit = async () => {
    // Local validation before hitting the API.
    // If validation rules change, this is the only place you touch.
    if (!name.trim()) {
      setValidationError('Name cannot be empty.');
      return;
    }
    if (bio.length > 500) {
      setValidationError('Bio must be 500 characters or less.');
      return;
    }
    setValidationError(null);
    await onSave(name.trim(), bio);
  };

  return (
    <div>
      {validationError && (
        // This is a local validation error — shows inline immediately.
        // The save error from the API is shown in the container.
        <p style={{ color: 'orange' }}>{validationError}</p>
      )}
      <label>
        Name:
        <input
          type="text"
          value={name}
          // This onChange now only re-renders UserEditForm.
          // Nothing else in the tree is affected.
          onChange={(e) => setName(e.target.value)}
          disabled={isSaving}
        />
      </label>
      <label>
        Bio ({bio.length}/500):
        <textarea
          value={bio}
          onChange={(e) => setBio(e.target.value)}
          disabled={isSaving}
        />
      </label>
      <button onClick={handleSubmit} disabled={isSaving}>
        {isSaving ? 'Saving...' : 'Save Changes'}
      </button>
      <button onClick={onCancel} disabled={isSaving}>
        Cancel
      </button>
    </div>
  );
});

UserEditForm.displayName = 'UserEditForm';

Reason to change #4: Display logic → UserDisplay

Pure. Presentational. No state. No side effects. It receives data, it renders data. If the entire visual design of the profile changes, this is the only file you touch.

// UserDisplay.tsx
// Responsibility: ONE — rendering the user profile view
// Reason to change: ONLY when the display design or displayed fields change
// Testable with zero mocks. Just render and assert.

import React from 'react';

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

interface UserDisplayProps {
  user: User;
  onEditClick: () => void;
}

export const UserDisplay: React.FC<UserDisplayProps> = React.memo(({ user, onEditClick }) => (
  <div>
    {user.avatarUrl && (
      <img
        src={user.avatarUrl}
        alt={`${user.name}'s avatar`}
        style={{ width: 80, height: 80, borderRadius: '50%' }}
      />
    )}
    <p><strong>Name:</strong> {user.name}</p>
    <p><strong>Email:</strong> {user.email}</p>
    <p><strong>Bio:</strong> {user.bio}</p>
    <button onClick={onEditClick}>Edit Profile</button>
  </div>
));

UserDisplay.displayName = 'UserDisplay';

Reasons to change #2, #3, #4 (orchestration): The Container

The container is the conductor. It doesn't play any instrument. It just knows what everyone else is doing and coordinates between them.

// UserProfileContainer.tsx
// Responsibility: ONE — orchestrating the profile feature
// Reason to change: ONLY when the feature's flow or composition changes
// (e.g., "add a confirmation step before saving")

import React, { useState } from 'react';
import { useUser } from './useUser';
import { UserDisplay } from './UserDisplay';
import { UserEditForm } from './UserEditForm';

interface UserProfileContainerProps {
  userId: string;
}

export const UserProfileContainer: React.FC<UserProfileContainerProps> = ({ userId }) => {
  const {
    user,
    isFetching,
    isSaving,
    fetchError,
    saveError,
    saveUser,
  } = useUser(userId);

  const [isEditing, setIsEditing] = useState(false);

  const handleSave = async (name: string, bio: string) => {
    try {
      await saveUser({ name, bio });
      // Only close the form if save succeeded.
      // If it throws, the form stays open — user doesn't lose their work.
      setIsEditing(false);
    } catch {
      // The error is already in saveError from the hook.
      // We don't need to do anything here except NOT close the form.
    }
  };

  // Fetch loading state — full page spinner, reasonable here
  if (isFetching) return <div>Loading profile...</div>;
  if (fetchError) return <div style={{ color: 'red' }}>{fetchError}</div>;
  if (!user) return null;

  return (
    <div style={{ border: '1px solid #ccc', padding: '20px', borderRadius: '8px' }}>
      <h2>{user.name}'s Profile</h2>

      {/* API save error — shown at the container level, not buried in the form */}
      {saveError && (
        <div style={{ color: 'red', marginBottom: '12px' }}>
          {saveError}
        </div>
      )}

      {isEditing ? (
        <UserEditForm
          initialName={user.name}
          initialBio={user.bio}
          isSaving={isSaving}
          onSave={handleSave}
          onCancel={() => setIsEditing(false)}
        />
      ) : (
        <UserDisplay
          user={user}
          onEditClick={() => setIsEditing(true)}
        />
      )}
    </div>
  );
};

Now apply the Change Isolation Test again:

API endpoint changes → Touch useUser.ts only
Loading spinner design changes → Touch UserProfileContainer.tsx only (or create a LoadingSpinner component — one file)
We want a different spinner during save → Already handled. isSaving vs isFetching are separate.
Display design changes → Touch UserDisplay.tsx only
Form validation rules change → Touch UserEditForm.tsx only
Add a new editable field → Touch UserEditForm.tsx and useUser.ts only
Error handling strategy changes → Touch UserProfileContainer.tsx only

Seven changes. Seven files affected. But now each file is affected by exactly one of those changes, not all seven. That's not just cleaner code. That's confidence. That's the difference between shipping on Friday and sweating on Saturday.

The Performance Win You Didn't Know You Were Getting

Here's the thing tutorials always get backwards: they show you React.memo and useCallback as the solution to re-render problems. They're not. They're tools that become useful once you've fixed the architecture.

Before the refactor, every keystroke in the name input caused UserProfile to re-render. The entire component. Including the display section, including the header, including any sibling components that happened to be nearby. You could slap React.memo on the whole thing and it wouldn't help — because the state was inside the component, so React.memo has nothing to compare against.

After the refactor, every keystroke in the name input causes UserEditForm to re-render. Only UserEditForm. UserDisplay is sitting there completely unbothered. UserProfileContainer is unbothered. The rest of your page is unbothered.

You got the performance win for free. Not from memoization. From architecture.

Now, about memoization specifically — because this is where I've watched developers cargo-cult their way into slower apps:

What Most Developers Think: useCallback and React.memo prevent re-renders, so more of both = faster app.

What's Actually True in Production: useCallback preserves function reference identity across renders. Whether that prevents re-renders depends entirely on whether the receiving component is wrapped in React.memo. Without React.memo, useCallback adds memory overhead and dependency comparison on every render with zero benefit.

Why the Gap Exists: Because tutorials show the "happy path" where you add React.memo to the child AND useCallback to the parent AND it works. They don't show the case where you add useCallback to a function that's only used inside a useEffect — which is valid — or the case where you wrap a function in useCallback and pass it to a component that isn't memoized — which is just overhead with no upside.

// ⚠️ Common memoization mistake: paying the cost, getting nothing back

// Parent component
const Parent = () => {
  const handleClick = useCallback(() => {
    // some handler
  }, []); // ← useCallback here creates a stable reference

  // But if Child is NOT wrapped in React.memo...
  return <Child onClick={handleClick} />;
  // ...then the stable reference doesn't matter.
  // Child re-renders whenever Parent re-renders regardless.
  // You've paid for the dependency array comparison on every render
  // and received nothing in return.
};

// ✅ useCallback is justified when the child IS memoized:
const Child = React.memo(({ onClick }: { onClick: () => void }) => {
  // Now the stable reference matters.
  // React.memo can say "onClick reference didn't change — skip re-render."
  return <button onClick={onClick}>Click me</button>;
});

The rule: Profile first. Optimize second. Open React DevTools Profiler. Record a session while using the feature. Look for components that render more than once when you'd expect them to render zero times. Then reach for React.memo and useCallback. Not before.

I've seen codebases where every function was wrapped in useCallback "for performance." The actual profiler showed zero difference in render counts. What it did show was slightly longer render times — from the dependency array comparisons that were happening on every render for no reason.

The State Discipline Rule You'll Use Every Day

Before you add a new useState call, ask one question: "Can this be derived from state that already exists?"

Derived state is one of the most common sources of bugs in React applications. It's not dramatic — it doesn't throw errors. It just silently gets out of sync.

// 🚫 The bug factory
const ProfileStats = ({ user }: { user: User }) => {
  // These three are derived from user — but stored as separate state.
  // They'll be correct on mount. But what happens when user changes?
  // You have to remember to update all three. Every time. Forever.
  const [displayName, setDisplayName] = useState(user.name);
  const [isVerified, setIsVerified] = useState(user.email.endsWith('@company.com'));
  const [bioWordCount, setBioWordCount] = useState(user.bio.split(' ').length);

  // Later, when user updates...
  // Did you remember to update displayName?
  // Did you remember to update isVerified?
  // Did you remember to update bioWordCount?
  // This is how subtle data inconsistency bugs are born.

  return <div>{displayName} ({bioWordCount} words in bio)</div>;
};

// ✅ Derive it. Don't store it.
const ProfileStats = ({ user }: { user: User }) => {
  // These are computed on every render.
  // They are ALWAYS in sync with user. No exceptions. No bugs.
  // And because they're simple calculations, the performance cost is negligible.
  const displayName = user.name;
  const isVerified = user.email.endsWith('@company.com');
  const bioWordCount = user.bio.split(' ').length;

  return <div>{displayName} ({bioWordCount} words in bio)</div>;
};

The only time to reach for useMemo on derived values is when the computation is genuinely expensive — we're talking sorting a list of ten thousand items, running a heavy calculation, or building a complex data structure. For everything else, compute it inline. React is fast. Your render functions are fast. Trust the platform.

The Uncomfortable Truth: You Will Recreate This Problem

Here's what I want to tell you that nobody else will.

You can do this refactor perfectly today. Every responsibility in its own file, every hook clean, every component pure. And six months from now, after three sprints of feature requests and two rounds of "just put it here for now, we'll clean it up later" — you'll have a new component with seven reasons to change.

This is not a failure of discipline. This is gravity. Codebases accumulate complexity the way kitchen drawers accumulate miscellaneous objects. The question isn't "how do I prevent it forever?" It's "how do I recognize it early enough to fix it before it becomes a legacy nightmare?"

The Change Isolation Test. Run it on your components every time you're about to open one to add a feature. Not as a refactoring ceremony — just as a quick gut-check. "How many reasons does this component have to change?" If the number is more than two, and you're about to add another feature to it, stop. Spend twenty minutes extracting just the thing you're about to add into its own home. You don't have to refactor the whole thing. Just don't make it worse.

Real Objections, Real Answers

Objection 1: "This is over-engineering for a simple component. Not everything needs four files."

Completely valid — with a caveat. A truly simple component with one responsibility doesn't need to be split. A LoadingSpinner that takes a message prop and renders a spinner? That's one file, one responsibility, done. The rule applies when the component has multiple reasons to change, not as a blanket "always split into hooks and containers." Use the Change Isolation Test. If the number is one, you're fine. If it's growing, that's the signal.

Objection 2: "Prop drilling gets worse with this pattern. Now I'm passing isSaving through multiple layers."

Fair. And the answer depends on your scale. For a contained feature like UserProfile, passing isSaving one level down (from container to form) is absolutely fine — it's one prop, one level. When you're passing the same prop through five layers to reach a deeply nested component, that's when context or a state management solution earns its place. The pattern I've shown here doesn't create prop drilling — it creates clear data flow. Those are different problems.

Objection 3: "Custom hooks are just moving the problem. The hook is still doing multiple things."

If your hook is doing multiple things, yes — it's the same problem, different location. useUser as I've written it has one job: manage the lifecycle of user data (fetch and save). If your hook is also managing UI state, routing, and analytics events, then the hook needs the same treatment the component got. The principle doesn't change based on whether you're looking at a component or a hook.

That said — there ARE cases where a single hook managing fetch AND save makes sense because they're tightly coupled to the same data entity. The test is still "how many reasons does this have to change?" If the fetch strategy and save strategy will always change together, they belong together. If they could evolve independently, separate them.

Resuources

📄 Article: "Making Sense of React Hooks" by Dan Abramov
- Why it made my brain itch: He explains the why behind hooks in a way that makes the design feel inevitable rather than arbitrary. Read it after you feel comfortable with hooks, not before.
📄 Article: "Application State Management with React" by Kent C. Dodds
- Why it made my brain itch: He makes the case for colocation — keeping state as close to where it's used as possible. Changed how I think about where things live.
🎥 Video: "React Performance" by Jack Herrington on YouTube
- Skip to minute 8:00: Where he shows an actual real-world app getting slower from too much memoization. Worth every second.
💬 Quote I'm stealing:

"Make it work, make it right, make it fast."
— Kent Beck

Why this stays with me: In that order. Most re-render problems I've seen were caused by trying to make it fast before making it right.

Here's what I'm still working through:

Where does the line between "this hook is doing too much" and "this hook is appropriately managing a domain" live in practice? In theory, useUser should only know about user data. But in a real application, saving a user profile might invalidate a cache, trigger an analytics event, update a global notification — at what point does the hook need to hand those concerns off, and to whom?

I've gone back and forth on this. My current position: the hook hands back the raw result and lets the caller decide what to do with it. Side effects like analytics belong in the container. Cache invalidation belongs in the API layer or a library like React Query that handles it natively.

But I've been wrong about this before. And I'll probably refine it again.

What's your current pattern for managing side effects that cut across concerns? I'm genuinely curious — drop it in the comments.

Code is not a sculpture. It's a public square. Other people have to walk through it after you.

The UserProfile component I described at the start of this article — the one with seven reasons to change — it wasn't written by a bad developer. It was written by me, under deadline pressure, making what felt like a reasonable call at the time. "It's just one component. I'll clean it up later."

Later never came. The feature shipped. The component grew. The Saturday bug happened.

The Change Isolation Test is the "clean it up later" that you do now, in twenty minutes, before the component becomes someone else's problem. Or your future self's problem. Which is worse.

Simple? Yes. Easy? Absolutely not. 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

React 19 Is Already Here. You're Just Not Ready for It.

Bishoy Bishai — Wed, 01 Apr 2026 11:36:44 +0000

React 19 Is Already Here. You're Just Not Ready for It.

And that's not an insult. It's the most honest thing I can say.

React 19 dropped stable in December 2024. The React Compiler — what you might know as "React Forget" — hit beta the same month. React Server Components have been in production via Next.js since 2023. The feature set is real. The ecosystem is catching up. The question isn't "is React 19 ready?" anymore.

The question is: are you ready to understand what it actually means?

Because here's the uncomfortable truth most articles won't tell you: React 19 doesn't forgive ignorance. If you don't understand why re-renders happen, the Compiler won't save you. If you don't understand the server-client boundary, RSCs will break your app in ways that take hours to debug. This isn't React asking you to re-learn everything — it's React asking you to finally understand the fundamentals you skipped.

This article is for the senior who's been doing React for 5 years but never actually understood what useMemo costs. It's for Bishoy at 23, who would have wasted two weeks on this without someone honest to explain it.

After reading this, you will be able to:

Explain the React Compiler to your Tech Lead without hand-waving
Know exactly when to use Server Components and when they'll blow up in your face
Debug the most common RSC mistakes before they hit production
Make a confident, specific decision about whether to migrate today or wait

Let's get into it.

THE SETUP — Why React 19, Why Now

React has always had one fundamental problem. It's not a bug. It's a feature that became its own worst enemy: the re-render.

Every time state changes in a React component, React re-renders that component and — by default — every component below it in the tree. This is fine when your component tree is small. It becomes a production nightmare when you have a dashboard with 200+ components, complex state management, and users who notice when things feel slow.

The traditional solution was manual memoization: React.memo for components, useMemo for computed values, useCallback for functions passed as props. Developers learned this the hard way — usually after their first profiling session revealed that one parent component was causing 80% of their re-renders.

Here's what nobody tells juniors: memoization has a cost. Every useMemo call allocates memory and runs a comparison check on every render, even when it's not needed. Used incorrectly, you can make your app slower by trying to optimize it. I've done this.

React 19 addresses this problem from two different directions simultaneously. The Compiler handles the memoization problem. RSCs handle the data fetching problem. And a set of new hooks — useActionState, useFormStatus, useOptimistic — handle the async interaction problem.

This isn't a version bump. This is React paying off years of technical debt it accumulated from its own success.

THE BREAKDOWN — The Problem React 19 Is Actually Solving

Before I explain what React 19 does, I need to show you what breaks without it. This is the pattern I've seen in every React codebase I've touched in 15 years — from the IoT dashboards I was building in 2014 to the enterprise security panels I work on today.

The Re-render Waterfall

// This is a real pattern. I've seen it in production.
// It looks innocent. It is not.

function Dashboard() {
  const [searchText, setSearchText] = useState('');
  const [selectedFilter, setSelectedFilter] = useState('all');

  return (
    <div>
      <SearchBar
        value={searchText}
        onChange={setSearchText}
      />
      <FilterPanel
        selected={selectedFilter}
        onFilterChange={setSelectedFilter}
      />
      {/* This re-renders on EVERY searchText change */}
      {/* Even though it only cares about selectedFilter */}
      <ExpensiveDataTable
        filter={selectedFilter}
        search={searchText}
      />
    </div>
  );
}

Every time the user types a character in SearchBar, the entire Dashboard re-renders. FilterPanel re-renders. ExpensiveDataTable re-renders. If ExpensiveDataTable has 50 child rows, each of those re-renders too.

The traditional fix:

// The "optimized" version — before React 19

function Dashboard() {
  const [searchText, setSearchText] = useState('');
  const [selectedFilter, setSelectedFilter] = useState('all');

  // Memoize the search handler so SearchBar doesn't
  // cause unnecessary re-renders downstream
  const handleSearchChange = useCallback((text: string) => {
    setSearchText(text);
  }, []); // Empty deps — this function never changes

  const handleFilterChange = useCallback((filter: string) => {
    setSelectedFilter(filter);
  }, []); // Same here

  // Memoize the filtered data computation
  const tableProps = useMemo(() => ({
    filter: selectedFilter,
    search: searchText,
  }), [selectedFilter, searchText]);

  return (
    <div>
      <SearchBar
        value={searchText}
        onChange={handleSearchChange} // Stable reference
      />
      <FilterPanel
        selected={selectedFilter}
        onFilterChange={handleFilterChange} // Stable reference
      />
      <MemoizedDataTable {...tableProps} />
    </div>
  );
}

// And you need this too:
const MemoizedDataTable = React.memo(ExpensiveDataTable);

This works. But look at what you had to do:

Add useCallback twice
Add useMemo once
Wrap the child component in React.memo
Think carefully about dependency arrays
Pray you didn't miss a dependency

And this is a simple example. In production, with 10 developers working on the same codebase, this pattern breaks constantly. Someone forgets React.memo. Someone adds a prop to the dependency array that shouldn't be there. Someone passes an inline object as a prop and breaks memoization silently.

This is the problem React 19's Compiler exists to solve.

THE MATCH REPORT — What React 19 Actually Changes

1, 2, 3, Tap — The React Compiler

The React Compiler (previously called React Forget) is a build-time tool that analyzes your component code and automatically inserts memoization where it's needed. You write clean, obvious code. The compiler makes it performant.

// What YOU write with React Compiler enabled:

function Dashboard() {
  const [searchText, setSearchText] = useState('');
  const [selectedFilter, setSelectedFilter] = useState('all');

  // No useCallback. No useMemo. No React.memo.
  // Just... code.

  return (
    <div>
      <SearchBar
        value={searchText}
        onChange={(text) => setSearchText(text)} // Inline function — FINE now
      />
      <FilterPanel
        selected={selectedFilter}
        onFilterChange={(f) => setSelectedFilter(f)} // Also fine
      />
      <ExpensiveDataTable
        filter={selectedFilter}
        search={searchText}
      />
    </div>
  );
}

The compiler looks at this code and figures out: "The inline function (text) => setSearchText(text) doesn't depend on anything outside Dashboard that changes. I can make it stable." It inserts memoization at compile time. The output is performant code without you having to think about it.

But here's what the tutorials don't say — and this is the Red Card moment:

Red Card 🟥 — The Compiler only works if your code follows React's rules.

The Rules of React aren't just guidelines. They're the contract the Compiler depends on. If you violate them, the Compiler silently opts that component out of optimization. Your code still runs. It's just not optimized. And you have no idea.

The three rules that trip up the most developers:

Rule 1: Components must be pure — same inputs, same output. Side effects only in useEffect.

// 🚫 This breaks the Compiler's analysis:
let globalCounter = 0;

function BadComponent({ name }: { name: string }) {
  globalCounter++; // Mutation of external variable
  return <div>{name} — render #{globalCounter}</div>;
}

// ✅ This is what the Compiler can optimize:
function GoodComponent({ name, renderCount }: { name: string; renderCount: number }) {
  return <div>{name} — render #{renderCount}</div>;
}

Rule 2: Hooks rules — no conditional hooks, no hooks in loops. The Compiler depends on the hook call order being stable.

Rule 3: Don't mutate props or state — always create new objects/arrays.

// 🚫 The Compiler cannot optimize components that do this:
function BadList({ items }: { items: Item[] }) {
  items.push({ id: 'temp', name: 'Loading...' }); // Mutation!
  return <ul>{items.map(i => <li key={i.id}>{i.name}</li>)}</ul>;
}

// ✅ Create new arrays:
function GoodList({ items }: { items: Item[] }) {
  const displayItems = [...items, { id: 'temp', name: 'Loading...' }];
  return <ul>{displayItems.map(i => <li key={i.id}>{i.name}</li>)}</ul>;
}

The Compiler is not magic. It's a very smart tool that rewards clean code.

If your codebase has violations — and most production codebases do — you need to fix them before the Compiler helps you. The good news: the React team ships an ESLint plugin that surfaces violations. Run it. Fix what it finds. Then enable the Compiler.

How to Enable It Today

npm install -D babel-plugin-react-compiler
# or with Next.js 15+:
# It's already in the experimental config

// next.config.js
const nextConfig = {
  experimental: {
    reactCompiler: true,
  },
};

module.exports = nextConfig;

// For non-Next.js projects, babel.config.js:
module.exports = {
  plugins: [
    ['babel-plugin-react-compiler', {
      // Start with specific files to test
      sources: (filename) => filename.includes('src/components'),
    }],
  ],
};

My recommendation: Don't enable it globally on day one. Enable it file by file, watch your bundle analyzer, run your tests. The Compiler is in beta. It's stable enough to use, but you want to be able to isolate issues.

2. React Server Components — The Thing Most Developers Get Wrong

RSCs are the most powerful and the most misunderstood feature in the React 19 ecosystem. Let me explain them the way I wish someone had explained them to me.

The mental model shift:

Before RSCs, there were two ways to get data into your component:

Fetch in useEffect (client-side, after render)
Fetch in getServerSideProps or getStaticProps (Next.js patterns, tied to pages)

Both have problems. useEffect fetching causes waterfalls — component A renders, fires a request, waits, then renders component B, which fires another request. You've seen this: the spinning spinner on top of a spinning spinner.

getServerSideProps solves the waterfall but creates a new problem: it's page-level only. If your data is needed by a deeply nested component, you have to pass it through 5 layers of props, or put it in global state. Neither is clean.

RSCs give components the ability to fetch their own data on the server, in parallel, before anything reaches the client.

// @/app/dashboard/page.tsx
// This is a Server Component by default in Next.js App Router

import { getUserMetrics } from '@/lib/db';
import { getActiveAlerts } from '@/lib/alerts';
import MetricsPanel from '@/components/MetricsPanel';
import AlertsPanel from '@/components/AlertsPanel';
import FilterControls from '@/components/FilterControls'; // Client Component

export default async function DashboardPage() {
  // These run IN PARALLEL on the server
  // No waterfall. No loading state. No useEffect.
  const [metrics, alerts] = await Promise.all([
    getUserMetrics(),
    getActiveAlerts(),
  ]);

  return (
    <div className="dashboard">
      {/* Server Component — no JS shipped to client */}
      <MetricsPanel data={metrics} />

      {/* Server Component — no JS shipped to client */}
      <AlertsPanel alerts={alerts} />

      {/* Client Component — needs interactivity */}
      <FilterControls />
    </div>
  );
}

MetricsPanel and AlertsPanel are Server Components. They render on the server, produce HTML, and ship zero JavaScript to the client. The browser receives rendered HTML for those components. Instant paint. No hydration delay.

FilterControls needs client-side interactivity — state, event handlers — so it's a Client Component. It gets hydrated in the browser.

The bundle size impact is real. In a project I was analyzing recently, moving data-display components to Server Components reduced the client bundle by 34%. Components that imported heavy libraries (date formatters, chart utilities) for display-only purposes now ran those imports exclusively on the server. The client never downloaded them.

The Server-Client Boundary — Where Everything Goes Wrong

This is where I need to slow down and be precise, because this is where developers spend hours debugging.

The boundary rule: A Server Component can import and render Client Components. A Client Component cannot import Server Components.

// ✅ This works — Server Component rendering a Client Component:

// ServerComponent.tsx (no 'use client' directive)
import ClientButton from './ClientButton'; // Client Component

export default async function ServerComponent() {
  const data = await fetchData();
  return (
    <div>
      <p>{data.title}</p>
      <ClientButton label="Click me" /> {/* Fine */}
    </div>
  );
}

// 🚫 This BREAKS — Client Component trying to use a Server Component:

'use client';
// ClientWrapper.tsx
import ServerDataFetcher from './ServerDataFetcher'; // Server Component

export default function ClientWrapper() {
  const [count, setCount] = useState(0);
  return (
    <div>
      <ServerDataFetcher /> {/* This will error. Server Component inside Client. */}
      <button onClick={() => setCount(c => c + 1)}>{count}</button>
    </div>
  );
}

The error message you'll see: Error: async/await is not yet supported in Client Components, only Server Components.

It's confusing because the reason is that Server Components are async by nature — they can await promises. Client Components can't run async code at the top level. When you try to nest a Server Component inside a Client Component, React doesn't know how to handle the async boundary.

The fix: Pass server data as props, or pass Server Components as children.

// ✅ Pattern 1: Pass data down as props

// ServerParent.tsx
import ClientWrapper from './ClientWrapper';

export default async function ServerParent() {
  const data = await fetchData(); // Runs on server
  return <ClientWrapper initialData={data} />; // Pass as prop
}

// ClientWrapper.tsx
'use client';
export default function ClientWrapper({ initialData }) {
  const [data, setData] = useState(initialData);
  // Now you have client-side state AND server-fetched initial data
  return <div>{/* render data */}</div>;
}

// ✅ Pattern 2: Pass Server Components as children (the elegant solution)

// ServerParent.tsx
import ClientWrapper from './ClientWrapper';
import ServerDisplay from './ServerDisplay';

export default async function ServerParent() {
  return (
    <ClientWrapper>
      <ServerDisplay /> {/* Server Component passed as children prop */}
    </ClientWrapper>
  );
}

// ClientWrapper.tsx
'use client';
export default function ClientWrapper({ children }) {
  const [isOpen, setIsOpen] = useState(false);
  return (
    <div>
      <button onClick={() => setIsOpen(!isOpen)}>Toggle</button>
      {isOpen && children} {/* ServerDisplay renders here, still on server */}
    </div>
  );
}

Pattern 2 is the one most tutorials skip. It feels strange at first — how can a Client Component render a Server Component? The answer: it doesn't. The Server Component was already rendered on the server. The Client Component is just deciding where to place the already-rendered output.

When NOT to Use Server Components

This is the part I want tattooed somewhere visible.

Don't use Server Components for:

Anything with event handlers — onClick, onChange, onSubmit. These require client-side JS. Server Components can't have them.
Anything with React state — useState, useReducer. No state on the server.
Anything with browser APIs — window, localStorage, navigator. The server doesn't have a browser.
Anything that needs real-time updates — WebSockets, polling. Server Components render once, at request time.

// 🚫 Common mistake — trying to use state in a Server Component:

// ProductCard.tsx (accidentally Server Component — no 'use client')
export default async function ProductCard({ productId }) {
  const product = await getProduct(productId);

  // THIS WILL ERROR:
  const [isWishlisted, setIsWishlisted] = useState(false);

  return (
    <div>
      <h3>{product.name}</h3>
      <button onClick={() => setIsWishlisted(!isWishlisted)}>
        {isWishlisted ? '❤️' : '🤍'}
      </button>
    </div>
  );
}

The fix: Split it. The data-fetching part is a Server Component. The interactive part is a Client Component.

// ✅ ProductCard.tsx — Server Component
import WishlistButton from './WishlistButton'; // Client Component

export default async function ProductCard({ productId }) {
  const product = await getProduct(productId);

  return (
    <div>
      <h3>{product.name}</h3>
      <p>{product.description}</p>
      {/* Interactivity lives in the Client Component */}
      <WishlistButton productId={productId} />
    </div>
  );
}

// WishlistButton.tsx — Client Component
'use client';
export default function WishlistButton({ productId }) {
  const [isWishlisted, setIsWishlisted] = useState(false);

  return (
    <button onClick={() => setIsWishlisted(!isWishlisted)}>
      {isWishlisted ? '❤️' : '🤍'}
    </button>
  );
}

3. The New Hooks — Actions and Async State

React 19 ships three new hooks that change how you handle form submissions and async operations. These are smaller in footprint than the Compiler and RSCs, but they'll show up in your daily code immediately.

`useActionState` — The End of Verbose Form State

Before React 19, a form with proper loading, error, and success states looked like this:

// Before React 19 — the verbose version
function ContactForm() {
  const [isPending, setIsPending] = useState(false);
  const [error, setError] = useState<string | null>(null);
  const [success, setSuccess] = useState(false);

  const handleSubmit = async (e: React.FormEvent) => {
    e.preventDefault();
    setIsPending(true);
    setError(null);
    setSuccess(false);

    try {
      await submitContactForm(new FormData(e.target as HTMLFormElement));
      setSuccess(true);
    } catch (err) {
      setError(err instanceof Error ? err.message : 'Something went wrong');
    } finally {
      setIsPending(false);
    }
  };

  return (
    <form onSubmit={handleSubmit}>
      <input name="email" type="email" />
      <button disabled={isPending}>
        {isPending ? 'Sending...' : 'Send'}
      </button>
      {error && <p className="error">{error}</p>}
      {success && <p className="success">Message sent!</p>}
    </form>
  );
}

Six state variables and a try/catch/finally. Every form. Every time.

With useActionState:

// React 19 — useActionState
import { useActionState } from 'react';

type FormState = {
  error: string | null;
  success: boolean;
};

async function submitAction(
  prevState: FormState,
  formData: FormData
): Promise<FormState> {
  try {
    await submitContactForm(formData);
    return { error: null, success: true };
  } catch (err) {
    return {
      error: err instanceof Error ? err.message : 'Something went wrong',
      success: false,
    };
  }
}

function ContactForm() {
  const [state, formAction, isPending] = useActionState(submitAction, {
    error: null,
    success: false,
  });

  return (
    <form action={formAction}>
      <input name="email" type="email" />
      <button disabled={isPending}>
        {isPending ? 'Sending...' : 'Send'}
      </button>
      {state.error && <p className="error">{state.error}</p>}
      {state.success && <p className="success">Message sent!</p>}
    </form>
  );
}

Notice action={formAction} on the form. In React 19, <form> elements can accept async functions as their action prop. React handles the pending state automatically. Your component logic is now: define the action, render based on state. That's it.

`useFormStatus` — Knowing What's Happening Above You

This hook solves a specific but very common problem: a submit button that needs to know if the form it's inside is pending, without passing props through multiple layers.

// useFormStatus — the button knows its own form's state
import { useFormStatus } from 'react-dom';

function SubmitButton() {
  const { pending } = useFormStatus();
  // 'pending' is true when the parent form's action is running
  // No props needed. No context. It just knows.

  return (
    <button type="submit" disabled={pending}>
      {pending ? 'Submitting...' : 'Submit'}
    </button>
  );
}

// Use it anywhere inside a form:
function MyForm() {
  return (
    <form action={someServerAction}>
      <input name="data" />
      <SubmitButton /> {/* Automatically aware of form state */}
    </form>
  );
}

This sounds small. It isn't. In a design system with a shared Button component used across dozens of forms, this eliminates an entire class of prop-threading.

`useOptimistic` — The UX Win You Can Ship This Week

Optimistic updates have always been possible in React. They've never been this clean.

// useOptimistic — update UI immediately, sync with server after
import { useOptimistic, useActionState } from 'react';

type Message = {
  id: string;
  text: string;
  sending?: boolean; // Optimistic flag
};

function MessageThread({ messages }: { messages: Message[] }) {
  const [optimisticMessages, addOptimisticMessage] = useOptimistic(
    messages,
    (currentMessages, newMessage: Message) => [
      ...currentMessages,
      { ...newMessage, sending: true }, // Show immediately with 'sending' flag
    ]
  );

  const [, formAction] = useActionState(
    async (prevState: null, formData: FormData) => {
      const text = formData.get('text') as string;
      const tempMessage: Message = { id: crypto.randomUUID(), text };

      addOptimisticMessage(tempMessage); // Update UI immediately

      await sendMessage(text); // Then actually send
      return null;
    },
    null
  );

  return (
    <div>
      <ul>
        {optimisticMessages.map((msg) => (
          <li
            key={msg.id}
            style={{ opacity: msg.sending ? 0.5 : 1 }} // Visual feedback
          >
            {msg.text}
            {msg.sending && ' (sending...)'}
          </li>
        ))}
      </ul>
      <form action={formAction}>
        <input name="text" />
        <button type="submit">Send</button>
      </form>
    </div>
  );
}

The message appears in the UI instantly. If the server call fails, React automatically rolls back to the previous state. If it succeeds, the optimistic message gets replaced by the real one. This is the UX pattern that makes apps feel fast — and React 19 makes it a handful of lines instead of a whole state machine.

THE TECHNICAL DEEP DIVE — React 18 vs React 19: What Changed in Production

Let me be specific. Here's a side-by-side of the most common patterns and how they change:

Data Fetching

// React 18 — data fetching in useEffect
function UserProfile({ userId }: { userId: string }) {
  const [user, setUser] = useState<User | null>(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<Error | null>(null);

  useEffect(() => {
    let cancelled = false;

    async function fetchUser() {
      try {
        const data = await getUser(userId);
        if (!cancelled) {
          setUser(data);
        }
      } catch (err) {
        if (!cancelled) {
          setError(err instanceof Error ? err : new Error('Unknown error'));
        }
      } finally {
        if (!cancelled) {
          setLoading(false);
        }
      }
    }

    fetchUser();
    return () => { cancelled = true; }; // Cleanup for StrictMode
  }, [userId]);

  if (loading) return <Spinner />;
  if (error) return <ErrorState message={error.message} />;
  if (!user) return null;

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

// React 19 with RSC — data fetching is just... async/await
// UserProfile.tsx (Server Component)

export default async function UserProfile({ userId }: { userId: string }) {
  // This runs on the server. No useEffect. No loading state.
  // Errors bubble to the nearest error.tsx boundary.
  const user = await getUser(userId);

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

The Server Component version is not simpler by accident. It's simpler because you've moved the async work to where async work belongs: the server, where there's no browser paint to block and no cleanup function needed because there's no component lifecycle.

Error Handling

React 19 improves Error Boundaries with better integration:

// app/users/[id]/error.tsx — Next.js App Router error boundary
'use client'; // Error boundaries must be client components

export default function UserError({
  error,
  reset,
}: {
  error: Error & { digest?: string };
  reset: () => void;
}) {
  return (
    <div>
      <h2>Something went wrong loading this profile.</h2>
      <p>{error.message}</p>
      <button onClick={() => reset()}>Try again</button>
    </div>
  );
}

When the Server Component throws, Next.js catches it and renders this boundary automatically. No manual try/catch in your component. No complex error state management. The error surface is clean and predictable.

`use()` — The New Data Primitive

React 19 ships a new primitive called use() that lets you read promises and context in Client Components without useEffect:

// The new use() hook
import { use, Suspense } from 'react';

// In a Client Component:
'use client';

function UserCard({ userPromise }: { userPromise: Promise<User> }) {
  // use() suspends the component until the promise resolves
  // No useEffect. No useState. No loading flag.
  const user = use(userPromise);

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

// In the parent Server Component:
export default function Page({ params }) {
  // Start fetching immediately, pass the Promise down
  const userPromise = getUser(params.id);

  return (
    <Suspense fallback={<Spinner />}>
      <UserCard userPromise={userPromise} />
    </Suspense>
  );
}

This pattern — start the fetch in the Server Component, pass the promise to the Client Component — eliminates the waterfall without requiring the Client Component to be async. The Suspense boundary handles the loading state.

THE UNCOMFORTABLE TRUTH

Here it is. The thing the hype doesn't say.

React 19's improvements are most valuable for developers who already understand React 18 deeply.

The Compiler helps you avoid bugs with memoization — but only if you already know what memoization is for. If you don't understand why useCallback exists, you can't tell when the Compiler has opted your component out. You'll think it's working. It isn't.

RSCs simplify data fetching — but only if you understand the server-client boundary well enough to know what can't go on the server. The number one RSC bug in production is trying to use browser APIs (localStorage, window) in a Server Component. The error message is confusing. The fix is trivial — but only if you understand the mental model.

The trap for mid-level developers: seeing the simplified code, learning the patterns by imitation, and building apps that work in development but fail in production edge cases. I've seen this happen. At Selfapy, building the first mobile app with React Native, I watched a developer copy patterns from tutorials without understanding the execution environment — and we found the bugs three days before launch.

There's no shortcut here. React 19 rewards understanding. It punishes cargo-culting.

The trap for senior developers: dismissing these features because "the fundamentals haven't changed." They have. The mental model for data fetching has changed. The boundary between server and client is a new concept that doesn't have a clean equivalent in React 18. Seniors who don't engage with RSCs seriously are going to be debugging Next.js App Router issues they don't understand.

Both traps have the same solution: go slow, go deep, understand before you build.

PRO TIP — The Migration Playbook I'd Follow Today

I wish someone had given me this specific, ordered list when App Router shipped.

Week 1 — Audit, don't migrate:

Run the React Compiler's ESLint plugin on your codebase:

npm install -D eslint-plugin-react-compiler

// .eslintrc
{
  "plugins": ["react-compiler"],
  "rules": {
    "react-compiler/react-compiler": "error"
  }
}

Count your violations. If you have more than 20, fix them before enabling the Compiler. Each violation is a component the Compiler won't optimize.

Week 2 — Enable the Compiler on leaf components first:

Leaf components — components that don't have complex children — are the safest to enable first. Enable it on your design system components: buttons, inputs, cards. Watch your Lighthouse scores.

Week 3 — Identify your Server Component candidates:

A component is a good Server Component candidate if:

It fetches data directly
It doesn't have event handlers or state
It imports heavy libraries purely for display (date-fns, lodash, chart libs)

Mark them. Plan the split.

Week 4 — Migrate one feature end-to-end:

Pick one route in your app. Migrate it fully — Server Components for data, Client Components for interactivity. Measure the bundle size difference before and after. That number becomes your business case for the rest of the migration.

The thing I wish I'd known: Don't migrate the layout layer first. Start with leaf data components. The layout layer is where the server-client boundary gets complicated, and you want to understand the pattern before you wrestle with it in the most complex part of your app.

VAR SECTION — The Objections I'd Raise in Code Review

Objection 1: "The Compiler is in beta. It's not production-ready."

Partially fair. The Compiler is beta — but it's running in production at Meta. The Instagram web app uses it. The risk profile is: the Compiler opts out of optimizing components it's unsure about, rather than optimizing them incorrectly. Your app won't break. You just might not get the optimization. For low-risk components (pure display components with no side effects), enabling it in production today is reasonable. For complex stateful components, wait for the stable release.

Objection 2: "We're not on Next.js. RSCs don't apply to us."

Currently, RSCs require framework support. Next.js App Router and Remix (via Vite + React Router v7) are the main options. If you're on Vite with React only, you're not getting RSCs yet. But the React team is working on standalone RSC support. Keep watching the React server rendering RFC. This will come to more frameworks.

Objection 3: "We don't have performance problems. Why migrate?"

That's the wrong frame. React 19 isn't about fixing performance problems you already have — it's about not building performance problems into your next project. If you're starting a new app today and not using RSCs, you're going to write waterfall data fetching that you'll need to fix in 18 months. The correct time to learn the patterns is before the technical debt exists, not after.

That said: if you have a stable, working React 18 app with no performance issues and no new features planned, there's no urgency to migrate. React 18 is supported. Don't fix what isn't broken.

BISHOY'S BOOKMARKS — إذا عاوز تغوص أعمق

📄 Article: "React Compiler Beta Release" — React Official Blog (October 2024)

Why it made my brain itch: The section explaining why the Compiler opts out of optimizing non-compliant components — silently, without errors — is the most important paragraph in the whole post. Read it twice before you enable the Compiler on your codebase.

📄 Article: "Making Sense of React Server Components" — Josh W. Comeau

Why it made my brain itch: The best visual explanation of the server-client boundary I've found anywhere. Josh draws the line between SSR and RSCs in a way that makes the 'use client' directive finally click. The diagrams alone are worth 30 minutes of your time.

📄 RFC: "React Server Components RFC #0188" — reactjs/rfcs on GitHub

Why it made my brain itch: Reading the "Motivation" section of the original RFC answers every "but why did they build this?" question. The React team wasn't chasing a trend — they were solving specific, measured pain points. Understanding those pain points makes every RSC decision obvious.

🎥 Video: "The Modern Full-Stack React Tutorial" — Theo Browne (t3dotgg) on YouTube

Why it's here: Theo covers RSCs, Server Actions, and the App Router mental model in the most honest, opinionated way I've seen. He doesn't hand-wave the hard parts. Search his channel for "React 19" — his reaction videos to the React team's announcements are unfiltered and technically solid.

📄 Docs: "React Compiler — Rules of React" — react.dev

Why it made my brain itch: This is the contract the Compiler depends on. Every violation is a component the Compiler will silently skip. Run the ESLint plugin against your codebase and count the violations before you do anything else.

💬 Quote I'm keeping:

"React Compiler is able to compile code safely by modeling both the rules of JavaScript and the rules of React." — React Labs blog, February 2024

Why this stays with me: The operative word is "safely." The Compiler won't break your app. It will just quietly not optimize the parts that don't follow the rules. That's both reassuring and dangerous — because you can think it's working when it isn't.

THE UNFINISHED CHAPTER

I want to be honest about what I don't fully understand yet.

The Compiler's interaction with complex custom hooks — I know it works well with simple hooks. I'm not confident yet about highly stateful hooks with complex dependency graphs. I've seen it behave unexpectedly with hooks that have nested useEffect calls. I'm still testing this.

The cache() primitive — React 19 ships a cache() function for deduplicating requests in Server Components. I understand the theory. I haven't built enough with it yet to have opinions about where it fails. If you have, I want to hear about it.

The long-term of RSC and client state management — Redux, Zustand, Jotai. These all work with Client Components. But as more logic moves to the server, I have a genuine open question: does the role of client-side state management shrink dramatically? In five years, is most of what we put in Zustand today just... server state managed by RSCs? I think yes. I'm not sure.

And here's the thing I got wrong for two years: I thought SSR and RSCs were the same thing. They're not even close. SSR is a rendering technique. RSCs are an architectural model. Conflating them caused me to dismiss RSC discussions as "we already do SSR." If I had understood the distinction earlier, I would have been more useful to my team when we migrated.

What are you still confused about? Drop it in the comments. I'll write the follow-up.

✨ 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? Check out my book: Surrounded by AI

Micro Frontend vs SPA: Which Architecture Should You Choose?

Bishoy Bishai — Wed, 25 Mar 2026 11:28:02 +0000

Micro Frontend vs. SPA: Which Architecture Should You Choose?

There comes a point in every successful application's journey where the simple architectural choices you made early on start to feel... heavy. Perhaps your Single Page Application (SPA), once a nimble Ferrari, is now a lumbering cargo truck, struggling to deliver new features efficiently. Or maybe, you're just starting a new project, and you're haunted by the ghosts of previous monolithic struggles, wondering if there's a better way to build for scale from day one.

You’re not alone. This is the exact dilemma that leads many engineering teams down the path of comparing Micro Frontends to the good old SPA. And honestly, it’s not a simple "one is better than the other" answer. It's about tradeoffs, context, and understanding your team's unique challenges.

The Familiar Comfort of the SPA: When Simplicity Reigns

Let's start with what most of us know and love: the Single Page Application. Think about a typical React application built with Create React App, Vite, or Next.js. You have a single codebase, a single build process, and a single deployment artifact (usually a bunch of static files).

The Upside (and why we loved it initially):

Simplicity: One repo, one language, one framework. Easier to set up, understand, and get started.
Unified User Experience: It’s often simpler to maintain consistent styling, navigation, and state across the entire application because everything lives together.
Performance (Initial Load): Once loaded, navigation is super fast because resources are already on the client.
Easier Deployment: One artifact to push to production. Less coordination needed.

The Downside (and why it starts to chafe):

Monolith Tendencies: As your application grows, the codebase becomes a giant ball of mud. Fear sets in when making changes because you might break something unrelated.
Team Scaling Nightmares: Multiple teams trying to work on the same massive codebase often lead to merge conflicts, slow PR reviews, and stepping on each other's toes.
Tech Stack Lock-in: Stuck with one framework or library choice. Want to try something new? Good luck refactoring the whole thing.
Single Point of Failure: A bug in one part of the app can potentially bring down the whole thing.
Longer Build/Deploy Times: Every tiny change, even in a small feature, requires rebuilding and redeploying the entire application. I've been on teams where a full build took 30+ minutes – imagine that for every hotfix!

The Distributed Promise of Micro Frontends: Deconstructing the Monolith

Micro Frontends are, at their core, an architectural pattern where a single large frontend application is composed of many smaller, semi-independent applications. Think of it like microservices, but for your user interface. Each "micro frontend" is owned by a single team, deployed independently, and can even be built with different technologies.

How Does This Even Work? (A Simplified View)

There are many ways to implement Micro Frontends, from simple iframes (often frowned upon for UX/communication issues) to server-side composition, build-time integration, and client-side composition (like Webpack's Module Federation, or custom JS loading).

Let's imagine a classic e-commerce site. Instead of one giant SPA, you might have:

A Header micro frontend
A Product Listing micro frontend
A Product Details micro frontend
A Shopping Cart micro frontend
A Checkout micro frontend

Each of these could be developed by a different team, using different versions of React, or even totally different frameworks like Vue or Angular, and deployed independently. A "shell" application then orchestrates and displays these together.

Here's a simplified React/TypeScript conceptual example of what a "shell" might do to load a micro-frontend (in reality, you'd use a robust solution like Module Federation or a custom loader):

// src/components/MicroFrontendLoader.tsx
import React, { useState, useEffect } from 'react';

interface MicroFrontendLoaderProps {
  name: string;
  host: string; // URL where the micro frontend is hosted
}

const MicroFrontendLoader: React.FC<MicroFrontendLoaderProps> = ({ name, host }) => {
  const [Component, setComponent] = useState<React.ComponentType | null>(null);

  useEffect(() => {
    // In a real scenario, this would dynamically load a JS bundle
    // and extract a React component from it.
    // For simplicity, we'll simulate a dynamic import.
    const loadMicroFrontend = async () => {
      try {
        // This is highly simplified! Real-world solutions handle
        // shared dependencies, versioning, and error handling much more robustly.
        // E.g., using Webpack Module Federation or a dedicated loader.
        const module = await import(/* @vite-ignore */ `${host}/dist/${name}.js`); // Simulating dynamic script loading
        setComponent(() => module.default); // Assuming the micro frontend exports a default React component
      } catch (error) {
        console.error(`Failed to load micro frontend "${name}" from ${host}`, error);
        setComponent(() => () => <div>Error loading {name}</div>); // Render an error fallback
      }
    };

    loadMicroFrontend();
  }, [name, host]);

  if (!Component) {
    return <div>Loading {name}...</div>;
  }

  return <Component />;
};

export default MicroFrontendLoader;

// src/App.tsx (the shell application)
import React from 'react';
import MicroFrontendLoader from './components/MicroFrontendLoader';

const App: React.FC = () => {
  return (
    <div>
      <header style={{ borderBottom: '1px solid gold', padding: '10px' }}>
        <h1>My Awesome App Shell</h1>
        <nav>
          {/* Global navigation */}
        </nav>
      </header>

      <main style={{ display: 'flex' }}>
        <aside style={{ borderRight: '1px solid gold', padding: '10px', width: '200px' }}>
          {/* Side navigation */}
          <h3>Categories</h3>
          <MicroFrontendLoader name="sidebar-nav" host="http://localhost:3001" />
        </aside>

        <section style={{ flexGrow: 1, padding: '10px' }}>
          <h2>Main Content Area</h2>
          <MicroFrontendLoader name="product-listing" host="http://localhost:3002" />
        </section>
      </main>

      <footer style={{ borderTop: '1px solid gold', padding: '10px', marginTop: '20px' }}>
        <MicroFrontendLoader name="footer-info" host="http://localhost:3003" />
      </footer>
    </div>
  );
};

export default App;

In this simplified setup, MicroFrontendLoader would fetch and render a component from a specified host. Each host would be a separate, independently deployed React (or other framework) application.

The Upside (where Micro Frontends shine):

Autonomous Teams: Teams own their slices end-to-end, from development to deployment. This boosts velocity and morale.
Independent Deployments: Deploy one micro frontend without touching others. Faster release cycles, less risk.
Technology Diversity: Teams can choose the best tech for their specific problem, without forcing everyone onto a single stack. Want to use Vue for one part and React for another? Go for it.
Improved Fault Isolation: A bug in one micro frontend might only affect that specific part of the page, not the entire application.
Easier to Scale: You scale individual components and teams, not a giant monolith.

The Downside (the complexity you're signing up for):

Increased Complexity: This is the big one. More repos, more build processes, more deployment pipelines, more infrastructure to manage.
Operational Overhead: You need robust tooling for CI/CD, monitoring, and logging across multiple deployments.
Integration Challenges: How do micro frontends communicate? How do they share state? How do you ensure a consistent look and feel without duplicating code everywhere? This requires careful planning and shared libraries.
Performance (Initial Load): Loading multiple bundles can sometimes be slower initially, though smart caching and lazy loading can mitigate this.
"Distributed Monolith" Risk: If you don't define clear boundaries and communication contracts, you end up with tightly coupled micro frontends that are just as hard to manage as a monolith, but now distributed and harder to debug. I've definitely seen teams fall into this trap!

So, Which One Should You Choose? My Two Cents.

In my experience, the decision often boils down to team size, organizational structure, and the anticipated growth of your application.

Small to Medium Teams (1-3 teams) / Stable Product:
- SPA is often the best choice. The added complexity of Micro Frontends rarely outweighs the benefits. You want to maximize development velocity, and an SPA keeps things simple and coherent. Focus on good component design, clean architecture within your SPA, and effective state management.
Large Teams (4+ teams) / Rapidly Evolving, Large-Scale Product:
- Micro Frontends are worth serious consideration. If you have multiple, truly independent teams who need to deploy on their own schedule, and the product is expected to grow substantially, Micro Frontends can unlock massive efficiencies. This is especially true for large enterprise applications, portals, or platforms.

Here's the thing that most tutorials miss: The technical implementation of Micro Frontends is only half the battle. The other half is organizational. Are your teams truly autonomous? Do they have clear domain boundaries? Do you have the leadership and engineering maturity to manage the increased operational complexity? If the answer to any of those is "no," you might be building a more complicated problem, not a solution.

Practical Advice from the Trenches:

Start Simple: Don't jump straight into Micro Frontends for a brand new project unless you have a very clear, proven need. Start with an SPA, and if you hit scaling pain points (teams stepping on each other, slow deployments), then consider a strategic refactor.
Invest in Tooling: If you go Micro Frontend, heavily invest in shared tooling, component libraries, and robust CI/CD pipelines. Consistency is key.
Communication is Critical: Define clear API contracts between micro frontends and establish robust communication patterns (e.g., event buses).
Don't Over-engineer: A "micro frontend" doesn't have to be a full-blown separate app. Sometimes, a shared component library or a dynamically loaded widget is all you need to achieve some of the benefits without the full architectural leap.

Ultimately, both architectures are powerful tools. The trick is to pick the right one for your specific job, and understand the hidden costs and benefits. Don't let buzzwords drive your decisions; let your team's needs and your product's lifecycle guide 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

Micro Frontend vs Microservices: What's the Difference?

Bishoy Bishai — Mon, 23 Mar 2026 11:30:34 +0000

Micro Frontend vs. Microservices: Unpacking the Architectural Power Couple

Remember those days when applications were glorious, monolithic giants? One database, one backend, one massive frontend codebase. Ah, simpler times, perhaps, but often fraught with pain when it came to scaling, team autonomy, and sheer deployment speed. As systems grew, we started looking for ways to break things down, to inject agility. That's when "microservices" burst onto the scene, fundamentally changing how we build backends. But what about the frontend? Can we apply the same philosophy there? Enter "micro frontends."

I've found there's often a bit of confusion, or at least an assumption, that these two concepts are interchangeable or even solve the same problem. Here's the thing: while both aim for modularity, autonomy, and scalability, they operate on entirely different planes of your application stack. Let's grab a virtual coffee and really dig into the distinct superpowers of each, and how they can combine to form an architectural dream team.

The Backend Trailblazer: Microservices

Let's start with the elder sibling, microservices. In my experience, this pattern was a direct response to the "monolithic monster" problem on the server side. Imagine a massive e-commerce platform. Instead of one giant application handling everything from user authentication to product catalogs, orders, payments, and shipping, microservices break these distinct business capabilities into independent, smaller services.

Each microservice:

Owns its domain: The "Order Service" handles everything about orders and nothing else.
Has its own database: This is a big one. No shared database schema, reducing coupling.
Communicates via APIs: Usually REST or gRPC, allowing services to talk without knowing each other's internal implementation.
Is independently deployable: You can update the "Payment Service" without touching the "Product Catalog Service."
Is built by a small, autonomous team: This is where the organizational benefits truly shine.

The core idea here is to reduce the blast radius of changes and empower small, cross-functional teams to own their piece of the puzzle, from code to deployment to operations. In practice, I've seen teams accelerate dramatically once they conquer the initial setup complexity.

// A highly simplified view of a Microservice API interface
interface ProductServiceAPI {
  getProduct(productId: string): Promise<Product>;
  listProducts(category?: string): Promise<Product[]>;
  // ... more product-related operations
}

interface OrderServiceAPI {
  createOrder(items: OrderItem[], userId: string): Promise<Order>;
  getOrderStatus(orderId: string): Promise<OrderStatus>;
  // ... more order-related operations
}

// These interfaces would be implemented by separate, deployable services.

The Frontend Game-Changer: Micro Frontends

Now, imagine that e-commerce platform again. Even with a stellar microservices backend, if your entire user interface is still one giant React app, you're back to square one for the frontend team. Everyone's touching the same package.json, the same Webpack config, the same CSS files. This is exactly the problem micro frontends aim to solve.

Micro frontends take the microservices philosophy and apply it to the browser. Instead of building a single, monolithic frontend, you compose your UI from features owned by independent teams. Think of your application's dashboard:

The "User Profile" widget could be one micro frontend.
The "Order History" component another.
The "Recommended Products" section yet another.

Each of these is an independently developed, tested, and deployed application or component, brought together in a "shell" or "container" application.

How do they work in practice?

There are several ways to stitch micro frontends together, often leveraging module federation (a Webpack 5 feature) or simple iframe embedding, or even custom component loading strategies.

Let's consider a basic example using Module Federation (a powerful Webpack 5 feature commonly used with React):

// In your 'App Shell' (host) application's webpack.config.js:
// This app will consume remote micro frontends.
module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'appShell',
      remotes: {
        UserProfileApp: 'UserProfileApp@http://localhost:3001/remoteEntry.js',
        OrderHistoryApp: 'OrderHistoryApp@http://localhost:3002/remoteEntry.js',
      },
      shared: {
        react: { singleton: true, requiredVersion: '18.x.x' },
        'react-dom': { singleton: true, requiredVersion: '18.x.x' },
        // Ensure shared dependencies are consistent
      },
    }),
  ],
};

// Then, in your React App Shell component (AppShell.tsx):
import React, { lazy, Suspense } from 'react';

// Dynamically import the remote micro frontends
const UserProfile = lazy(() => import('UserProfileApp/UserProfilePage'));
const OrderHistory = lazy(() => import('OrderHistoryApp/OrderHistoryWidget'));

const AppShell: React.FC = () => {
  return (
    <div>
      <h1>My Super App</h1>
      <nav>...</nav>
      <main style={{ display: 'flex' }}>
        <aside>
          <Suspense fallback={<div>Loading User Profile...</div>}>
            <UserProfile userId="user-123" />
          </Suspense>
        </aside>
        <section>
          <Suspense fallback={<div>Loading Order History...</div>}>
            <OrderHistory customerId="cust-456" />
          </Suspense>
        </section>
      </main>
      <footer>...</footer>
    </div>
  );
};

export default AppShell;

// In a 'UserProfileApp' (remote) application's webpack.config.js:
// This app exposes its UserProfilePage as a micro frontend.
module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'UserProfileApp',
      filename: 'remoteEntry.js',
      exposes: {
        './UserProfilePage': './src/UserProfilePage.tsx',
      },
      shared: {
        react: { singleton: true, requiredVersion: '18.x.x' },
        'react-dom': { singleton: true, requiredVersion: '18.x.x' },
      },
    }),
  ],
};

// src/UserProfilePage.tsx within UserProfileApp:
import React from 'react';

interface UserProfileProps {
  userId: string;
}

const UserProfilePage: React.FC<UserProfileProps> = ({ userId }) => {
  // Fetch user data for 'userId'
  return (
    <div style={{ padding: '20px', border: '1px solid #ccc' }}>
      <h2>User Profile for {userId}</h2>
      <p>Name: Jane Doe</p>
      <p>Email: jane.doe@example.com</p>
      {/* ... more profile details */}
    </div>
  );
};

export default UserProfilePage;

This React/TypeScript example demonstrates how the App Shell dynamically loads UserProfilePage and OrderHistoryWidget from separate, independently built and deployed applications. The shared configuration is crucial for ensuring that React and ReactDOM are loaded only once, preventing common pitfalls.

The Crucial Difference: What Solves What?

Here's the distinction that often gets missed:

Microservices tackle backend complexity and team autonomy at the data and business logic layer. They break down monolithic server applications.
Micro Frontends tackle frontend complexity and team autonomy at the user interface layer. They break down monolithic client-side applications.

You absolutely can have a microservices backend with a monolithic frontend, or vice-versa (though the latter is less common in practice). The true power, and what I've often championed, comes from using them together, aligning your frontend architecture with your backend services. If your "Order Service" team owns the backend order logic, why shouldn't they also own the UI components related to orders?

What Most Tutorials Miss: The Human Factor and Shared Challenges

It's easy to get lost in the technical setup, but I've found that the biggest challenges are often non-technical:

Organizational Alignment: Both patterns require a shift in how teams are structured and communicate. If your teams aren't truly cross-functional and empowered, you'll just create distributed monoliths.
Shared Concerns:
- Microservices: Distributed transactions, data consistency, service discovery, API versioning. These are tough nuts to crack.
- Micro Frontends: Shared UI components (design systems), global state management, cross-micro frontend communication, consistent routing, and performance optimization (bundle size, lazy loading).
Governance: Who owns the overall design system? Who defines the contracts between micro frontends? Without clear guidelines, your UI can quickly become a Frankenstein monster.
Testing: Testing an integrated system with multiple deployable units, both on the backend and frontend, adds significant complexity.

Pitfalls to Avoid

Over-engineering: Don't jump to microservices or micro frontends just because they're trendy. Start with a monolith if you're small, and refactor when the pain points become clear.
Ignoring communication: "Independent teams" doesn't mean "isolated teams." Regular syncs, clear APIs (frontend and backend), and shared architectural principles are vital.
Shared state nightmares (Micro Frontends): Trying to manage complex global state across disparate micro frontends without a well-defined strategy can quickly devolve into chaos. Embrace clear communication channels (e.g., custom events, pub/sub) over direct state manipulation between them.
Inconsistent UX (Micro Frontends): Without a strong design system and clear ownership of shared components, your user experience will suffer. A button might look slightly different on every page.

Bringing It All Together

Microservices and micro frontends aren't silver bullets. They're powerful architectural patterns that, when implemented thoughtfully, can unlock incredible agility, scalability, and developer experience. They encourage autonomous, focused teams, allowing them to iterate and deploy faster.

The key takeaway for me has always been this: understand the problem you're trying to solve. If your backend is bogged down by intertwined logic and slow deployments, microservices are your answer. If your frontend is a tangled mess, slowing down UI development and breaking team autonomy, micro frontends offer a clear path forward. Combine them judiciously, and you won't just build faster – you'll build smarter.

✨ 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

Frontend interview questions you'll actually get in 2026

Bishoy Bishai — Thu, 12 Mar 2026 11:20:57 +0000

Frontend Interviews in 2026: Beyond the `useState` – It's About Systems, Not Just Components

Remember those whiteboard sessions where you'd be asked to implement a simple counter with useState or explain the dependency array of useEffect? While those are foundational, I've found that the truly insightful interviews today, and certainly by 2026, are probing for something far deeper. The landscape has matured, and with it, the expectations for frontend engineers.

The truth is, building a component is one thing; building a system that's performant, scalable, and maintainable across a large team is another entirely. I recall a recent interview where a candidate flawlessly implemented a custom hook for form validation. Impressive, sure. But when asked how they'd ensure this form scaled to hundreds of fields, integrated with a complex global state, and maintained sub-100ms response times even on slow networks, the conversation shifted dramatically. That's the real challenge, and that's what hiring managers want to see you tackle.

Why This Shift Matters: The Evolution of "Frontend"

The "frontend" isn't just about styling divs and fetching data anymore. It's a sophisticated layer of a distributed system, often interacting with multiple APIs, managing complex state, and delivering experiences that rival desktop applications. Teams are larger, user expectations for speed and responsiveness are higher than ever, and the cost of poor performance or architectural debt is significant.

In my experience, the biggest companies aren't just looking for React developers; they're looking for systems thinkers who happen to use React. They want to understand your mental model for building robust web applications that can stand the test of time and scale.

Deep Dive: What "Systems Thinking" Looks Like in React Interviews

So, what does this translate to practically? Here are the areas I've seen differentiate good candidates from truly exceptional ones:

1. Data Fetching & State Management: Beyond the Basics

It's no longer enough to know how to fetch data in useEffect or use Redux. Interviews will delve into:

Caching Strategies: How do you handle stale data? When do you re-fetch? Libraries like TanStack Query (React Query) and SWR aren't just buzzwords; understanding their core principles, cache invalidation, and optimistic updates is crucial.
Race Conditions & Loading States: How do you prevent multiple requests for the same data? How do you manage loading, error, and empty states gracefully across a complex UI?
Global vs. Local State: When do you lift state up? When do you use Context, and when is it appropriate to reach for a dedicated state management library? And more importantly, why?

Let's look at a simplified example of what I mean by a "system-aware" data fetching hook. It's not just fetching; it's about managing the lifecycle elegantly:

// src/hooks/useOptimisticData.ts
import { useState, useEffect, useCallback, useRef } from 'react';

interface FetchResult<T> {
  data: T | null;
  isLoading: boolean;
  error: Error | null;
  refetch: () => void;
  updateData: (updater: (prev: T | null) => T | null) => void; // For optimistic updates
}

export function useOptimisticData<T>(
  url: string,
  initialData: T | null = null
): FetchResult<T> {
  const [data, setData] = useState<T | null>(initialData);
  const [isLoading, setIsLoading] = useState<boolean>(true);
  const [error, setError] = useState<Error | null>(null);
  const abortControllerRef = useRef<AbortController | null>(null);

  const fetchData = useCallback(async () => {
    abortControllerRef.current?.abort(); // Abort previous pending requests
    const controller = new AbortController();
    abortControllerRef.current = controller;

    setIsLoading(true);
    setError(null);
    try {
      const response = await fetch(url, { signal: controller.signal });
      if (!response.ok) {
        throw new Error(`HTTP error! status: ${response.status}`);
      }
      const result: T = await response.json();
      setData(result);
    } catch (err) {
      if (err instanceof Error && err.name !== 'AbortError') {
        setError(err);
      }
    } finally {
      setIsLoading(false);
      if (abortControllerRef.current === controller) {
        abortControllerRef.current = null; // Clear if this was the last active request
      }
    }
  }, [url]);

  useEffect(() => {
    fetchData();
    return () => {
      abortControllerRef.current?.abort(); // Cleanup on unmount
    };
  }, [fetchData]);

  const updateData = useCallback((updater: (prev: T | null) => T | null) => {
    setData(prev => updater(prev));
  }, []);

  return { data, isLoading, error, refetch: fetchData, updateData };
}

// Example usage:
/*
  function MyComponent() {
    const { data: user, isLoading, error, updateData } = useOptimisticData<{ name: string }>('/api/user/1', { name: 'Loading...' });

    const handleUpdateName = async (newName: string) => {
      // Optimistic update
      updateData(prev => prev ? { ...prev, name: newName } : { name: newName });
      try {
        await fetch('/api/user/1', { method: 'PUT', body: JSON.stringify({ name: newName }) });
        // If server returns updated data, setData with that. Otherwise, current optimistic is fine.
      } catch (e) {
        // Handle error, maybe rollback optimistic update
      }
    };

    if (isLoading) return <p>Loading user...</p>;
    if (error) return <p>Error: {error.message}</p>;

    return (
      <div>
        <h1>Welcome, {user?.name}</h1>
        <button onClick={() => handleUpdateName('Jane Doe')}>Change Name</button>
      </div>
    );
  }
*/

This isn't just fetching; it's robust, cancellable, and supports immediate UI feedback. That's system thinking.

2. Performance & Optimization: Beyond `memo`

Everyone knows React.memo and useCallback, but interviewers want to see a deeper understanding of why and when to use them, and what lies beyond:

Bundle Splitting & Lazy Loading: How do you minimize initial load times? Code splitting with React.lazy and dynamic imports, understanding preloading strategies.
Critical Rendering Path: Server-Side Rendering (SSR), Static Site Generation (SSG), and especially React Server Components (RSC) are changing the game. Understanding their impact on initial load, interactivity, and SEO is paramount.
Resource Hints: preload, preconnect, dns-prefetch – when and why would you use these?
Visual Performance: Understanding Layout Shifts (CLS), paint times, and interaction latency.

3. Architectural Patterns & Scalability

This is where you show you can think beyond a single component:

Monorepos vs. Polyrepos: Understanding the trade-offs.
Design Systems & Component Libraries: How do you contribute to or consume a shared component library effectively?
Micro-frontends: While not every project needs them, knowing the principles and challenges is a strong signal.
Testing Strategy: Unit tests are great, but how do you approach integration and end-to-end testing with tools like Playwright or Cypress? You should be able to articulate a comprehensive testing pyramid.

Common Pitfalls to Avoid in 2026

Blindly Optimizing: Don't reach for memo on every component. Premature optimization is still the root of all evil. Explain why you believe a performance bottleneck exists before applying a solution.
Ignoring the Server: With the rise of Next.js and RSC, ignoring the server-side implications of your frontend choices is a huge red flag. Understand data fetching on the server, component hydration, and how they impact the user experience.
Focusing on Syntax over Problem Solving: The interview isn't a quiz on React API. It's a test of your ability to solve complex, real-world problems. Be ready to discuss trade-offs, alternative solutions, and the rationale behind your choices.
Not Asking Questions: A thoughtful engineer asks clarifying questions to understand the constraints and goals. This shows critical thinking, not a lack of knowledge.

Wrapping Up: Be the Architect, Not Just the Builder

By 2026, frontend interviews won't just be about "can you code." They'll be about "can you design and build a robust, performant, and maintainable web application that scales with the business?" It's about demonstrating your ability to contribute to a larger engineering effort, to think critically about system architecture, performance budgets, and user experience from a holistic perspective.

So, when you prepare, don't just review your hooks. Think about the entire lifecycle of a modern web application, from the first byte loaded to continuous deployment. Understand the "why" behind the tools and patterns, and you'll shine. Good luck!

✨ 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

You're Overusing useEffect. Here's How to Fix It.

Bishoy Bishai — Wed, 11 Mar 2026 11:20:22 +0000

You're Overusing useEffect. Here's How to Fix It.

We've all been there. You open a React component, scroll through line after line, and find yourself in a dense forest of useEffect calls. One useEffect for data fetching, another for updating the document title, a third for setting up a WebSocket connection, and maybe a fourth for animating something on mount. It's easy to fall into the trap of using useEffect as the go-to solution for anything that feels "side-effect-y." But in my experience, this often leads to code that's harder to read, debug, and maintain, ultimately making your team less productive and your application less robust.

Here's the stark truth: if you find yourself constantly battling useEffect's dependency array, or if your components feel brittle and prone to unexpected re-renders, it's a strong signal you might be overusing it. Let's unpack why this happens and, more importantly, how we can build more resilient React applications.

The Mental Model Mismatch: `useEffect` Isn't `componentDidMount` (or `Update`)

The biggest misconception I've encountered is treating useEffect as a direct replacement for lifecycle methods like componentDidMount, componentDidUpdate, or componentWillUnmount. While it can handle those scenarios, its true power, and primary purpose, is synchronization.

Think of useEffect as a way to synchronize your React component with external systems. This could be:

The DOM (e.g., manually adding event listeners, updating document.title).
The network (e.g., data fetching).
Browser APIs (e.g., localStorage, geolocation).
Third-party libraries (e.g., integrating a charting library, a video player).

If your useEffect isn't clearly synchronizing with something outside of React's render cycle, there's a good chance you have a simpler, more direct solution available.

Let's dive into some common scenarios where useEffect is often overused and explore better alternatives.

1. Derived State: Don't Recalculate What You Can `useMemo`

A frequent misuse of useEffect is to compute derived state that depends on other state or props.

The useEffect trap:

function ProductDisplay({ products, filterTerm }: Props) {
  const [filteredProducts, setFilteredProducts] = useState<Product[]>([]);

  useEffect(() => {
    console.log('Recalculating filtered products in useEffect');
    const newFiltered = products.filter(p => p.name.includes(filterTerm));
    setFilteredProducts(newFiltered);
  }, [products, filterTerm]); // Runs on every product/filter change

  return (
    <div>
      {/* Render filteredProducts */}
    </div>
  );
}

This works, but it's unnecessary overhead. setFilteredProducts triggers another render after the initial render for ProductDisplay.

The fix: useMemo

import React, { useMemo } from 'react';

function ProductDisplay({ products, filterTerm }: Props) {
  const filteredProducts = useMemo(() => {
    console.log('Recalculating filtered products with useMemo');
    return products.filter(p => p.name.includes(filterTerm));
  }, [products, filterTerm]); // Recalculates only when products or filterTerm change

  return (
    <div>
      {/* Render filteredProducts */}
    </div>
  );
}

useMemo directly computes the value during render and memoizes it, preventing unnecessary state updates and re-renders. It's cleaner, more performant, and expresses intent better.

2. Event Handlers & Local State: Attach Directly or `useState`

Sometimes, we reach for useEffect to manage simple local state interactions or attach event handlers that don't need a full synchronization loop.

The useEffect trap for local state:

function MyComponent() {
  const [isOpen, setIsOpen] = useState(false);

  // Don't do this!
  useEffect(() => {
    // This is essentially just setting state based on a prop or internal logic
    // which should happen directly or via useState's lazy initializer
  }, [someCondition]); 
  // (Often this pattern morphs into useEffects that set state based on other state)

  // ...
}

If you're just initializing state or updating it based on a direct user interaction, useState or direct event handlers are usually sufficient.

The fix: Direct handlers & useState initializers

function Counter() {
  const [count, setCount] = useState(0);

  // Direct event handler
  const increment = () => setCount(prev => prev + 1);

  return <button onClick={increment}>Count: {count}</button>;
}

function InitializedComponent({ initialValue }: { initialValue: number }) {
  // Lazily initialize state once, no useEffect needed
  const [value, setValue] = useState(() => initialValue * 2); 

  return <div>Value: {value}</div>;
}

For cases where you need to react to a prop change and update local state, consider if key prop re-mounting or a dedicated useReducer with an initializer might be more appropriate than useEffect.

3. Data Fetching (with Caveats): Custom Hooks are Your Friends

This is a big one. While useEffect is suitable for data fetching, especially simple cases, its overuse comes when we embed complex fetching logic, caching, and error handling directly into components.

The useEffect trap:

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

  useEffect(() => {
    let ignore = false; // To handle race conditions
    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 = await response.json();
        if (!ignore) {
          setUser(data);
        }
      } catch (err: any) {
        if (!ignore) {
          setError(err.message);
        }
      } finally {
        if (!ignore) {
          setIsLoading(false);
        }
      }
    };

    fetchUser();

    return () => {
      ignore = true; // Cleanup for race conditions
    };
  }, [userId]); // Re-fetches when userId changes

  if (isLoading) return <p>Loading user...</p>;
  if (error) return <p>Error: {error}</p>;
  if (!user) return <p>No user found.</p>;

  return (
    <div>
      <h2>{user.name}</h2>
      <p>Email: {user.email}</p>
    </div>
  );
}

This is a lot of boilerplate for every data fetch. It tightly couples the fetching logic to the component, making it less reusable and harder to test.

The fix: Custom Hooks

Extract this common logic into a reusable custom hook.

import { useState, useEffect } from 'react';

interface User {
  id: string;
  name: string;
  email: string;
}

interface UseFetchResult<T> {
  data: T | null;
  isLoading: boolean;
  error: string | null;
}

function useFetch<T>(url: string, dependencies: React.DependencyList = []): UseFetchResult<T> {
  const [data, setData] = useState<T | null>(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    let ignore = false;
    const fetchData = async () => {
      setIsLoading(true);
      setError(null);
      try {
        const response = await fetch(url);
        if (!response.ok) {
          throw new Error(`HTTP error! status: ${response.status}`);
        }
        const json = await response.json();
        if (!ignore) {
          setData(json);
        }
      } catch (err: any) {
        if (!ignore) {
          setError(err.message);
        }
      } finally {
        if (!ignore) {
          setIsLoading(false);
        }
      }
    };

    fetchData();

    return () => {
      ignore = true;
    };
  }, [url, ...dependencies]); // Re-runs when URL or explicit dependencies change

  return { data, isLoading, error };
}

// Now, your component becomes much cleaner:
function UserProfile({ userId }: { userId: string }) {
  const { data: user, isLoading, error } = useFetch<User>(`/api/users/${userId}`, [userId]);

  if (isLoading) return <p>Loading user...</p>;
  if (error) return <p>Error: {error}</p>;
  if (!user) return <p>No user found.</p>;

  return (
    <div>
      <h2>{user.name}</h2>
      <p>Email: {user.email}</p>
    </div>
  );
}

This pattern is a game-changer. It abstracts away the complexity, makes fetching logic reusable, and significantly cleans up your components. Libraries like React Query or SWR take this even further, handling caching, revalidation, and more.

4. Cleanup Logic: Don't Forget the Return

This isn't an "overuse" issue as much as a "misuse" or "neglect" issue, but it's crucial for useEffect to avoid memory leaks and unexpected behavior. If your useEffect sets up anything that needs to be torn down (event listeners, subscriptions, timers), always return a cleanup function.

Example:

useEffect(() => {
  const handleScroll = () => { /* ... */ };
  window.addEventListener('scroll', handleScroll);

  return () => {
    // This runs when the component unmounts OR when dependencies change and the effect re-runs
    window.removeEventListener('scroll', handleScroll);
  };
}, []); // Empty dependency array means it runs once on mount, cleans up on unmount

Neglecting cleanup is a common source of bugs that are hard to track down.

A Mindset Shift: When Is `useEffect` Appropriate?

After all this, you might be wondering if you should ever use useEffect! Absolutely. It's indispensable when you truly need to synchronize with an external system.

Ask yourself these questions:

Is this logic interacting with something outside of React's render cycle? (e.g., DOM, network, browser API, 3rd-party library)
Does this logic need to run after every render where its dependencies change?
Does this logic need a cleanup mechanism?

If you answer "yes" to these, useEffect is likely the right tool. If not, pause and consider useMemo, useCallback, useState, direct event handlers, or a custom hook.

The Payoff: Cleaner, More Predictable Code

By being more intentional with useEffect, you'll gain:

Improved Readability: Components become easier to parse, with concerns clearly separated.
Easier Debugging: Fewer places for side effects to hide, making issues simpler to pinpoint.
Better Performance: Avoiding unnecessary renders and state updates.
Enhanced Reusability: Logic encapsulated in custom hooks can be shared across your application.
Reduced Cognitive Load: You and your team can reason about component behavior more quickly.

It's a journey, not a destination. Start by looking at your existing components with a critical eye. Can that useEffect be a useMemo? Can those three effects be combined into a single, well-scoped custom hook? Embrace the simplicity, and your React code will thank you for it. The goal isn't to eliminate useEffect, but to use it wisely, like the powerful precision tool it was designed to be.

✨ 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 Removed 80% of useEffect From Our Codebase — Here's What Happened

Bishoy Bishai — Tue, 03 Mar 2026 11:19:17 +0000

The Great Un-effecting: How We Slashed 80% of useEffect from Our React Codebase

Alright, folks, let's be real. If you've been building React applications for a while, you've probably got a soft spot, or perhaps a mild trauma, for useEffect. It's that powerful hook we all learned early on, the one that lets us "do stuff" after render, sync with external systems, and generally escape the declarative world of React when we need to. But here's the thing: while useEffect is incredibly powerful, it's also incredibly easy to overuse and misuse.

I've seen it time and again, in my own projects and those of others: useEffects sprouting like weeds, each trying to manage a piece of state, fetch some data, or orchestrate some side effect. You end up with components that are hard to read, harder to debug, and often riddled with subtle performance traps or infinite re-render loops.

In one particular project, we hit a wall. Our main dashboard component, seemingly simple, had accumulated over a dozen useEffect calls. Performance was sluggish, and a particular bug where data wasn't updating reliably was driving us nuts. Every fix seemed to introduce a new edge case. It was a classic case of useEffect sprawl. That's when we decided enough was enough. We embarked on a journey to rigorously re-evaluate every single useEffect in our codebase. The result? We removed over 80% of them. And honestly, it felt like magic. Our code became leaner, faster, and surprisingly, a lot more fun to work with.

The `useEffect` Trap: A Powerful Tool, Often Misunderstood

So, why does this happen? useEffect is often taught as the "do anything after render" hook, a catch-all for any imperative logic. Need to fetch data? useEffect. Need to set up an event listener? useEffect. Need to update state based on other state? You guessed it, useEffect.

The problem isn't useEffect itself; it's our mental model around it. As Dan Abramov famously put it, "A useEffect should ideally only do one thing: synchronize state with an external system." When we try to use it for internal React state management or for logic that could be handled declaratively or imperatively at a more appropriate time, that's when the complexity snowballs.

Let's look at some common useEffect misuses and better ways to approach them.

Misuse #1: Data Fetching (The Most Common Culprit)

This is the poster child for useEffect misuse. We all started here:

import React, { useState, useEffect } from 'react';

interface User {
  id: number;
  name: string;
}

function UserProfile({ userId }: { userId: number }) {
  const [user, setUser] = useState<User | null>(null);
  const [loading, setLoading] = useState(true);
  const [error, setError] = useState<string | null>(null);

  useEffect(() => {
    const fetchUser = async () => {
      setLoading(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 as Error).message);
      } finally {
        setLoading(false);
      }
    };

    fetchUser();
  }, [userId]); // Dependency array often forgotten or misused

  if (loading) return <div>Loading user...</div>;
  if (error) return <div>Error: {error}</div>;
  if (!user) return <div>No user found.</div>;

  return (
    <div>
      <h2>{user.name}</h2>
      {/* ... more user details */}
    </div>
  );
}

This works, but it's not ideal. The component is now directly managing data fetching, caching concerns, and race conditions can easily creep in.

The Better Way: Dedicated Data Fetching Libraries (React Query, SWR)

In my experience, the single biggest game-changer for reducing useEffects related to data fetching is adopting a robust client-side data fetching library like react-query (TanStack Query) or SWR. These libraries handle caching, revalidation, error handling, loading states, and even background fetching for you, turning imperative useEffect logic into simple, declarative custom hooks.

import React from 'react';
import { useQuery } from '@tanstack/react-query'; // Assuming react-query is installed

interface User {
  id: number;
  name: string;
}

async function fetchUserById(userId: number): Promise<User> {
  const response = await fetch(`/api/users/${userId}`);
  if (!response.ok) {
    throw new Error('Failed to fetch user');
  }
  return response.json();
}

function UserProfile({ userId }: { userId: number }) {
  const { data: user, isLoading, isError, error } = useQuery({
    queryKey: ['user', userId],
    queryFn: () => fetchUserById(userId),
    enabled: !!userId, // Only fetch if userId is valid
  });

  if (isLoading) return <div>Loading user...</div>;
  if (isError) return <div>Error: {(error as Error).message}</div>;
  if (!user) return <div>No user found.</div>;

  return (
    <div>
      <h2>{user.name}</h2>
      {/* ... more user details */}
    </div>
  );
}

Zero useEffects in your component. Cleaner, more robust, and handles so many edge cases for free. If you're not using one of these, you're truly missing out.

Misuse #2: Deriving State or Reacting to Internal State Changes

Sometimes, we find ourselves using useEffect to update one piece of state when another piece of state changes.

function ProductDisplay({ quantity, price }: { quantity: number; price: number }) {
  const [total, setTotal] = useState(0);

  useEffect(() => {
    setTotal(quantity * price);
  }, [quantity, price]); // Updates 'total' whenever 'quantity' or 'price' changes

  return (
    <div>
      <p>Quantity: {quantity}</p>
      <p>Price: ${price}</p>
      <h3>Total: ${total.toFixed(2)}</h3>
    </div>
  );
}

The Better Way: Derive State Directly During Render

If state can be derived from props or other state, do it directly in the render function. This is more declarative and avoids unnecessary renders and state updates.

function ProductDisplay({ quantity, price }: { quantity: number; price: number }) {
  // total is directly derived, not stored in state
  const total = quantity * price;

  return (
    <div>
      <p>Quantity: {quantity}</p>
      <p>Price: ${price}</p>
      <h3>Total: ${total.toFixed(2)}</h3>
    </div>
  );
}

Simple, right? No useEffect, no extra state, no potential for stale closures or dependency array bugs. This is a critical mental model shift: compute what you can, store what you must.

For more complex derivations or expensive computations, useMemo is your friend, but even then, it's about memoizing a calculation, not triggering a side effect.

Misuse #3: Event Listeners and Manual DOM Manipulation (Often Wrapped in Custom Hooks)

While useEffect is designed for synchronizing with external systems like the DOM, we often create bulky useEffects in components when a custom hook could abstract that logic away.

function MyComponent() {
  const [width, setWidth] = useState(window.innerWidth);

  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth);
    window.addEventListener('resize', handleResize);

    return () => {
      window.removeEventListener('resize', handleResize);
    };
  }, []); // Only runs once on mount

  // ... rest of component
}

The Better Way: Encapsulate in Reusable Custom Hooks

While useEffect is correctly used here, placing this directly in MyComponent means MyComponent has to know about window resizing logic. Abstract it!

import { useState, useEffect } from 'react';

function useWindowWidth() {
  const [width, setWidth] = useState(window.innerWidth);

  useEffect(() => {
    const handleResize = () => setWidth(window.innerWidth);
    window.addEventListener('resize', handleResize);

    return () => {
      window.removeEventListener('resize', handleResize);
    };
  }, []); 

  return width;
}

function MyComponent() {
  const width = useWindowWidth(); // Simple, clean usage

  return (
    <div>
      <p>Current window width: {width}px</p>
      {/* ... rest of component */}
    </div>
  );
}

Now, MyComponent is only concerned with rendering. The side effect logic is isolated and reusable. This significantly cleans up component logic, making it easier to test and reason about.

When Does `useEffect` Make Sense?

After all this talk about removing useEffect, it's important to remember it's not evil. It has a crucial role. useEffect is ideal for:

Synchronizing with external systems:
- Subscribing to external stores (e.g., a Redux store, a WebSocket, a browser API).
- Interacting with the DOM directly (e.g., focusing an input, measuring element size, integrating a non-React library like a D3 chart).
- Logging or analytics calls that are pure side effects.
When there's a cleanup phase: If you set up an event listener, a timer, or an observable subscription, useEffect's cleanup function (return () => {}) is invaluable for preventing memory leaks.
Third-party library integration: When a library expects an imperative setup or teardown based on React state/props.

The key distinction: Is this effect orchestrating something within React, or is it reaching outside of React? If it's reaching outside, useEffect is likely the right tool. If it's internal, there's probably a more declarative or direct way.

Pitfalls to Avoid During the Great Un-effecting

Don't just delete and move imperative code elsewhere haphazardly: The goal is simplification, not just refactoring without thought. Ensure the new location for the logic is more appropriate and doesn't just push the complexity around.
Be wary of over-optimizing too early: If a useEffect is simple, clear, and performing well, don't necessarily rip it out just for the sake of it. Focus on the ones causing pain points (bugs, performance, readability).
Understand the alternatives deeply: Before removing a useEffect, make sure you fully grasp the alternative pattern (e.g., useQuery, useMemo, direct derivation, custom hooks, event handlers). A half-baked alternative can introduce new bugs.
Test rigorously: Refactoring useEffects can change component behavior. Ensure you have good tests in place or implement them as you refactor.

The Payoff: Clarity, Performance, and Developer Happiness

The journey of cutting down our useEffect footprint wasn't just an academic exercise. The immediate benefits were tangible:

Improved Readability: Components became much easier to scan and understand their primary purpose.
Fewer Bugs: Race conditions, stale closures, and infinite loops (often useEffect culprits) dramatically decreased.
Better Performance: Fewer unnecessary re-renders and state updates led to snappier UIs.
Easier Maintenance: When a bug did arise, tracking it down in a cleaner component was significantly faster.
Higher Developer Confidence: We spent less time scratching our heads trying to debug complex effect chains.

So, next time you reach for useEffect, pause for a moment. Ask yourself: "Is this truly synchronizing with an external system, or am I trying to manage internal React state imperatively?" More often than not, you'll find a simpler, more declarative, and ultimately more "React-y" way to achieve your goal. Start small, pick one component with a lot of effects, and see what you can simplify. You might be surprised by how much cleaner your codebase can become.

✨ 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

MCP: The "Universal Remote" for Your AI

Bishoy Bishai — Tue, 03 Mar 2026 10:44:28 +0000

Let’s be honest, my human friend. Up until recently, talking to an AI was like talking to a genius who was locked in a dark room with no windows. It could tell you the meaning of life or write a poem in the style of Van Gogh, but if you asked it to actually do something—like check your calendar, update a lead in your CRM, or send an email—it would just look at you blankly and say, "I'm sorry, I can't do that".

You had to do the "manual labor" of copying and pasting code or text between windows. You’d ask ChatGPT to write an email, then you’d have to carry that text over to Gmail yourself. In a world "Surrounded by AI," that felt a bit primitive. It was like having a Ferrari but having to get out and push it every time you wanted to change lanes.

The main philosophy of human invention has always been to free our time from meaningless work so we can do things of greater value. That brings us to MCP—the Model Context Protocol. This is the bridge that turns your AI from a conversationalist into a "Maestro" of action.

What is MCP?

Think of MCP as the universal standard for how AI models (like Claude, Gemini, or ChatGPT) talk to the tools you use every day. It moves us away from simply possessing knowledge and toward taking direct action.In my book, I talk about the Maestro Shift—how we need to leave the player's seat and step up to the podium.

MCP is basically the baton. It is an agreed-upon standard, developed by Anthropic, so that every tool—from Salesforce to Notion—doesn't have to create its own unique method to connect with an AI.

The Two Superpowers of MCP:

Real-Time Context: Instead of you manually uploading a file, the AI can "pull" context from the tool. If you ask for an analysis of new customer job titles, the model can reach directly into your CRM to find the answer.
Autonomous Action: It allows the AI to perform the task for you. It can create a draft in your Gmail account or even send the email out directly.

The Architecture Breakdown

If you’re a developer (or a curious "Maestro"), here is the breakdown of the architecture. We aren't just inserting a bolt; we are understanding the whole engine.

The MCP Client: The interface you interact with (like Claude Desktop) that wants to use a tool.
The MCP Server: A small piece of code that acts as a translator, exposing specific tools or data to the AI.
The Tools: These are the digital "assistants" in your studio. They query the database, hit the API, or read the local files.

Building Your Own MCP Server

In the past, we were paid for what our hands made, but now the present requires us to lead. Building an MCP server is how you become the CEO of your talent. You provide the Vision and the Final Touch, while the AI handles the routine execution.

The Developer's Blueprint:

Choose Your Language: Most developers use TypeScript/Node.js or Python to build their bridge.
Define Your Tools: These are the functions your AI is allowed to call, like query_internal_database or summarize_meeting_notes.
Implement the Connection: Use the MCP SDK to tell the AI what you can do. The AI asks, "What can you do?" and your server replies with a list of capabilities.

Let's try to build our own Email-Maestro

Let's Build MCP server to send emails is a brilliant way to give your AI tools "hands" to communicate. We’ll use the official MCP TypeScript SDK and Nodemailer for the email transport.

🛠 Prerequisites

You'll need node, npm, and an SMTP service (like Gmail, Resend, or Mailtrap).

1. Project Setup

First, initialize your project and install the necessary dependencies.

mkdir mcp-email-server
cd mcp-email-server
npm init -y
npm install @modelcontextprotocol/sdk nodemailer
npm install -D @types/node @types/nodemailer typescript
npx tsc --init

2. The MCP Server Code

This server defines a tool called send_email. When the AI wants to send a message, it will provide the recipient, subject, and body.

import { Server } from "@modelcontextprotocol/sdk/server/index.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import {
  CallToolRequestSchema,
  ListToolsRequestSchema,
} from "@modelcontextprotocol/sdk/types.js";
import nodemailer from "nodemailer";

// 1. Configure your Email Transport
// Replace these with your actual SMTP credentials or environment variables
const transporter = nodemailer.createTransport({
  host: "smtp.example.com",
  port: 587,
  secure: false, // true for 465, false for other ports
  auth: {
    user: "your-email@example.com",
    pass: "your-password",
  },
});

// 2. Initialize the MCP Server
const server = new Server(
  {
    name: "email-sender",
    version: "1.0.0",
  },
  {
    capabilities: {
      tools: {},
    },
  }
);

// 3. Define available tools
server.setRequestHandler(ListToolsRequestSchema, async () => {
  return {
    tools: [
      {
        name: "send_email",
        description: "Send an email to a specified recipient",
        inputSchema: {
          type: "object",
          properties: {
            to: { type: "string", description: "Recipient email address" },
            subject: { type: "string", description: "Email subject line" },
            body: { type: "string", description: "The plain text content of the email" },
          },
          required: ["to", "subject", "body"],
        },
      },
    ],
  };
});

// 4. Handle tool execution
server.setRequestHandler(CallToolRequestSchema, async (request) => {
  if (request.params.name !== "send_email") {
    throw new Error("Tool not found");
  }

  const { to, subject, body } = request.params.arguments as {
    to: string;
    subject: string;
    body: string;
  };

  try {
    const info = await transporter.sendMail({
      from: '"MCP Assistant" <your-email@example.com>',
      to,
      subject,
      text: body,
    });

    return {
      content: [
        {
          type: "text",
          text: `Email sent successfully! Message ID: ${info.messageId}`,
        },
      ],
    };
  } catch (error) {
    return {
      content: [{ type: "text", text: `Failed to send email: ${error}` }],
      isError: true,
    };
  }
});

// 5. Start the server using Stdio transport
async function main() {
  const transport = new StdioServerTransport();
  await server.connect(transport);
  console.error("Email MCP Server running on stdio");
}

main().catch(console.error);

3. How to Connect it to Claude

To use this in the Claude Desktop app, you need to add it to your configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
Windows: %APPDATA%\Claude\claude_desktop_config.json

Add this entry (pointing to your compiled JS file):

{
  "mcpServers": {
    "email-tools": {
      "command": "node",
      "args": ["/path/to/your/project/dist/index.js"]
    }
  }
}

💡 Pro Tips for Email MCPs

Environment Variables: Never hardcode your SMTP password. Use process.env.SMTP_PASS and pass it via the env field in your claude_desktop_config.json.
Confirmation: AI can be trigger-happy. You might want to add a "draft" mode or a manual verification step if you're worried about accidental sends.
HTML Support: You can easily extend the inputSchema to accept an html parameter if you want the AI to send styled emails.

If you like the idea you can go more deep:

mcp-get-started: The official boilerplate to begin your journey.
awesome-mcp: A massive list of pre-built servers for PostgreSQL, Slack, and GitHub.
modelcontextprotocol/servers: Reference implementations showing how the pros connect to Google Drive or Brave Search.

✨ 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

3 Vite Tricks I Wish I Knew When I Started

Bishoy Bishai — Mon, 02 Mar 2026 10:12:47 +0000

Unlocking Vite's Hidden Gems: 3 Tricks I Wish I Knew Sooner

When Vite first burst onto the scene, it was a breath of fresh air. The "instant server start" and "lightning-fast HMR" became instant selling points, and for good reason. For many of us, myself included, it felt like magic after years of wrestling with sluggish Webpack builds. But here's the thing: while Vite's speed is its most celebrated feature, it's really just the tip of the iceberg.

In my early days with Vite, I used it mostly as a faster drop-in replacement. I was missing out on a ton of built-in capabilities that, once discovered, genuinely felt like superpowers. These weren't "configs to tweak for 0.01ms faster build" type tricks; they were fundamental architectural patterns that simplified complex tasks and vastly improved developer experience.

Today, I want to share three such tricks – built right into Vite – that I truly wish I knew when I started. They’ll help you move beyond basic usage and leverage Vite as the powerful, opinionated tool it was designed to be.

1. The Magic of Glob Imports (`import.meta.glob`)

Have you ever found yourself manually importing dozens of components, routes, or files, particularly in larger applications? It's tedious, error-prone, and clutters your module graph. This is where Vite's import.meta.glob truly shines.

What it is: import.meta.glob is a special Vite function that allows you to import multiple modules from a given glob pattern. Instead of a single import, it returns an object where keys are file paths and values are functions that return the module.

Why it's a game-changer:

Dynamic Routing: Automatically register all your route components without explicitly importing each one.
Lazy-Loaded Components: Easily split your app by feature or component, loading them only when needed.
Plugin Systems: Discover and load plugins or extensions from a specific directory.
Testing: Find all your test files without manual configuration.

How it works (with a React/TypeScript example):

Imagine you have a components folder with Button.tsx, Card.tsx, Modal.tsx, etc. Instead of:

// src/App.tsx
import Button from './components/Button';
import Card from './components/Card';
import Modal from './components/Modal';
// ... and so on

You can do this:

// src/components/index.ts
const components = import.meta.glob('./**/*.tsx'); // Returns { './Button.tsx': () => import('./Button.tsx'), ... }

export async function getComponent(name: string) {
  const path = `./${name}.tsx`;
  if (!components[path]) {
    console.warn(`Component ${name} not found.`);
    return null;
  }
  const module = await components[path]();
  return module.default; // Assuming default export
}

// src/App.tsx
import { getComponent } from './components';
import React, { useState, useEffect } from 'react';

function App() {
  const [DynamicComponent, setDynamicComponent] = useState<React.ComponentType | null>(null);

  useEffect(() => {
    async function loadComponent() {
      const Comp = await getComponent('Button'); // Or 'Card', 'Modal'
      setDynamicComponent(() => Comp); // Use a functional update for useState
    }
    loadComponent();
  }, []);

  return (
    <div>
      {DynamicComponent && <DynamicComponent />}
    </div>
  );
}

Vite also provides import.meta.globEager which imports all modules synchronously and returns them directly (no async functions). Use eager for smaller sets of files or when you absolutely need immediate access, but be mindful of initial load performance.

Pitfall to avoid: Don't use globEager for large directories unless you really need every single module at startup. Lazy loading with the default glob is usually the more performant choice.

2. Mastering Environment Variables and Modes (`import.meta.env`)

Managing environment variables securely and consistently across development, testing, and production environments is crucial. If you've come from Node.js or Webpack, you're probably used to process.env. Vite, however, takes a slightly different, and in my opinion, safer approach with import.meta.env.

What it is: import.meta.env is a special object exposed by Vite that contains environment variables. It's client-side safe, meaning only variables prefixed with VITE_ are exposed to your client-side code, preventing accidental leakage of sensitive server-side secrets.

Why it's a game-changer:

Client-Side Safety: Only explicitly exposed variables are available in the browser.
Mode Awareness: Easily determine if your app is running in development (import.meta.env.DEV), production (import.meta.env.PROD), or a test environment (import.meta.env.SSR).
Flexible Configuration: Vite automatically loads .env files based on the current mode (e.g., .env.development, .env.production, .env.staging), allowing for granular control without complex build scripts.

How it works (with a React/TypeScript example):

First, define your environment variables in .env files:

# .env (default)
VITE_APP_TITLE=My Awesome App

# .env.development
VITE_API_URL=http://localhost:3001/api

# .env.production
VITE_API_URL=https://api.myawesomeapp.com/api

Then, access them in your React components:

// src/config.ts
const config = {
  appTitle: import.meta.env.VITE_APP_TITLE,
  apiUrl: import.meta.env.VITE_API_URL,
  isDevelopment: import.meta.env.DEV,
  isProduction: import.meta.env.PROD,
  // Example of a non-prefixed variable (will be undefined on client)
  // serverOnlySecret: process.env.SECRET_KEY // This would be 'process.env' on server, but not available on client via Vite
};

export default config;

// src/App.tsx
import config from './config';

function App() {
  return (
    <div>
      <h1>{config.appTitle}</h1>
      <p>API URL: {config.apiUrl}</p>
      {config.isDevelopment && <p>Running in development mode!</p>}
    </div>
  );
}

You can also define custom modes for staging or other environments by creating .env.staging and running vite --mode staging.

Pitfall to avoid: Always remember to prefix client-side environment variables with VITE_. Any variable not prefixed will not be exposed to your client-side code, which is a security feature, not a bug! Don't try to access process.env directly in client-side Vite code; it won't work as expected.

3. Advanced Asset Handling: `?url` & `?raw` Import Suffixes

Vite's approach to asset handling is generally "it just works." You import an image, and Vite optimizes it and gives you a public URL. But what if you need to do something more specific, like load a Web Worker from a specific path, or read the raw content of a shader file? That's where import suffixes like ?url and ?raw come in.

What they are: These are special query parameters appended to asset imports that tell Vite how to process the imported file.

?url: Imports the asset as its public URL. Instead of embedding or optimizing the file into your bundle, Vite simply provides you with the URL where the asset will be served.
?raw: Imports the asset's raw content as a string. Useful for text files, shaders, or any other content you need as plain text.

Why they're a game-changer:

Web Workers: Effortlessly create Web Workers by importing their module as a URL.
Dynamic Assets: Load images, audio, or video dynamically where a direct URL is needed, not a module import.
Shader Code/Markdown: Embed GLSL shaders or Markdown content directly into your JavaScript without complex loaders.
Custom Fonts: Get the URL for a font file without Vite trying to process it as a CSS import.

How they work (with a React/TypeScript example):

Let's say you have a worker.js file for heavy computations and a shader.glsl file for a WebGL canvas.

// src/worker.js
self.onmessage = (e) => {
  const result = e.data * 2;
  self.postMessage(result);
};

// src/shader.glsl
precision mediump float;
void main() {
    gl_FragColor = vec4(1.0, 0.0, 0.0, 1.0);
}

Now, import them in your React component:

// src/App.tsx
import React, { useEffect, useRef } from 'react';

// Import worker as a URL
import workerUrl from './worker.js?url';

// Import shader as raw string content
import fragmentShaderSource from './shader.glsl?raw';

function App() {
  const canvasRef = useRef<HTMLCanvasElement>(null);

  useEffect(() => {
    // --- Web Worker Example ---
    const myWorker = new Worker(workerUrl);
    myWorker.onmessage = (e) => {
      console.log('Worker result:', e.data); // Outputs 20
    };
    myWorker.postMessage(10);

    // --- Raw Shader Content Example ---
    if (canvasRef.current) {
      const gl = canvasRef.current.getContext('webgl');
      if (gl) {
        console.log('Fragment Shader Source:', fragmentShaderSource); // Logs the GLSL string
        // In a real app, you'd compile and link this shader.
        // For demonstration, we just log it.
        gl.clearColor(0, 0, 0, 1);
        gl.clear(gl.COLOR_BUFFER_BIT);
      }
    }

    return () => {
      myWorker.terminate();
    };
  }, []);

  return (
    <div>
      <h1>Vite Advanced Assets</h1>
      <p>Check console for worker results and shader source.</p>
      <canvas ref={canvasRef} width="300" height="300" style={{ border: '1px solid gold' }} />
    </div>
  );
}

export default App;

Pitfall to avoid: Don't overuse ?raw for large text files that you could fetch via a network request. ?raw embeds the content directly into your JavaScript bundle, which can increase its size. It's best for smaller, static text assets that are integral to your module's logic.

Pro Tip: I use ?raw to import SVG code directly when I need to manipulate the paths via CSS. It avoids an extra network request and gives you total control. I wish someone had told me this in 2018.

Wrapping Up

Vite is so much more than just a fast development server. Its thoughtful design includes a powerful set of features that can significantly streamline your development workflow, reduce boilerplate, and give you fine-grained control over how your application is built and deployed.

By leveraging glob imports for dynamic module loading, mastering import.meta.env for secure and flexible environment configuration, and understanding advanced asset handling with ?url and ?raw, you’ll be using Vite not just for its speed, but for its inherent intelligence and developer-centric design.

Go forth and build something amazing, with a smarter Vite setup! Your future self (and your teammates) will thank you.

🛠️ VAR Section — Objections

"Isn't import.meta.glob slower for large folders?"
Actually, no. Since they are lazy-loaded by default, the impact on the initial build is negligible. You're trading a tiny bit of build-time analysis for massive runtime performance gains.
"Why use ?raw when I can just fetch() the file?"
fetch is an extra HTTP request. ?raw inlines it. If it's a small config file or a shader, inlining is almost always faster and prevents "flicker" on load.
"I like process.env. Why switch?"
Because process.env in the browser is a lie. It's a polyfill. import.meta.env is the modern, native standard. Stop fighting the platform.

Bookmarks

📄 Article: Vite's Official Guide on Env Vars
*It explains the "why" behind the VITE_ prefix security model better than any tutorial.
🐦 Thread: Patak on Vite Architecture
Vite leverages native ESM, avoids bundling during dev, and uses esbuild for speed.
🎥 Video: Advanced Vite Patterns
Skip to minute 08:45: They show a real-world example of using ?url for dynamic image loading.

The Unfinished Chapter: I’m still figuring out the best way to handle monorepo symlinks with Vite without losing HMR speed. If you’ve solved this in a production environment, hit me up on LinkedIn.

Simple? Yes. Easy? Absolutely not. 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

Vite #WebDev #Frontend #SoftwareEngineering #SurroundedByAI

DEV Community: Bishoy Bishai

# Single Page Applications and SEO: How to Rank React & Next.js Apps in 2026

Decoding SPA SEO in 2026: Ranking React & Next.js Apps

Why This Still Matters: Beyond Just "Can Google See It?"

Next.js: Your SEO Supercharger for React

1. Server-Side Rendering (SSR) with getServerSideProps

2. Static Site Generation (SSG) with getStaticProps & getStaticPaths

3. Metadata Management with next/head

The Next Evolution: React Server Components and the App Router

Common Pitfalls I've Learned to Avoid

Wrapping Up

Implementing Dark Mode: CSS Variables, System Preference, and Persistence

Demystifying Dark Mode: The Elegant Path with CSS Variables, System Preference, and Persistence

The Core Idea: CSS Variables as Theme Tokens

Respecting System Preferences with prefers-color-scheme

Bringing it to React: Context and a Custom Hook

My Awesome App

The Crucial Detail: Preventing FOUC (Flash of Unstyled Content)

Real-World Insights and Lessons Learned

Wrapping Up

Next.js vs React: When Should You Use Each?

Next.js vs. React: Stop Asking "Which Is Better?" Ask This Instead.

The One Question That Settles It

What "Client Renders First" Means in Production

What "Server Renders First" Changes

The Rendering Model Spectrum — This Is Not Binary

The Two Expensive Mistakes

Expensive Mistake #1 — Reaching for Next.js when you need a React SPA

Expensive Mistake #2 — Building a public product with bare React

The App Router Reality Check

A Decision Framework You Can Use Tomorrow

The Uncomfortable Truth

Real Objections

📚 Nice to see too

Your React Component Isn't Too Big. It Has Too Many Reasons to Change.

The Uncomfortable Truth Nobody Says Out Loud

What "Doing Too Much" Actually Looks Like in Production

The Refactor: Change Isolation, Not Just Code Splitting

The Performance Win You Didn't Know You Were Getting

The State Discipline Rule You'll Use Every Day

The Uncomfortable Truth: You Will Recreate This Problem

Real Objections, Real Answers

Resuources

Here's what I'm still working through:

React 19 Is Already Here. You're Just Not Ready for It.

React 19 Is Already Here. You're Just Not Ready for It.

THE SETUP — Why React 19, Why Now

THE BREAKDOWN — The Problem React 19 Is Actually Solving

The Re-render Waterfall

THE MATCH REPORT — What React 19 Actually Changes

1, 2, 3, Tap — The React Compiler

How to Enable It Today

2. React Server Components — The Thing Most Developers Get Wrong

The Server-Client Boundary — Where Everything Goes Wrong

When NOT to Use Server Components

3. The New Hooks — Actions and Async State

useActionState — The End of Verbose Form State

useFormStatus — Knowing What's Happening Above You

useOptimistic — The UX Win You Can Ship This Week

THE TECHNICAL DEEP DIVE — React 18 vs React 19: What Changed in Production

Data Fetching

Error Handling

use() — The New Data Primitive

THE UNCOMFORTABLE TRUTH

PRO TIP — The Migration Playbook I'd Follow Today

VAR SECTION — The Objections I'd Raise in Code Review

BISHOY'S BOOKMARKS — إذا عاوز تغوص أعمق

THE UNFINISHED CHAPTER

Micro Frontend vs SPA: Which Architecture Should You Choose?

Micro Frontend vs. SPA: Which Architecture Should You Choose?

The Familiar Comfort of the SPA: When Simplicity Reigns

The Distributed Promise of Micro Frontends: Deconstructing the Monolith

How Does This Even Work? (A Simplified View)

So, Which One Should You Choose? My Two Cents.

Practical Advice from the Trenches:

Micro Frontend vs Microservices: What's the Difference?

Micro Frontend vs. Microservices: Unpacking the Architectural Power Couple

The Backend Trailblazer: Microservices

The Frontend Game-Changer: Micro Frontends

How do they work in practice?

1. Server-Side Rendering (SSR) with `getServerSideProps`

2. Static Site Generation (SSG) with `getStaticProps` & `getStaticPaths`

3. Metadata Management with `next/head`

Respecting System Preferences with `prefers-color-scheme`

`useActionState` — The End of Verbose Form State

`useFormStatus` — Knowing What's Happening Above You

`useOptimistic` — The UX Win You Can Ship This Week

`use()` — The New Data Primitive

Frontend Interviews in 2026: Beyond the `useState` – It's About Systems, Not Just Components

2. Performance & Optimization: Beyond `memo`

The Mental Model Mismatch: `useEffect` Isn't `componentDidMount` (or `Update`)

1. Derived State: Don't Recalculate What You Can `useMemo`

2. Event Handlers & Local State: Attach Directly or `useState`

A Mindset Shift: When Is `useEffect` Appropriate?

The `useEffect` Trap: A Powerful Tool, Often Misunderstood

When Does `useEffect` Make Sense?

1. The Magic of Glob Imports (`import.meta.glob`)

2. Mastering Environment Variables and Modes (`import.meta.env`)

3. Advanced Asset Handling: `?url` & `?raw` Import Suffixes