DEV Community: Shudhanshu Raj

The Memory Leak That Only Showed Up After an Hour

Shudhanshu Raj — Fri, 29 May 2026 01:42:15 +0000

A story about a tab that got slower the longer you left it open, the heap snapshots that finally explained why, and the boring patterns that stopped it.

Nobody noticed it for months. The app loaded fast, the first interaction felt snappy, the demos went fine. The bug report that finally surfaced it was almost apologetic: "The dashboard gets laggy if I leave it open all day. Refreshing fixes it."

That last sentence is the tell. Refreshing fixes it. Whenever a refresh makes a performance problem disappear, you're not looking at a slow algorithm or a heavy render. You're looking at something that accumulates — something that grows in memory the longer the page lives. For a typical content site nobody would ever catch it, because nobody keeps a tab open for eight hours. But our users are operations people who open the dashboard at 9am and close their laptop at 6pm. The tab was the session.

What follows is how I found it, what was actually causing it, and the handful of unglamorous habits that keep it from coming back.

First: confirm it's actually a leak

Before chasing anything, you have to prove the memory is growing and not being reclaimed. "The app feels slow over time" has a dozen causes, and most of them aren't leaks. So the first thing I did was open Chrome DevTools, go to the Performance panel, check "Memory," and record while I used the app the way a real user would for a few minutes — clicking around, navigating between views, coming back.

The shape of the graph is everything. A healthy app has a sawtooth: memory climbs as you work, then garbage collection drops it back down. A leak has a staircase — it climbs, GC shaves a little off, but the floor keeps rising. Every cycle ends higher than the last.

Ours was a staircase. The baseline crept up about 8MB every time I navigated away from the dashboard view and back. Do that fifty times over a workday and you've got half a gigabyte of garbage the browser can't reclaim.

That's the moment to stop guessing and take heap snapshots.

The tool that actually finds the culprit

The Memory panel in DevTools, with heap snapshots, is the only thing that reliably answers what is being retained. The technique that works is the three-snapshot comparison:

Load the app, get to a clean state, take a snapshot.
Perform the suspect action a bunch of times — navigate away and back ten times.
Return to the same clean state, force GC (the trash-can icon), take a second snapshot.

Then switch the snapshot view to "Comparison" and sort by the delta. If your app returned to the same clean state, the object counts should be roughly flat. Anything with a large positive delta — objects that were created and never freed — is your leak.

In our snapshot, the offender was unmistakable: hundreds of Detached HTMLDivElement nodes and a steadily growing count of one specific component's closures. Detached DOM nodes are the classic signature. They're elements that have been removed from the page but are still referenced by something in JavaScript, so the garbage collector can't touch them.

The "Retainers" panel tells you what that something is. Ours pointed at an event listener.

The root cause nobody removes

Here's the pattern that was sitting in three different components:

function LiveChart({ socketUrl }) {
  const [data, setData] = useState([]);

  useEffect(() => {
    const socket = new WebSocket(socketUrl);
    socket.onmessage = (event) => {
      setData((prev) => [...prev, JSON.parse(event.data)]);
    };

    window.addEventListener('resize', handleResize);
    // ...and that's it. No cleanup.
  }, [socketUrl]);

  return <div ref={chartRef}>{/* ... */}</div>;
}

Looks completely reasonable. It works. It even works correctly — the chart updates, the resize handler fires. The problem only exists across the component's lifecycle.

Every time LiveChart unmounts and a new one mounts, we open a new WebSocket and add a new resize listener — but we never close the old socket or remove the old listener. The old socket keeps its onmessage closure alive. That closure captures setData, which keeps the component's entire fiber alive, which keeps its DOM nodes alive even after React detached them from the page.

Multiply that by every navigation and you have the staircase. The DOM nodes were detached but immortal.

The useEffect cleanup function exists for exactly this, and we'd skipped it:

