HomeBytesheetsRoadmapsUI TemplatesUI ToolsStack Discussion
5 Topics
Chapter•120 Minutes

Expert Patterns, Troubleshooting and Real-World Scenarios

Develop expert-level reasoning for architecture decisions, debugging stale data, authentication failures, performance problems, hydration issues, and production incidents.

Hydration Mismatch Problems

Hydration mismatches occur when the HTML produced on the server does not match what React expects when the browser hydrates the application.

Common causes include rendering Date.now(), random values, browser-only APIs, locale-dependent formatting, or different data between server and client.

A component that depends on browser-only information should usually read that information after hydration or remain entirely client-driven where appropriate.

Avoid Browser-Dependent Initial Render
'use client';

import { useEffect, useState } from 'react';

export default function ClientWidth() {
  const [width, setWidth] = useState<number | null>(null);

  useEffect(() => {
    setWidth(window.innerWidth);
  }, []);

  return <p>{width === null ? 'Loading...' : `${width}px`}</p>;
}
💡 The browser-specific value is read after hydration instead of producing different initial server and client HTML.
Key Takeaways
  • Server and client initial output should be consistent.
  • Browser APIs do not exist during server rendering.
  • Avoid non-deterministic values in server-rendered markup.

Debugging Stale Data

When users report stale data, determine which cache layer is responsible before changing code. Check browser caching, CDN behavior, framework data caching, route output caching, database replicas, and application-level caches.

A useful debugging technique is to trace one request from browser to database and identify where the old value is introduced.

Avoid solving every stale-data problem by disabling caching globally. That may fix freshness while destroying performance.

Key Takeaways
  • Find the stale layer before changing caching configuration.
  • Cache invalidation should follow data dependencies.
  • Freshness and performance must be balanced.

Choosing Server vs Client Execution

Expert Next.js development is largely about placing computation in the correct environment.

Use the server for database access, secrets, heavy data preparation, authorization, and initial content. Use the browser for interactions, local state, animation, immediate UI responses, and browser APIs.

There is no universal rule that all data must be fetched on the server or that all interactive applications should use client-side fetching. The correct choice depends on latency, freshness, interaction requirements, SEO, security, and caching.

Key Takeaways
  • Server versus client is an architectural tradeoff.
  • Security-sensitive operations belong on the server.
  • Interactive behavior belongs where it can provide the best user experience.

Production Incident Reasoning

When production fails, start with symptoms rather than assumptions. Identify when the problem began, whether all users are affected, which routes or regions are affected, and whether a deployment or infrastructure change occurred.

Then inspect error rates, latency, logs, dependency health, database health, and recent changes.

A strong engineer avoids making several unrelated changes simultaneously because that makes the root cause harder to identify.

Key Takeaways
  • Start incident debugging with observable symptoms.
  • Correlate failures with recent deployments and infrastructure changes.
  • Change one major variable at a time when possible.