useEffect(() => {
  const socket = new WebSocket(socketUrl);
  socket.onmessage = (event) => {
    setData((prev) => [...prev, JSON.parse(event.data)]);
  };

  const handleResize = () => { /* ... */ };
  window.addEventListener('resize', handleResize);

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

Three lines. That return function was the entire fix for two of the three leaks.

The subtler leak: subscriptions that outlive the component

The third one was nastier because there was no obvious listener to remove. We had a small global store — a hand-rolled pub/sub — and components subscribed to it on mount:

useEffect(() => {
  store.subscribe(handleUpdate);
}, []);

There's no removeEventListener here to forget. But store.subscribe pushes handleUpdate into an internal array inside the store, and that array lives for the entire life of the page. The store is a global singleton — it never unmounts, never gets garbage collected, and it's holding a reference to a callback from a component that was destroyed twenty navigations ago. Through that callback, it holds the component too.

This is the leak people miss, because nothing looks wrong. The subscription API just didn't return an unsubscribe handle, and we never asked for one. The fix was to make subscribe return a teardown function and actually call it:

useEffect(() => {
  const unsubscribe = store.subscribe(handleUpdate);
  return unsubscribe;
}, []);

The lesson that generalized: anything you register against something that lives longer than your component, you are responsible for unregistering. Sockets, intervals, event listeners, store subscriptions, observers, animation frames. If the thing you attached to outlives you, your cleanup is the only thing standing between you and a leak.

The timers and observers checklist

Once I knew what to look for, I grepped the codebase for the usual suspects. Every one of these is a leak waiting to happen if its teardown is missing:

setInterval without a matching clearInterval. setTimeout in a component that might unmount before it fires. IntersectionObserver, ResizeObserver, and MutationObserver without .disconnect(). requestAnimationFrame loops without cancelAnimationFrame. Any .addEventListener on window, document, or a DOM node outside the component without the matching removeEventListener.

We found four more latent leaks this way that hadn't surfaced yet — a setInterval polling a status endpoint that kept running after navigation, and three observers that never disconnected. None of them were causing visible problems yet. They would have.

The habit that catches it before users do

Performance work without a guardrail is gardening — you weed it once and it grows back the next sprint. So we added two cheap habits.

First, a lint rule. eslint-plugin-react-hooks won't catch a missing cleanup on its own, but we wrote a small custom rule that flags any useEffect that creates a WebSocket, calls addEventListener, setInterval, or subscribe without returning a function. It's not bulletproof, but it turns "we forgot" into a review comment instead of a production incident.

Second — and this is the one that actually pays off — a memory regression check on the heaviest view. Before a release, someone takes the three-snapshot comparison on the dashboard: clean state, navigate away and back ten times, force GC, compare. If the detached-node count isn't roughly flat, the release waits. It takes five minutes and it has caught two regressions since we started.

What I'd tell past-me at the start of this

Don't start by reading code looking for the leak — you'll stare at a hundred reasonable-looking useEffects and find nothing, because every one of them looks fine in isolation. Start with the Performance panel to confirm the staircase, then let heap snapshots tell you what is retained and the Retainers panel tell you who is holding it. The tools point straight at the answer. Reading code is what you do after they've narrowed it to three files.

And the deeper thing: memory leaks are lifecycle problems, not memory problems. Every leak I found traced back to the same gap — something got set up on the way in and nothing tore it down on the way out. React gives you exactly one place to express that symmetry, the useEffect cleanup, and the bug is almost always that the cleanup half is simply missing. Setup and teardown are a pair. Write them together, or you'll debug them apart.

We have a standing rule now: any useEffect that opens, attaches, subscribes, or starts something gets reviewed for the matching close, remove, unsubscribe, or stop — in the same PR. It takes thirty seconds. It's saved us days.

Found this useful? A reaction helps other developers find it. I write about React, frontend architecture, and the unglamorous parts of shipping software at scale.

Advanced React Patterns I Wish I Knew 5 Years Ago

Shudhanshu Raj — Tue, 26 May 2026 04:40:00 +0000

Five years of React. Hundreds of components. Dozens of refactors. And the lesson I keep re-learning? How you structure your components matters more than what's inside them.

In this post, I'll walk through four patterns I use regularly in production today — with real examples, their trade-offs, and when not to use them.

1. Compound Components

This is the pattern that changed how I think about component APIs entirely.

The Problem

You're building a <Select> or a <Tabs> component. You start with props:

<Tabs
  items={['Overview', 'Details', 'Reviews']}
  activeIndex={0}
  onSelect={handleSelect}
  renderContent={(index) => <div>{content[index]}</div>}
/>

Two weeks later, a designer wants custom icons in the tab labels. Then someone needs a tab to be disabled. Then a badge count. Before long you have 15 props, a messy renderX prop API, and a component nobody wants to touch.

The Pattern

Compound components let the consumer control structure while the parent manages state:

// Usage — clean, readable, extensible
<Tabs defaultIndex={0}>
  <Tabs.List>
    <Tabs.Tab>Overview</Tabs.Tab>
    <Tabs.Tab disabled>Details <Badge>New</Badge></Tabs.Tab>
    <Tabs.Tab>Reviews</Tabs.Tab>
  </Tabs.List>

  <Tabs.Panels>
    <Tabs.Panel><Overview /></Tabs.Panel>
    <Tabs.Panel><Details /></Tabs.Panel>
    <Tabs.Panel><Reviews /></Tabs.Panel>
  </Tabs.Panels>
</Tabs>

Here's the implementation using Context:

const TabsContext = createContext(null);

function Tabs({ defaultIndex = 0, children }) {
  const [activeIndex, setActiveIndex] = useState(defaultIndex);

  return (
    <TabsContext.Provider value={{ activeIndex, setActiveIndex }}>
      <div className="tabs">{children}</div>
    </TabsContext.Provider>
  );
}

function TabList({ children }) {
  return <div role="tablist" className="tab-list">{children}</div>;
}

function Tab({ children, disabled = false }) {
  const { activeIndex, setActiveIndex } = useContext(TabsContext);
  const index = useTabIndex(); // tracks position via cloneElement or Context counter

  return (
    <button
      role="tab"
      aria-selected={activeIndex === index}
      disabled={disabled}
      onClick={() => !disabled && setActiveIndex(index)}
    >
      {children}
    </button>
  );
}

function TabPanels({ children }) {
  return <div className="tab-panels">{children}</div>;
}

function TabPanel({ children }) {
  const { activeIndex } = useContext(TabsContext);
  const index = useTabIndex();

  return activeIndex === index ? <div role="tabpanel">{children}</div> : null;
}

// Attach sub-components
Tabs.List = TabList;
Tabs.Tab = Tab;
Tabs.Panels = TabPanels;
Tabs.Panel = TabPanel;

Why It Works

Zero prop-drilling — Context handles shared state transparently.
Fully composable — consumers can put anything inside <Tabs.Tab>.
Open for extension, closed for modification — adding a <Tabs.Tab> variant doesn't touch the core. ### When NOT to Use It

Compound components shine for UI components with shared state (Tabs, Accordion, Dropdown, Modal). They're overkill for simple stateless components. Don't reach for this pattern reflexively.

2. The State Reducer Pattern

Kent C. Dodds popularised this one, and once you get it, you'll see the use case everywhere.

The Problem

You've built a polished useToggle hook. Then a consumer says:

"Can we prevent the toggle from turning off if a certain condition is met?"

You could add an allowToggleOff prop. Then they ask for disableOnMax. And now your hook has 6 options covering every edge case someone dreamed up — and your tests look like a horror movie.

The Pattern

Give consumers control over how state transitions happen by accepting a custom reducer:

// The hook
function useToggle({ reducer = toggleReducer } = {}) {
  const [state, dispatch] = useReducer(reducer, { on: false });

  const toggle = () => dispatch({ type: 'TOGGLE' });
  const reset = () => dispatch({ type: 'RESET' });

  return { on: state.on, toggle, reset };
}

// Default reducer — normal behaviour
function toggleReducer(state, action) {
  switch (action.type) {
    case 'TOGGLE': return { on: !state.on };
    case 'RESET':  return { on: false };
    default: throw new Error(`Unhandled action: ${action.type}`);
  }
}

Now a consumer can override specific transitions without touching the hook:

function App() {
  const [timesToggled, setTimesToggled] = useState(0);

  function customReducer(state, action) {
    if (action.type === 'TOGGLE' && timesToggled >= 3) {
      // Prevent toggling after 3 times — no hook changes needed
      return state;
    }
    return toggleReducer(state, action); // Delegate everything else
  }

  const { on, toggle } = useToggle({ reducer: customReducer });

  return (
    <div>
      <p>Toggle is {on ? 'ON' : 'OFF'}</p>
      <p>Times toggled: {timesToggled}</p>
      <button onClick={() => { toggle(); setTimesToggled(c => c + 1); }}>
        Toggle
      </button>
    </div>
  );
}

Why It Works

Inversion of control — the hook owns what can happen; the consumer controls when.
No breaking changes — adding new behaviour doesn't change the hook's public API.
Testable in isolation — you can test the default reducer separately from custom overrides. ### Real Production Use Case

I used this in a form library to let consumers block submission during async validation, throttle re-renders on fast inputs, or add optimistic updates — all without forking the core hook.

3. Headless Components (a.k.a. Renderless Components)

This is the pattern behind Radix UI, Headless UI, and React Aria. And once you use it, you'll never go back to shipping styled components in a shared library.

The Problem

Your design system ships a <Dropdown> component. Works great. Then a team needs a dark-mode version. Then mobile needs a full-screen overlay instead of a floating menu. Now you're maintaining three variants of the same logic — open/close state, keyboard navigation, accessibility roles — duplicated across all three.

The Pattern

Separate behaviour and accessibility from visual rendering:

// Headless hook — pure logic, zero opinions on markup
function useDropdown(items) {
  const [isOpen, setIsOpen] = useState(false);
  const [activeIndex, setActiveIndex] = useState(-1);
  const triggerRef = useRef(null);
  const listRef = useRef(null);

  const open  = () => setIsOpen(true);
  const close = () => { setIsOpen(false); setActiveIndex(-1); };
  const toggle = () => (isOpen ? close() : open());

  const handleKeyDown = (e) => {
    if (!isOpen) return;
    if (e.key === 'ArrowDown') setActiveIndex(i => Math.min(i + 1, items.length - 1));
    if (e.key === 'ArrowUp')   setActiveIndex(i => Math.max(i - 1, 0));
    if (e.key === 'Escape')    close();
    if (e.key === 'Enter' && activeIndex >= 0) {
      items[activeIndex].onSelect();
      close();
    }
  };

  // Returns prop getters — the key to this pattern
  return {
    isOpen,
    activeIndex,
    getTriggerProps: () => ({
      ref: triggerRef,
      onClick: toggle,
      'aria-haspopup': 'listbox',
      'aria-expanded': isOpen,
    }),
    getMenuProps: () => ({
      ref: listRef,
      role: 'listbox',
      onKeyDown: handleKeyDown,
    }),
    getItemProps: (index) => ({
      role: 'option',
      'aria-selected': index === activeIndex,
      onClick: () => { items[index].onSelect(); close(); },
    }),
  };
}

Now any team can render their own markup with full keyboard support and ARIA:

// Team A — desktop floating menu
function DesktopDropdown({ items, label }) {
  const { isOpen, getTriggerProps, getMenuProps, getItemProps } = useDropdown(items);

  return (
    <div className="dropdown">
      <button {...getTriggerProps()}>{label}</button>
      {isOpen && (
        <ul className="dropdown-menu" {...getMenuProps()}>
          {items.map((item, i) => (
            <li key={item.id} className="dropdown-item" {...getItemProps(i)}>
              {item.label}
            </li>
          ))}
        </ul>
      )}
    </div>
  );
}

// Team B — mobile bottom sheet, same hook
function MobileDropdown({ items, label }) {
  const { isOpen, getTriggerProps, getMenuProps, getItemProps } = useDropdown(items);

  return (
    <>
      <button className="mobile-trigger" {...getTriggerProps()}>{label}</button>
      {isOpen && (
        <div className="bottom-sheet">
          <ul {...getMenuProps()}>
            {items.map((item, i) => (
              <li key={item.id} className="sheet-item" {...getItemProps(i)}>
                <span>{item.icon}</span> {item.label}
              </li>
            ))}
          </ul>
        </div>
      )}
    </>
  );
}

The Prop Getter Pattern

Notice the getTriggerProps() / getItemProps() approach — this is the secret sauce. Instead of passing individual ARIA props, you return an object the consumer spreads. This means:

You can add new ARIA attributes to the getter without breaking consumers.
Consumers can merge their own handlers: {...getTriggerProps(), onFocus: myHandler}. ### When to Use It

Build headless when: you're building a shared library used across multiple teams or design languages, or when you're wrapping a complex interaction (date pickers, comboboxes, drag-and-drop).

Don't headless-ify everything. A one-off <UserCard> in your app doesn't need this.

4. Composition Over Configuration

This isn't a single pattern — it's a mindset shift that ties everything together.

The Configuration Trap

// This is a configuration component. It will never stop growing.
<DataTable
  data={rows}
  columns={columns}
  sortable
  filterable
  paginated
  pageSize={10}
  onRowClick={handler}
  rowClassName={(row) => row.urgent ? 'urgent' : ''}
  emptyState={<EmptyIllustration />}
  headerRenderer={(col) => <Tooltip title={col.hint}>{col.label}</Tooltip>}
  footerRenderer={() => <ExportButton />}
  // ...and it keeps going
/>

Every new requirement becomes a new prop. The component's internals become a maze of conditionals. Onboarding a new engineer? Good luck.

The Composition Alternative

<Table>
  <Table.Header>
    {columns.map(col => (
      <Table.Column key={col.id} sortable={col.sortable}>
        <Tooltip title={col.hint}>{col.label}</Tooltip>
      </Table.Column>
    ))}
  </Table.Header>

  <Table.Body data={rows}>
    {(row) => (
      <Table.Row key={row.id} onClick={() => handleRowClick(row)} className={row.urgent ? 'urgent' : ''}>
        {columns.map(col => (
          <Table.Cell key={col.id}>{col.render(row)}</Table.Cell>
        ))}
      </Table.Row>
    )}
  </Table.Body>

  <Table.Footer>
    <Pagination total={total} pageSize={10} onChange={setPage} />
    <ExportButton data={rows} />
  </Table.Footer>
</Table>

More verbose? Yes. But:

Adding a sticky footer doesn't require a stickyFooter prop.
Custom row grouping doesn't require a groupBy API.
Every piece is individually testable. ### The Rule of Thumb

If you catch yourself adding more than 3 render props or 5 boolean flags to a component, it's time to decompose. Composition is usually the answer.

Putting It All Together

These four patterns aren't independent — they complement each other:

Pattern	Best For	Core Trade-off
Compound Components	Shared-state UI (Tabs, Accordion)	More verbose usage, but infinitely composable
State Reducer	Custom hooks with complex state logic	Requires consumers to understand reducer shape
Headless Components	Shared libraries across design systems	More code up-front; massive long-term flexibility
Composition	Any component that's growing too many props	Verbose JSX; worth it at scale

None of these are silver bullets. The best engineers I've worked with aren't the ones who know the most patterns — they're the ones who know when patterns are the wrong tool and keep things simple.

But when your component starts growing a config API that rivals a webpack config? That's your signal. Reach for these.

Thanks for reading. If you found this useful, I write about real-world React architecture, performance, and engineering trade-offs. Drop a comment if you've used any of these patterns — or if you've been burned by them. Both stories are worth hearing.

Micro-Frontend Architecture: How to Split a Monolith Without Losing Your Mind

Shudhanshu Raj — Tue, 19 May 2026 04:40:00 +0000

I still remember the moment I knew our frontend had become a problem.

It took 4 minutes to run our test suite. PRs sat in review for days because everyone was afraid of merge conflicts. Deploying a button color change required coordinating with three other teams. We had a 280,000-line React monolith, and it was slowly eating us alive.

That was three years ago. Since then I've navigated two micro-frontend migrations, made some expensive mistakes, and developed strong opinions about what actually works in production. This is that story.

What Even Is a Micro-Frontend?

The idea is simple: apply the same thinking that gave us microservices — independent, separately deployable units — to the frontend.

Instead of one giant React (or Angular, or Vue) app that every team commits to, you break the UI into smaller apps owned by individual teams. Each team ships independently. Each slice of the UI has its own repo, its own CI/CD pipeline, its own release cadence.

BEFORE (Monolith):
┌─────────────────────────────────────────────┐
│              one-giant-app                  │
│   Header | Dashboard | Orders | Settings    │
│        (everyone touches everything)        │
└─────────────────────────────────────────────┘

AFTER (Micro-Frontends):
┌──────────┐  ┌───────────┐  ┌────────┐  ┌──────────┐
│  Shell   │  │ Dashboard │  │ Orders │  │ Settings │
│  (host)  │  │   (MFE)   │  │ (MFE)  │  │  (MFE)   │
└──────────┘  └───────────┘  └────────┘  └──────────┘
   Team A         Team B        Team C      Team D

That's the pitch. Reality, as always, is more complicated.

The Three Integration Strategies (and When to Use Each)

How you stitch micro-frontends together is the most consequential architectural decision you'll make. Get this wrong and you'll create more problems than you solve.

Strategy 1: Build-Time Integration

Each MFE is published as an npm package. The shell app imports and bundles them together at build time.

// shell/package.json
{
  "dependencies": {
    "@company/dashboard-mfe": "2.4.1",
    "@company/orders-mfe":    "1.9.0",
    "@company/settings-mfe":  "3.1.2"
  }
}

The catch: This isn't really micro-frontend architecture. It's just modular architecture with extra steps. To deploy the Orders team's new feature, the Shell team still has to bump a package version and redeploy. You've added npm overhead but kept the deployment coupling.

Use it when: Teams are small (or even solo), and you want better code organization without operational complexity. Don't call it micro-frontends.

Strategy 2: Run-Time Integration via iframes

The oldest trick in the book. Each MFE lives at its own URL and gets embedded in an iframe.

<!-- shell/index.html -->
<div id="dashboard-container">
  <iframe src="https://dashboard.internal.company.com" />
</div>

The surprising truth: iframes solve almost every hard micro-frontend problem out of the box. Perfect isolation. Independent deployments. No shared global state. Different tech stacks? No problem.

The real costs: Cross-frame communication is painful (postMessage everywhere). Responsive layouts are a nightmare. Accessibility is genuinely hard to get right — focus management, screen readers, keyboard traps. And they feel clunky to users if you're not careful.

Use it when: You need hard isolation (e.g., embedding a third-party widget), or your MFEs are truly standalone tools that don't need to interact much.

Strategy 3: Run-Time Integration via Module Federation (The Modern Approach)

Webpack 5 (and now Vite with plugins) introduced Module Federation — the ability for one JavaScript bundle to dynamically load code from another bundle at runtime, across separate deployments.

// dashboard-mfe/webpack.config.js
new ModuleFederationPlugin({
  name: 'dashboardMFE',
  filename: 'remoteEntry.js',
  exposes: {
    './Dashboard': './src/Dashboard',
  },
  shared: { react: { singleton: true }, 'react-dom': { singleton: true } }
})

// shell/webpack.config.js
new ModuleFederationPlugin({
  name: 'shell',
  remotes: {
    dashboardMFE: 'dashboardMFE@https://dashboard.cdn.company.com/remoteEntry.js',
  },
})

Now the shell can do this at runtime:

// shell/src/App.jsx
const Dashboard = React.lazy(() => import('dashboardMFE/Dashboard'));

function App() {
  return (
    <Suspense fallback={<Spinner />}>
      <Dashboard />
    </Suspense>
  );
}

The Dashboard team deploys their new remoteEntry.js to the CDN. The shell picks it up on the next page load — no shell redeploy needed. That's the magic.

The Five Problems Nobody Warns You About

Theory is easy. Here's where things get genuinely hard.

Problem 1: Dependency Hell

Each MFE has its own node_modules. Without careful coordination, you'll end up loading React 18.2 and React 18.3 in the same page. Or worse, two different major versions.

Module Federation's shared config handles this, but it needs explicit care:

shared: {
  react: {
    singleton: true,     // Only one instance allowed on the page
    requiredVersion: '^18.0.0',
    eager: false,        // Load lazily, not in initial bundle
  },
  'react-dom': { singleton: true, requiredVersion: '^18.0.0' }
}

singleton: true is non-negotiable for React. Two React instances on one page will break context, hooks, and refs in subtle, maddening ways. Add the shared config, then enforce it — a lint rule or CI check that flags any MFE shipping its own React bundle.

Problem 2: Shared State Is a Trap

The most tempting antipattern: a global Redux store or Context shared across MFEs.

// ❌ Don't do this
// shell/src/globalStore.js
export const store = createStore(rootReducer);

// orders-mfe/src/OrderList.jsx
import { store } from 'shell/globalStore'; // tight coupling disguised as convenience

You've just recreated the monolith in a trenchcoat. Now the Orders MFE can't deploy without the shell, because it's importing from it.

What to do instead: Keep each MFE's state local. Share the minimum necessary via well-defined contracts: URL parameters, custom events, or a thin event bus.

// Lightweight event bus for cross-MFE communication
// shell/src/eventBus.js
const bus = new EventTarget();

export const emit  = (event, detail) => bus.dispatchEvent(new CustomEvent(event, { detail }));
export const on    = (event, cb)     => bus.addEventListener(event, cb);
export const off   = (event, cb)     => bus.removeEventListener(event, cb);

// orders-mfe: emit an event when an order is placed
emit('order:placed', { orderId: '12345', total: 49.99 });

// notifications-mfe: listen for it
on('order:placed', ({ detail }) => showToast(`Order ${detail.orderId} confirmed!`));

Clean, decoupled, and each MFE can be deployed in isolation.

Problem 3: Design System Drift

Without discipline, each MFE will slowly develop its own button component, its own color tokens, its own spacing system. Six months in, your app looks like it was designed by five people who never spoke to each other — because it was.

The fix: A shared design system as a separate, versioned package. But version it carefully.

@company/design-system@3.x — locked via shared config in Module Federation

The design system is the one dependency that should be shared. Everything else, keep isolated.

Problem 4: Performance — You're Loading More JavaScript

A micro-frontend architecture almost always means more JavaScript on the page. Multiple remoteEntry.js files, multiple framework instances if you're not careful, multiple routers.

Track your bundle metrics religiously:

// Add to your CI pipeline — fail if initial JS exceeds budget
// webpack.config.js
performance: {
  maxEntrypointSize: 170000,  // 170KB gzipped
  maxAssetSize: 250000,
  hints: 'error',             // Fail the build, don't just warn
}

And lean on lazy loading aggressively. Users shouldn't pay the cost of loading the Settings MFE when they're on the Dashboard.

Problem 5: Testing Gets Complicated

Unit tests per MFE are easy — same as before. But integration testing across MFE boundaries is where teams struggle.

My recommendation: contract testing. Each MFE publishes a contract describing its interface (the events it emits, the props it accepts). The shell validates against those contracts in CI, without needing to spin up every MFE.

Tools like Pact handle this well, or you can roll a simple JSON schema validation in your CI pipeline.

The Architecture I'd Recommend Today

For a mid-size product team (3–6 frontend teams), here's my pragmatic setup:

┌─────────────────────────────────────────────────────────┐
│                     Shell App (Host)                    │
│  - Routing                                              │
│  - Auth / session                                       │
│  - Design system tokens                                 │
│  - Event bus                                            │
└──────┬──────────────┬──────────────┬────────────────────┘
       │              │              │
  Module Fed     Module Fed     Module Fed
       │              │              │
┌──────▼──────┐ ┌─────▼──────┐ ┌────▼──────────┐
│  Dashboard  │ │   Orders   │ │   Settings    │
│    MFE      │ │    MFE     │ │     MFE       │
│  (Team B)   │ │  (Team C)  │ │   (Team D)   │
└─────────────┘ └────────────┘ └───────────────┘

Shell responsibilities: routing, authentication, session, shared design system, event bus. Nothing else.

MFE responsibilities: everything inside their domain boundary. Own their data fetching, own their state, own their tests.

The rule I enforce: No MFE imports from another MFE. Communication only through the event bus or URL. If two MFEs need to share logic, that logic belongs in the design system or a shared utility package — not in either MFE.

Is Micro-Frontend Right for Your Team?

Micro-frontends introduce real operational overhead. Be honest about whether you need them:

Signal	Recommendation
< 3 frontend engineers	Monolith. Micro-frontends will slow you down.
3–8 engineers, one codebase	Modular monolith with clear domain folders
Multiple teams, frequent merge conflicts	Strong candidate for MFEs
Teams need independent deploy cadences	MFEs are worth the investment
Different tech stacks per team	MFEs (iframes or Module Federation)

The honest truth: most teams that migrate to micro-frontends are solving a people and process problem with a technology solution. If your teams can agree on shared standards and communicate well, a well-structured monolith might serve you better for longer than you think.

But when you genuinely need independent deployability and team autonomy at scale? Module Federation is mature enough, the tooling has caught up, and the patterns are now well-understood.

What I'd Do Differently

Looking back at those two migrations:

I'd define the event bus contract first, before writing a single component. The communication layer between MFEs is your most critical API. Treat it like one.

I'd version the design system from day one, not after three teams have forked the button component.

I'd set bundle size budgets in CI on day one and make them fail the build. "We'll optimize later" is a lie we all tell ourselves.

And honestly? I'd question whether we needed it at all — at least one of those migrations happened because it was architecturally fashionable, not because the team had actually outgrown the monolith. The best architecture is the simplest one that solves your actual problem.

Wrapping Up

Micro-frontend architecture is powerful when applied to the right problems: large teams, independent deployments, domain ownership at scale. Module Federation has made the integration story dramatically better than it was even two years ago.

But it's not free. Shared dependencies, state isolation, design consistency, and integration testing all require intentional effort that a monolith handles for you by default.

My three-sentence summary:

Use Module Federation for run-time integration. Enforce singleton shared dependencies. Never let MFEs import from each other — the event bus is your friend.

If you're in the middle of a micro-frontend migration — or trying to decide whether to start one — drop a comment. I've been in the trenches on this and I'm happy to dig into specifics.

I write about frontend architecture, performance, and the messy realities of building large-scale UIs. Follow me on DEV if that's your kind of thing.

I Thought I Knew React. Then I Watched It Re-render 47 Times on a Button Click.

Shudhanshu Raj — Tue, 12 May 2026 17:58:52 +0000

A story about chasing unnecessary renders, the tools that exposed them, and the patterns that finally made them stop.

Our app had a search bar. It worked fine. It felt fine. Until a designer on the team — curious, with DevTools open — asked why the sidebar, the header, the notification badge, and a completely unrelated recommendations panel all lit up in the React DevTools highlighter every time she typed a single character into it.

She wasn't filing a bug. She was just confused. I was too, until I sat down and traced it.

That was the beginning of three weeks I now think of as re-render hell. Not because the app was broken — it wasn't. Performance was "fine." But once you see it, you can't unsee it: a 400-component tree thrashing on every keystroke, most of it doing absolutely nothing meaningful, all of it eating time on lower-end devices that our users in Tier-2 cities actually used.

What follows is the short version of what we found, what caused it, and — more importantly — what actually fixed it.

First: how to see what's actually happening

You can't fix what you can't see. Before you change a single line of code, turn on the React DevTools profiler and enable "Highlight updates when components render." It's the flame icon in the Components panel. Every component that re-renders flashes a colored border. Watch it while you interact with your app.

What you're looking for: components lighting up that have no business lighting up. A sidebar re-rendering when you type in a search box. A header re-rendering when you toggle a modal. A card component re-rendering when a completely different card updates.

In our case, the React DevTools highlighter looked like a Christmas tree. Almost everything was re-rendering on almost every interaction.

The next tool in the chain is why-did-you-render — a small library that patches React and logs to the console exactly why a component re-rendered: which props changed, which state changed, whether it was a context update. Install it once in development, point it at the components you're suspicious of, and let it tell you the truth.

// wdyr.js — import this at the top of your index.js
import React from 'react';

if (process.env.NODE_ENV === 'development') {
  const whyDidYouRender = require('@welldone-software/why-did-you-render');
  whyDidYouRender(React, {
    trackAllPureComponents: true,
  });
}

What the console showed us was humbling. Components re-rendering with prevProps === nextProps. Components re-rendering because a context value object was recreated every render, even though the underlying data hadn't changed. Components re-rendering because a callback was being defined inline and failing referential equality on every pass.

The problem wasn't one thing. It was a category of thing: we were creating new references constantly, and React was treating them as new values.

The root cause nobody talks about plainly

React re-renders a component when its state changes, its parent re-renders, or a context it subscribes to updates. That last one is the silent killer, and it's almost always the same underlying mistake.

Here's the pattern we had everywhere:

// AuthContext.jsx
export function AuthProvider({ children }) {
  const [user, setUser] = useState(null);
  const [permissions, setPermissions] = useState([]);

  return (
    <AuthContext.Provider value={{ user, permissions, setUser }}>
      {children}
    </AuthContext.Provider>
  );
}

Looks fine. The problem: every time AuthProvider re-renders — for any reason — it creates a new value object. New object reference = React assumes the context changed = every consumer re-renders. Every. Single. One.

On our app, AuthContext was consumed in 34 components. Every top-level state change anywhere near the provider triggered 34 re-renders across the tree, most of them pointless.

The fix was two things used together: useMemo to stabilize the value object, and — more importantly — splitting the context.

The fix that helped most: split your contexts

The most impactful architectural change we made was splitting monolithic contexts into smaller, focused ones. Instead of one AuthContext that held user data, permissions, and setters, we split it:

// Separate stable data from volatile data
const UserContext = createContext(null);       // rarely changes
const PermissionsContext = createContext([]);  // changes on role updates
const AuthActionsContext = createContext(null); // never changes (stable callbacks)

export function AuthProvider({ children }) {
  const [user, setUser] = useState(null);
  const [permissions, setPermissions] = useState([]);

  const actions = useMemo(() => ({ setUser }), []); // stable forever

  return (
    <AuthActionsContext.Provider value={actions}>
      <UserContext.Provider value={user}>
        <PermissionsContext.Provider value={permissions}>
          {children}
        </PermissionsContext.Provider>
      </UserContext.Provider>
    </AuthActionsContext.Provider>
  );
}

Now a component that only needs setUser subscribes to AuthActionsContext and never re-renders when the user object updates. A component that reads user doesn't re-render when permissions change. Surgical updates instead of broadcast updates.

We applied this pattern to every context in the app. The re-render count on a typical interaction dropped by roughly 60% overnight. No logic changed. No UX changed. Just topology.

memo, useMemo, useCallback — and when they're actually worth it

After the context work, we started reaching for React.memo, useMemo, and useCallback more deliberately. The keyword there is deliberately. I've seen codebases where every component is wrapped in memo and every function is wrapped in useCallback as a cargo-cult reflex. That's not optimization — that's noise. Each of these has a cost (the comparison itself, the closure overhead), and if the component is cheap to render or re-renders rarely anyway, you're paying a cost for no benefit.

The mental model that helped us decide when to apply them:

React.memo is worth it when a component is expensive to render and its parent re-renders frequently and its props are often the same between those re-renders. A list item in a 200-item list, for example. A sidebar that re-renders whenever any top-level state changes but whose own props almost never change.

const ProductCard = React.memo(function ProductCard({ product, onAddToCart }) {
  // Expensive render — reads from a selector, renders a complex layout
  return (...);
});

useCallback is worth it specifically when you're passing a function as a prop to a memoized child. Without it, a new function reference on every parent render defeats the memo entirely.

// Without this, ProductCard's memo is useless — new function ref every render
const handleAddToCart = useCallback((productId) => {
  dispatch({ type: 'ADD_TO_CART', payload: productId });
}, [dispatch]);

useMemo is worth it for expensive computations that are called during render — filtering a large list, computing derived state, building a complex data structure. It is not worth it for simple object construction unless that object is a context value or a prop passed to a memoized child.

The question I ask before adding any of these: "What re-renders am I preventing, and is that render actually expensive?" If I can't answer both parts, I don't add the wrapper.

The inline function trap

This one is small but it's everywhere and it compounds:

// This creates a new function on every render of ParentList
return items.map(item => (
  <Item key={item.id} onClick={() => handleSelect(item.id)} />
));

If Item is memoized, this defeats the memo. Every render of ParentList produces a new arrow function, a new prop reference, and a re-render of every Item in the list.

The fix is either useCallback with a stable identity, or — often cleaner — passing the handler and the id separately and letting the child call onSelect(id):

const handleSelect = useCallback((id) => {
  setSelected(id);
}, []);

return items.map(item => (
  <Item key={item.id} id={item.id} onSelect={handleSelect} />
));

Now handleSelect is the same reference across renders. Item doesn't re-render unless its id or onSelect actually changes.

The monitoring habit that caught regressions

We learned the hard way that performance work without monitoring is just gardening — you trim things back and they grow again. After three weeks of cleanup, we added two habits:

First, we kept why-did-you-render wired up in our dev environment, permanently. Any PR that causes a suspicious re-render shows up in the console during review. It became a lightweight CI check without any tooling overhead.

Second, we added React DevTools profiling to our pre-release checklist for any feature that touched shared state or context. The rule: record a profiling session of the core interaction, look at the flame chart, flag any component that renders more than twice for the same user action. It takes five minutes. It's caught three regressions in the months since.

What I'd tell past-me at the start of this

Don't start with memo and useCallback. Start with the DevTools highlighter and why-did-you-render, because the real answer is almost always upstream — a context that's too wide, a value object that's recreated too often, a state that's placed too high in the tree. Wrapping symptoms in memo is like putting a rug over a leak. It hides the puddle. It doesn't fix the pipe.

The other thing: re-render problems are architecture problems in slow motion. They usually trace back to decisions made early — where state lives, how context is structured, what gets colocated — and they compound as the app grows. The earlier you take them seriously, the cheaper they are to fix.

We have a standing rule now: any new context gets reviewed for how many components will consume it and whether it can be split. It takes ten minutes in a PR. It's saved us weeks of profiling work.

Found this useful? A reaction helps other developers find it. I write about React, frontend architecture, and the unglamorous parts of shipping software at scale.

I Spent Six Months Chasing Core Web Vitals. Here’s What Actually Moved the Needle.

Shudhanshu Raj — Tue, 28 Apr 2026 04:30:00 +0000

A field guide to LCP, INP, and CLS that skips the theory and gets to what breaks in production.

Our dashboard said green. Our users said otherwise.

For the better part of a year, we shipped features, ran Lighthouse locally, watched scores float between 92 and 98, and patted ourselves on the back. Then one Monday morning, support pinged us: a product manager testing on her own phone swore the listing page felt "stuck" for a second every time she tapped a filter. She wasn't wrong. She just wasn't in our lab.

That was the moment I learned the most important thing about Core Web Vitals: the number in your terminal is not the number Google cares about. Google cares about what happens to real users, on real devices, on real networks — the 75th percentile of them — and it measures that over a rolling 28 days through the Chrome User Experience Report (CrUX). Your Lighthouse run is a simulation. CrUX is the scoreboard.

That distinction — lab versus field — reshaped how our team approached performance. What follows is the short version of six months of work, minus the dead ends, focused on the three metrics that matter in 2026: LCP, INP, and CLS.

The metric most teams are losing on

Let me start with the one that hurts: INP. Interaction to Next Paint replaced First Input Delay in March 2024, and unlike FID — which only measured the delay before the browser started processing your click — INP measures the full round trip. Click to visual update. Every interaction on the page, not just the first one. The reported score is essentially your worst case.

Roughly 43% of sites currently fail the 200 ms "good" threshold, and on most of the apps I've touched, it's the metric that takes the deepest rework to fix. LCP is a logistics problem (ship bytes faster). CLS is a discipline problem (reserve space). INP is an architecture problem.

Here's where it bit us hardest: filters on a product listing page. Each tap triggered a setState that ran through a context provider, re-rendered about 40 components, recomputed a sort, and then — only then — painted the new chip as "selected." On a mid-range Android over 4G, that round trip hit 480 ms. The user felt it. Chrome reported it. No amount of bundle trimming was going to fix a long task.

What actually fixed it:

1. Break the task, then yield. The single highest-impact change was introducing yield points using scheduler.yield() (with a fallback to a setTimeout(0) shim for browsers without it). We split the interaction into "visual feedback first, everything else second."

async function handleFilterTap(filter) {
  // Paint the selected state immediately
  setSelectedFilter(filter);
  await yieldToMain();

  // Then do the expensive work
  const filtered = applyFilters(products, filter);
  await yieldToMain();

  setResults(filtered);
}

function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return window.scheduler.yield();
  }
  return new Promise(resolve => setTimeout(resolve, 0));
}

The perceived responsiveness change was dramatic. The filter chip highlighted instantly. The list updated a tick later. INP at p75 dropped from 480 ms to 170 ms on the same page, with no change to the actual filtering logic.

2. Defer non-critical renders with useDeferredValue. In React, marking the filtered results as a deferred value let the input stay responsive while the heavy list re-rendered in the background. Free win, about a week to roll out safely across the product.

3. Kill the long tasks you don't know you're running. This one is humbling. Open the Performance panel in Chrome DevTools, record an interaction, and look for any task over 50 ms. In our case, a third-party analytics script was running a synchronous JSON serialization on every click. We had no idea. We moved the script to a web worker. INP dropped another 40 ms on pages where that analytics event fired.

The pattern that emerged: INP rewards event handlers that do almost nothing synchronously. Anything expensive — filtering, sorting, logging, heavy computations — gets yielded, deferred, or offloaded. If you take one thing from this post, take that.

LCP: it's almost always the hero image

Every team I've worked with has the same story with LCP. Someone optimized "the images." LCP was still 3.2 seconds. Because "the images" is not the fix — the LCP element is the fix, and the LCP element is almost always one specific image above the fold.

Before you touch anything, identify what the LCP element actually is. You can read it straight from the web-vitals library in production:

import { onLCP } from 'web-vitals';

onLCP(metric => {
  console.log('LCP element:', metric.entries.at(-1)?.element);
  console.log('LCP value:', metric.value);
});

Ninety percent of the time, it's a hero image. Once you know that, the playbook is short and boring, which is the highest compliment I can give a performance playbook:

Preload it. <link rel="preload" as="image" href="..." fetchpriority="high"> in the document head. This one line moved our LCP from 2.8 s to 2.1 s on the homepage. Don't preload everything — just the LCP resource. Preload abuse is its own problem.
Set fetchpriority="high" on the image tag itself. Browsers are conservative about image priority by default; you're telling it this one matters.
Use modern formats. AVIF first, WebP fallback, JPEG as a last resort. The file size difference between JPEG and AVIF at equivalent quality is routinely 40 to 60 percent.
Serve the right size. A responsive srcset is not optional. Shipping a 2000-pixel-wide image to a phone that displays it at 400 is the most common unforced error in frontend performance.
Do not lazy-load the LCP image. I've seen this mistake on production sites shipping in 2026. loading="lazy" on the hero image is a guaranteed LCP regression.

The harder part of LCP is when the element isn't an image — when it's a block of text that depends on a custom font, for example. In that case, font-display: swap and preloading the font file are your friends. Accept the brief flash of fallback type. Your users won't notice. Your 75th-percentile LCP will.

CLS: the metric that makes you look unprofessional

CLS is the cheapest to fix and the one that makes your site feel the most amateur when you don't. When buttons jump out from under thumbs and ads push content down after the user has started reading, people lose trust in the interface, even if they can't articulate why.

Three rules. That's all. I have not found a CLS problem in the last three years that wasn't covered by these:

Every image, video, and iframe gets explicit width and height attributes. Even if you're styling them with CSS, the HTML attributes let the browser reserve space before the asset loads. Aspect-ratio boxes work too, but the width/height attributes are simpler and work everywhere.
Reserve space for anything injected late. Ad slots, cookie banners, personalization widgets — any element that arrives after first paint needs a height reserved upfront. A min-height on the container is usually enough. If the slot stays empty, leave it empty. The shift is worse than the blank space.
Use font-display: swap with care. Swap prevents invisible text, but it can cause a layout shift if your fallback font has significantly different metrics. The size-adjust descriptor on @font-face lets you match fallback metrics to your web font and eliminates that shift entirely. This is underused. Most teams haven't heard of it.

That's it. CLS under 0.05 is achievable on nearly any site if you follow those three rules. Ours runs at 0.02.

The monitoring setup that actually helped

You cannot fix what you cannot see, and DevTools on your machine is not "seeing." We installed the web-vitals npm package, shipped real-user metrics to our analytics pipeline, and — this was the unlock — sliced the data by route, device class, and country. A single aggregate INP number hides everything. The same site can have great INP for desktop users in Germany and awful INP for mobile users in Brazil, and the aggregate will look mid. Slicing is how you find the real fire.

We also set alerts at 80% of Google's thresholds — INP at 160 ms, LCP at 2.0 s, CLS at 0.08 — so we'd see regressions before they started eating our CrUX window. A deploy that bumps INP from 150 to 190 still reports "good," but three of those deploys in a month and you're in trouble.

What I'd tell past-me on day one

Three things.

First, stop optimizing for Lighthouse. Use it as a diagnostic tool, not a scoreboard. The scoreboard lives at CrUX, and the gap between the two can be an order of magnitude. We spent weeks chasing a 98 when we needed to spend a day fixing a filter handler.

Second, fix the metric that's actually failing, not the one you have opinions about. I like LCP. I find it tractable and satisfying. For three weeks I optimized LCP while INP silently tanked. Look at your CrUX dashboard, find the worst of the three, and start there. Then the next worst. No hero shots.

Third, performance is a product feature, not a cleanup task. Every team I've seen succeed at Core Web Vitals treated them like any other product metric: someone owned them, they were reviewed weekly, regressions were treated as bugs, and they were part of the definition of done for new features. Every team I've seen fail at Core Web Vitals treated them as something to "get to after the next launch."

You know which team gets to the next launch faster.

If this was useful, a clap helps other engineers find it. I write about frontend architecture, performance, and the unglamorous parts of shipping software.