DEV Community: Anas Sheikh

Your useEffect Data Fetch Might Show Stale Data If a User Navigates Quickly

Anas Sheikh — Thu, 24 Sep 2026 07:42:12 +0000

This is a genuinely common race condition, and it's specifically the kind that only shows up under real usage conditions, someone clicking between items quickly, a slow network, exactly the situations casual development testing on a fast local connection rarely reproduces.

The Setup That Looks Completely Standard

'use client';
import { useState, useEffect } from 'react';

export function UserDetail({ userId }: { userId: string }) {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then((res) => res.json())
      .then((data) => setUser(data));
  }, [userId]);

  return <div>{user ? user.name : 'Loading...'}</div>;
}

This is close to the most common way to fetch data based on a changing prop in a Client Component, and it works completely correctly the vast majority of the time. It also has a real race condition that only shows up under a specific, genuinely common sequence of events.

The Exact Sequence That Triggers the Bug

A user clicks on user A in a list, userId becomes A's ID, the effect fires, a request for A's data starts. Before that request resolves, network latency, a slow connection, the user clicks user B instead, userId becomes B's ID, the effect fires again, a second, separate request for B's data starts. Now two requests are in flight simultaneously.

If B's request happens to resolve faster than A's, perfectly plausible depending on server load, caching, or just network variance, B's data renders correctly first. Then A's slower, now-stale request finally resolves, and its .then() callback runs setUser(data) with A's data, overwriting B's correct, current data with A's outdated, no-longer-relevant response. The component now displays user A's name and information while userId itself is actually set to B, a genuine, visible mismatch between what's shown and what's actually selected.

Why This Feels Random Rather Than Reliably Broken

This only manifests when the specific timing lines up, a slower first request resolving after a faster second one. On a fast, consistent local connection during development, requests often resolve close enough to their sending order that this exact interleaving rarely happens, which is exactly why it's easy to ship without ever seeing it locally, and exactly why it tends to surface first as a confusing, hard-to-reproduce bug report from a real user on a real, more variable connection.

The Actual Fix: Ignore Stale Responses Explicitly

'use client';
import { useState, useEffect } from 'react';

export function UserDetail({ userId }: { userId: string }) {
  const [user, setUser] = useState(null);

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

    fetch(`/api/users/${userId}`)
      .then((res) => res.json())
      .then((data) => {
        if (!ignore) {
          setUser(data);
        }
      });

    return () => {
      ignore = true; // marks this specific effect's request as stale on cleanup
    };
  }, [userId]);

  return <div>{user ? user.name : 'Loading...'}</div>;
}

The ignore flag, scoped locally to each individual effect invocation, gets set to true in the cleanup function, which React runs automatically the moment userId changes again, before the next effect invocation starts. When A's slow request finally resolves, its specific closure's ignore flag is already true, since the effect was cleaned up the moment the user clicked B, and the stale setUser(data) call for A's outdated data simply never happens. Only B's request, whose ignore flag remains false because its effect was never cleaned up, actually updates state.

An Alternative Using AbortController

For fetch specifically, AbortController provides a more complete version of the same fix, actually canceling the in-flight request rather than just ignoring its eventual result:

useEffect(() => {
  const controller = new AbortController();

  fetch(`/api/users/${userId}`, { signal: controller.signal })
    .then((res) => res.json())
    .then((data) => setUser(data))
    .catch((err) => {
      if (err.name !== 'AbortError') {
        console.error(err); // genuinely handle real errors, ignore expected aborts
      }
    });

  return () => {
    controller.abort();
  };
}, [userId]);

This has a real advantage over the simple ignore flag, the actual network request gets canceled, not just its result discarded, which saves real bandwidth and server load for a request whose result was never going to be used anyway, particularly valuable for anything more expensive than a small JSON response.

Why This Matters More for Search and Filtering Specifically

This exact pattern shows up constantly in search-as-you-type and rapid filtering interactions, exactly the kind of interface covered in an earlier post on search and filtering patterns. A user typing quickly triggers a new request on every keystroke, and without this protection, a slower response to an earlier, now-outdated keystroke can overwrite the correct results for what the user is actually searching for right now, displaying results for a query they've already moved past.

The Actual Rule

Any effect that fetches data based on a value that can change again before the fetch resolves needs a way to distinguish a stale, no-longer-relevant response from a current one. A simple ignore flag set in the cleanup function handles this cheaply for most cases. AbortController handles it more completely, actually canceling the wasted request rather than just discarding its result, and is worth the small amount of extra code for anything with real cost behind each request, a genuinely expensive query, meaningful bandwidth, a rate-limited endpoint.

I handle this exact pattern, mostly with AbortController for anything backed by a real database query, across the dashboards and templates I build at pixelanas.com, since it's exactly the kind of subtle bug that looks fine in every casual test and only shows up once real users start clicking around at real speed.

If you've got a useEffect fetching data based on a changing prop with no stale-response handling, go test it specifically by clicking or navigating quickly between a few items in a row. If you see a flash of the wrong data settling in, that's this exact race condition. Drop what you find in the comments.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Forgetting to Disable Draft Mode in Next.js Can Leave Unpublished Content Visible Longer Than You Think

Anas Sheikh — Wed, 23 Sep 2026 11:34:45 +0000

I covered enabling draft mode as part of the Sanity CMS setup in an earlier post, letting an editor preview unpublished content before it goes live. There's a real, practical gap worth covering on its own, specifically what draft mode actually is and isn't scoped to, since the natural assumption about that scope is wrong in a way that causes genuine, recurring confusion.

What Draft Mode Actually Is

// app/api/draft/route.ts
import { draftMode } from 'next/headers';

export async function GET(request: Request) {
  const draft = await draftMode();
  draft.enable();
  redirect('/blog/some-post');
}

Calling enable() sets a cookie in the current browser session, and Next.js checks for that specific cookie on subsequent requests to decide whether to fetch and render draft content instead of published content. This is genuinely useful, exactly the mechanism that lets an editor click "preview" and see an unpublished change before it goes live.

The Assumption That Causes Real Confusion

The natural, intuitive assumption is that enabling draft mode is a site-wide toggle, flip it on, the whole site shows draft content to everyone, flip it off, everyone's back to published content. That's not what's actually happening. Draft mode is scoped entirely to the cookie in one specific browser, one specific person's session. It has no effect whatsoever on what any other visitor sees, and it's not a global site state at all.

Where This Assumption Actually Causes Problems

An editor previews a draft, sees it looks correct, and reports the change is live, when it isn't. Since draft mode only affects their own browser, they're seeing the preview correctly, and it's genuinely easy to forget, in the moment, that what they're seeing is specifically because of their own enabled draft mode, not because the change has actually been published for everyone else.

An editor forgets to disable draft mode after previewing, and later assumes the live site is broken when they see unexpected content. If draft mode stays enabled in their browser from a previous preview session, every subsequent visit to the site, including regular, non-preview browsing, continues showing draft content in that specific browser, which can look exactly like the site rendering the wrong content, when it's actually correctly rendering draft content because that browser's cookie still has it enabled.

A shared or public computer retains draft mode enabled from a previous session. If draft mode was enabled on a shared device and never explicitly disabled, whoever uses that browser next, potentially someone without any editing permissions or context at all, sees draft, unpublished content without any indication of why, or that it's not what a normal visitor would see.

Why This Doesn't Feel Like a Bug When It Happens

None of this is actually broken, draft mode is behaving exactly as designed, scoped to a cookie in one browser. The confusion comes entirely from a mismatch between that actual, correct behavior and the intuitive mental model of it as some kind of site-wide switch. Nothing in the experience of using it particularly corrects that mental model, since enabling it does show the expected preview, which reinforces the sense that "draft mode is on" as a general, site-wide state, rather than "draft mode is on, in this specific browser, right now."

The Actual Fix: Always Pair Enable With a Clear, Visible Exit Path

// app/api/disable-draft/route.ts
import { draftMode } from 'next/headers';
import { redirect } from 'next/navigation';

export async function GET() {
  const draft = await draftMode();
  draft.disable();
  redirect('/');
}

// A persistent, visible banner whenever draft mode is active in the current browser
// app/layout.tsx
import { draftMode } from 'next/headers';

export default async function RootLayout({ children }) {
  const { isEnabled } = await draftMode();

  return (
    <html>
      <body>
        {isEnabled && (
          <div style={{ background: '#facc15', padding: '8px', textAlign: 'center' }}>
            Draft mode is on in this browser.{' '}
            <a href="/api/disable-draft">Exit preview</a>
          </div>
        )}
        {children}
      </body>
    </html>
  );
}

A persistent, visible banner, shown for as long as draft mode remains enabled in that specific browser, with a clear, one-click way to exit it, closes most of the actual confusion here. It makes the scoped, per-browser nature of draft mode visible and obvious in the moment, rather than an invisible state someone has to remember exists and remember to manually undo.

Where This Connects Back to the Original Setup

This banner pattern is worth adding as a standard part of any draft mode implementation, not an optional extra. Without it, draft mode functions correctly but silently, and silent, correctly-functioning features that contradict someone's natural mental model of how they work are exactly the kind of thing that causes recurring, hard-to-diagnose confusion, not because anything's actually broken, but because nothing visible corrects the wrong assumption in the moment it matters.

I build this banner pattern into the CMS setups I put together for client projects and the templates at pixelanas.com, specifically because the confusion this prevents is common enough to be worth the small amount of extra code every time.

The Actual Rule

Draft mode is a per-browser, cookie-scoped state, not a global site toggle, and that gap between actual behavior and intuitive assumption is exactly what causes real confusion. Pairing every draft mode implementation with a persistent, visible indicator and an obvious way to exit closes that gap directly, rather than leaving editors to remember and manually track an invisible state themselves.

If you've implemented draft mode without a visible indicator showing when it's active, worth adding one, this is a small addition that prevents a genuinely common, confusing situation. Drop your own experience with this in the comments, curious whether this confusion is as common elsewhere as it's been on projects I've worked on.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Binding Extra Arguments to a Server Action? The Order Matters More Than You'd Think

Anas Sheikh — Tue, 22 Sep 2026 08:15:47 +0000

This is a small, easy detail to get backwards, and getting it backwards doesn't throw a clear error, it just means one of your two values silently isn't what you expected it to be.

The Common Pattern This Applies To

A Server Action used directly as a form's action prop automatically receives FormData as its argument. Sometimes you also need to pass something extra, an ID identifying which specific record this particular form instance belongs to, that isn't itself a field in the form.

// components/DeletePostButton.tsx
import { deletePost } from '@/actions/posts';

export function DeletePostButton({ postId }: { postId: string }) {
  return (
    <form action={deletePost.bind(null, postId)}>
      <button type="submit">Delete</button>
    </form>
  );
}

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

export async function deletePost(postId: string, formData: FormData) {
  await Post.findByIdAndDelete(postId);
  revalidatePath('/dashboard/posts');
}

This is the correct, standard pattern, and it hinges entirely on getting the parameter order right in both places, matching each other exactly.

Where This Actually Goes Wrong

.bind(null, postId) pre-fills the function's arguments starting from the left, the first parameter position, not appended after whatever Next.js would normally pass in. postId becomes the function's first argument, and formData, which Next.js still automatically supplies, becomes the second, shifted over by exactly one position.

// ❌ Function signature doesn't match the actual argument order .bind() produces
export async function deletePost(formData: FormData, postId: string) {
  // formData here is actually receiving postId's value
  // postId here is actually receiving formData
  console.log(postId); // logs a FormData object, not the string you expected
}

Swap the parameter order in the function signature so it doesn't match how .bind() actually supplies arguments, and both values silently land in the wrong place. No error gets thrown, since both parameters exist and TypeScript, unless you're being genuinely careful with the types here, often won't catch this either, since FormData and a bound string are both just values being passed to a function expecting some combination of two arguments.

Why This Specific Mistake Is Easy to Make

The natural, intuitive mental model is "the form gives me formData, and I'm adding an extra value on top of that," which suggests formData first, extra value second, matching the order you'd think about it in conversation. .bind()'s actual behavior, prepending arguments from the left, runs counter to that intuition, and the correct order, bound value first, formData second, only becomes obvious once you specifically know how .bind() works, not from how the situation naturally gets described out loud.

How This Actually Manifests as a Bug

Depending on what your function does with each parameter, this can fail in different ways. If postId is used directly as a database ID and it's actually receiving a FormData object instead, a database query with a malformed ID typically does throw a real, if somewhat confusing, error, which at least surfaces the problem, even if not obviously. If the mismatched values happen to both be used in ways that don't immediately throw, string interpolation, a loose comparison, the bug can produce quietly wrong behavior with no error at all, which is the more dangerous version, since nothing points you toward the actual cause.

The Fix: Match the Order Deliberately, and Consider Typing It Explicitly

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

export async function deletePost(postId: string, formData: FormData) {
  await Post.findByIdAndDelete(postId);
  revalidatePath('/dashboard/posts');
}

Keeping the function signature's argument order matching exactly how .bind() supplies them, bound values first, in the order they were bound, formData last, is the actual fix. For extra safety, especially on a function you're not confident everyone touching the codebase will get right by memory, a comment directly above the signature noting the expected call pattern removes any ambiguity for the next person editing it.

// Called as: deletePost.bind(null, postId) — postId first, formData supplied automatically after
export async function deletePost(postId: string, formData: FormData) {
  // ...
}

Binding Multiple Extra Arguments

The same left-to-right rule extends cleanly to more than one bound value, in the exact order they're passed to .bind():

<form action={updatePost.bind(null, postId, currentUserId)}>

export async function updatePost(postId: string, userId: string, formData: FormData) {
  // postId first, userId second, formData last, matching the bind() call exactly
}

The Actual Rule

.bind() prepends arguments from the left, in the order you pass them, and whatever Next.js automatically supplies, formData for a form action, always ends up last, after every explicitly bound value. The function signature needs to match that exact order, not the order that feels most natural to describe the situation in conversation. When in doubt, a one-line comment above the function noting the expected .bind() call pattern is cheap insurance against exactly this kind of easy-to-miss, hard-to-notice mistake.

I run into this pattern constantly building the SaaS dashboards and templates I sell at pixelanas.com, and it's exactly the kind of small detail worth getting right once and documenting, rather than re-deriving from memory every time a new form needs an extra bound argument.

If you've got a Server Action bound with extra arguments, worth double-checking the parameter order actually matches, especially on anything where a mismatch wouldn't throw an obvious error. Drop what you find in the comments.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Why Your Next.js Modal Route Works Perfectly Until Someone Refreshes the Page

Anas Sheikh — Mon, 21 Sep 2026 11:18:57 +0000

This one isn't really a bug, it's a genuinely common point of confusion about a feature working exactly as designed, and understanding why it behaves this way changes how you'd actually build around it, rather than fighting it.

The Pattern: A Photo Grid That Opens Items as a Modal

Intercepting routes are what makes an Instagram-style interaction possible in the App Router, click a photo in a grid, it opens as a modal overlay on top of the current page, without a full navigation, while the URL still updates to something shareable and bookmarkable.

app/
├── @modal/
│   ├── default.tsx
│   └── (.)photo/
│       └── [id]/
│           └── page.tsx    // renders as a modal when intercepted
├── photo/
│   └── [id]/
│       └── page.tsx        // the actual full page
├── layout.tsx
└── page.tsx                 // the grid

Click a photo from the grid, and the (.)photo/[id] route intercepts the navigation, rendering the modal version in the @modal slot on top of the grid, without a full page transition. The URL correctly updates to /photo/123. It feels seamless, and it's a genuinely well-built pattern for exactly this kind of interaction.

Where the Confusion Starts

Someone building this, testing by clicking through the grid, sees exactly the intended modal behavior. Then they refresh the page while the modal is open, or share that /photo/123 URL with someone else, or that someone else pastes it directly into a new browser tab, and instead of the modal, they get the full, standalone photo/[id]/page.tsx page, no grid behind it, no modal chrome, just the plain page rendering on its own.

The natural first reaction is that something's broken, the modal "isn't working" on refresh. It's actually working exactly as designed, just not in the way that first reaction assumes.

Why This Is Correct, Not Broken

Interception is specifically a client-side navigation behavior. It only intercepts a navigation that happens through Next.js's client-side router, clicking a <Link>, calling router.push(), moving from one already-loaded page to another within the same app session. A hard refresh, a direct URL visit, or someone opening that link in a completely fresh browser tab isn't a client-side navigation at all, it's a fresh, full server request for that specific URL, with no prior page state to intercept from, no grid already rendered behind it to interrupt. Next.js correctly falls back to rendering the actual underlying route, the full page, because that's genuinely the only thing that makes sense in a context where there's no previous client-side navigation to interrupt in the first place.

This is why the folder structure includes both the intercepted route ((.)photo/[id], the modal version) and the actual route (photo/[id], the full page) as separate, real routes. The full page isn't a fallback or an error state, it's the intended, correct experience for anyone arriving at that URL directly, someone who shared or bookmarked the link, a search engine crawling it, anyone without an existing client-side session to interrupt.

The Actual Design Implication

This isn't something to work around, it's something to design for deliberately. The full, non-modal version of the route needs to be a genuinely complete, standalone page on its own merits, not a stripped-down fallback that only half-works, since a real share of your actual traffic to that URL, direct visits, refreshes, shared links, search engines, will land there specifically, not on the modal version.

// app/photo/[id]/page.tsx
// This needs to be a genuinely complete page, not an afterthought,
// since direct visits, refreshes, and shared links all land here specifically
export default async function PhotoPage({ params }) {
  const { id } = await params;
  const photo = await getPhoto(id);

  return (
    <div>
      <BackToGridLink /> {/* since there's no grid rendered behind this version */}
      <PhotoDisplay photo={photo} />
      <PhotoMetadata photo={photo} />
    </div>
  );
}

Including something like a clear way back to the grid, since this version genuinely doesn't have the grid rendered behind it the way the modal does, treats this as the real, complete experience it needs to be for a meaningful share of actual visitors, rather than assuming everyone always arrives via the modal path.

Why This Actually Matters for SEO Too

This split has a genuine upside worth being deliberate about. Since the full page is a real, standalone route, it's exactly what search engines actually crawl and index, a real, complete, server-rendered page for that specific photo, with its own metadata, its own content, rather than something only reachable through a client-side modal interaction a crawler would never trigger. Building the full page version to be genuinely complete isn't just handling an edge case gracefully, it's the version doing real SEO work for that specific piece of content.

The Actual Rule

Intercepting routes are a client-side navigation enhancement layered on top of real, independently functional routes, not a replacement for them. The full, non-intercepted version of the route needs to be built as a genuinely complete experience on its own, since refreshes, direct visits, shared links, and search engine crawlers all land there specifically, not on the modal version, and treating it as an afterthought means a real share of your actual traffic gets an incomplete experience.

If you're building or have built an intercepting route pattern, worth checking whether the full, non-modal version genuinely stands on its own, or was built assuming everyone always arrives through the modal. Drop your experience with this pattern in the comments, curious how many people hit this exact confusion the first time before understanding why it's actually correct.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

That bcrypt.hash(password, 10) You Copy-Pasted Might Not Be as Secure as You Think

Anas Sheikh — Sun, 20 Sep 2026 09:48:24 +0000

Almost every auth tutorial, including some of my own examples in earlier posts, uses bcrypt.hash(password, 10) without much explanation of what that number actually controls or why it's 10 specifically rather than some other value. It's worth understanding, because the right number isn't fixed, it's a moving target that most codebases never revisit after the initial copy-paste.

What the Salt Rounds Number Actually Controls

bcrypt's cost factor, the second argument, controls how computationally expensive hashing a single password is, specifically by determining how many times an internal key-setup routine repeats. It's not a linear scale, each increment roughly doubles the computation required. A cost factor of 10 means roughly 1,024 iterations of that internal routine. 11 means roughly 2,048. 12 means roughly 4,096.

This deliberate slowness is the entire point. A fast hash function is great for most use cases and terrible for passwords specifically, since a fast hash lets an attacker who's obtained a database of hashed passwords try billions of guesses per second against them. A deliberately slow hash function directly limits how many guesses an attacker can attempt in any given amount of time, even with significant computing power.

Why 10 Specifically, and Why That's Worth Questioning

The number 10 shows up constantly in tutorials and documentation because it was, at the time much of that content was written, a reasonable balance, slow enough to meaningfully limit brute-force attempts, fast enough not to noticeably slow down a real login flow for a legitimate user. That balance point depends entirely on how fast the hardware attempting to brute-force it actually is, and hardware, particularly specialized hardware built for exactly this kind of computation, gets faster every year. A cost factor considered a reasonable balance several years ago represents meaningfully less real protection against modern hardware than it did when that number first became the common default.

Why This Doesn't Show Up as an Obvious Problem

There's no error, no warning, no visible symptom of a salt rounds value that's become outdated relative to current hardware capability. Login continues working exactly as expected for legitimate users. The gap is entirely about resistance to an offline brute-force attempt against a stolen password database, something that only becomes relevant if that database is ever actually compromised, which means the weakness sits completely invisible until the exact moment it matters most.

The Actual Guidance, and Why It's a Moving Target Rather Than a Fixed Number

Security guidance on this specific number gets revised periodically as hardware capability changes, and current recommendations from security-focused organizations trend higher than the value that shows up in most existing tutorials and codebases. Rather than citing a specific number here that will itself become outdated, the actual, durable guidance is this, check current recommendations specifically when setting this up, rather than trusting whatever number happens to be sitting in the tutorial or codebase you're referencing, since that number is a snapshot of a past moment, not a permanently correct value.

A Practical Way to Choose the Right Number for Your Own Server

// A quick, practical way to find a cost factor appropriate for your actual hardware,
// rather than trusting a number copied from somewhere else
import bcrypt from 'bcryptjs';

async function benchmarkCostFactor(rounds: number) {
  const start = Date.now();
  await bcrypt.hash('benchmark-password', rounds);
  return Date.now() - start;
}

// Run this on your actual production server or equivalent hardware,
// and pick the highest cost factor where a single hash still completes
// in a reasonable time for your login flow, commonly cited targets
// are in the range of a few hundred milliseconds

This gives you a real, current answer specific to your actual infrastructure, rather than a number that was correct for someone else's hardware at some point in the past and has simply been carried forward through tutorials and copy-paste ever since.

The Broader Rule This Points To

A security parameter borrowed from a tutorial is a snapshot of what was reasonable when that tutorial was written, not a permanently correct value. This applies beyond just bcrypt cost factors, TLS cipher suite choices, JWT expiration windows, rate limit thresholds, all of these are calibrated against assumptions, about hardware, about attacker capability, about acceptable risk, that shift over time. A value copied once and never revisited quietly drifts from "reasonable" toward "outdated" without any code change ever signaling that drift.

What to Actually Do About Your Own Codebase

Check what cost factor your app is actually using right now, and compare it against current guidance rather than assuming a number from an older tutorial or your own original setup is still appropriate. If it's genuinely outdated, increasing it is straightforward for new passwords going forward, though existing stored hashes were created with the old cost factor and remain at that lower value unless you specifically implement a rehash-on-next-login pattern, checking and upgrading a user's stored hash cost factor the next time they successfully log in with their correct password.

Check what cost factor your own app is actually using, and when you last revisited that number versus just inheriting it from the original setup or a tutorial. Drop what you find in the comments, genuinely curious how many people have actually reconsidered this since first setting it up versus never touching it again.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Optional Chaining Is Probably Hiding Real Bugs in Your Next.js App

Anas Sheikh — Sat, 19 Sep 2026 10:55:36 +0000

Optional chaining is genuinely useful for values that are legitimately, expectedly sometimes absent. The problem is how often it gets applied defensively, everywhere, as a reflex against crashes, including on values that should always exist if everything upstream is actually working correctly. When one of those genuinely-should-never-be-undefined values is undefined anyway, ?. doesn't surface that as the real problem it is, it just quietly renders nothing and moves on.

The Pattern That Looks Like Careful, Defensive Code

export default async function DashboardPage() {
  const session = await getSession();
  const user = await getUserData(session?.userId);

  return (
    <div>
      <h1>Welcome, {user?.name}</h1>
      <p>Role: {user?.role}</p>
      {user?.role === 'admin' && <AdminPanel />}
    </div>
  );
}

Every one of these optional chains looks like responsible, defensive coding. If session is somehow null, session?.userId gracefully becomes undefined instead of throwing. If user fails to load, the page still renders instead of crashing. This feels careful. It's also actively hiding the fact that, if this route is only reachable by an authenticated user in the first place, session and user being undefined here isn't a normal, expected condition, it's a sign something upstream is genuinely broken, an auth check that should have redirected but didn't, a database lookup silently failing, a race condition in how the session gets set. None of that gets surfaced. The page just quietly shows "Welcome, " with a blank name and no admin panel, and looks like a minor rendering glitch instead of the real bug it actually is.

Why This Is Worse Than It Sounds for the Admin Check Specifically

{user?.role === 'admin' && <AdminPanel />}

This line deserves particular attention. If user is unexpectedly undefined, user?.role evaluates to undefined, the comparison to 'admin' is false, and the admin panel correctly doesn't render. That specific outcome is safe, a broken session fails closed here, not open. But notice what's actually happening, a genuinely serious bug, the current user's identity failing to load at all, on a page that's supposed to require authentication, is being silently absorbed into the exact same code path as "this user is correctly not an admin." Both produce identical, unremarkable output. One of them is completely normal. The other represents your auth system genuinely malfunctioning, and nothing distinguishes them from each other anywhere in this code.

The Actual Distinction Worth Making Deliberately

Values that are legitimately, expectedly sometimes absent, an optional profile bio, an optional avatar image, a field that's genuinely allowed to not exist as part of normal, correct behavior. Optional chaining is exactly the right tool here.

Values that should always exist if everything upstream actually worked correctly, the current user on an authenticated route, a database record that was just confirmed to exist moments earlier, a required field on a validated form submission. Optional chaining on these doesn't handle an edge case gracefully, it hides a real failure by making it look identical to a normal, unremarkable state.

What to Do Instead for the Second Category

export default async function DashboardPage() {
  const session = await getSession();
  if (!session) {
    redirect('/login'); // handle the genuinely expected "not logged in" case explicitly
  }

  const user = await getUserData(session.userId);
  if (!user) {
    // session exists but the user record doesn't, this is a real, unexpected problem
    console.error('Session exists but user not found:', session.userId);
    throw new Error('User data could not be loaded'); // let it surface, don't hide it
  }

  return (
    <div>
      <h1>Welcome, {user.name}</h1>
      <p>Role: {user.role}</p>
      {user.role === 'admin' && <AdminPanel />}
    </div>
  );
}

No optional chaining needed anywhere past this point, because both genuinely expected absence cases, no session, get handled explicitly, with a real redirect and a real, loud error respectively, rather than silently smoothed over. Everything after those two checks can safely assume session and user are real, present values, because any case where they aren't has already been caught and surfaced, not quietly absorbed into a blank render.

The Actual Rule

Optional chaining should be a deliberate choice for values that are genuinely, normally allowed to be absent, not a reflexive habit applied to anything that might theoretically be undefined. For a value that represents a genuine invariant, something that should always be true if the rest of the system is working correctly, handle its absence explicitly, a redirect, a thrown error, a logged warning, something that actually surfaces the problem, rather than a ?. that quietly renders nothing and leaves the real bug invisible until someone notices the symptom much later, disconnected from its actual cause.

A Practical Way to Audit Your Own Code

For every ?. in a codebase, ask honestly, is this value legitimately allowed to be missing as part of normal, correct behavior, or would its absence here actually indicate something upstream is broken. The first case is optional chaining used correctly. The second is optional chaining quietly doing the opposite of what defensive code is supposed to do, hiding a real failure instead of catching it.

Go find the optional chains in your own codebase specifically sitting on values you'd genuinely be alarmed to discover were undefined, an authenticated user, a record that was just confirmed to exist. If any of those chains are just gracefully rendering blank instead of surfacing a real problem, that's worth fixing. Drop what you find in the comments.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Adding priority to Every Image in Next.js Can Actually Make Your Site Slower

Anas Sheikh — Fri, 18 Sep 2026 10:32:33 +0000

This is a genuinely counterintuitive one, since the natural instinct when trying to speed up image loading is to mark more images as high priority, and that instinct, applied broadly, actively works against the exact goal it's trying to achieve.

What priority Actually Does

<Image src="/hero.jpg" alt="Hero" width={1200} height={600} priority />

The priority prop tells Next.js to preload this specific image, fetching it immediately, ahead of the browser's normal lazy-loading behavior, and to skip the default loading="lazy" treatment entirely. This exists specifically for the one image that matters most for perceived load speed, usually the hero image or whatever's driving your Largest Contentful Paint metric, the specific thing a visitor sees first and that most directly determines how fast the page feels to load.

Why More Priority Images Feels Like It Should Help

The instinct is understandable, if priority makes one image load faster, marking several important-looking images as priority should make the whole page feel faster, right. This reasoning treats "priority" as a simple speed boost you can apply liberally, more of a good thing being better, rather than what it actually is, a request to the browser to allocate scarce, limited bandwidth and rendering attention to this specific resource first, ahead of everything else.

What Actually Happens With Multiple priority Images

// A product page marking every product thumbnail as priority
{products.map((product) => (
  <Image
    key={product.id}
    src={product.image}
    alt={product.name}
    width={300}
    height={300}
    priority // applied to every single one
  />
))}

Every image marked priority competes for the same limited early bandwidth and browser attention simultaneously. Instead of one clear, fast-loading LCP element, the browser is now juggling ten, twenty, however many priority requests all at once, none of which gets the focused, immediate loading priority was actually designed to provide. The specific image that should have been your fastest, most important visual element now loads alongside, and competes against, a dozen others that never needed that treatment in the first place, and your actual LCP timing often gets measurably worse, not better, than if only the genuinely critical image had been marked.

Why This Doesn't Show Up Obviously in Casual Testing

On a fast connection, with a small number of images, and especially in local development, the practical difference between one priority image and ten is often small enough to not be obviously noticeable just clicking around. The real cost shows up specifically on a slower connection, mobile networks in particular, or on a page with genuinely many images, exactly the conditions where LCP optimization matters most in the first place, and exactly the conditions a developer testing casually on a fast office connection is least likely to be experiencing themselves.

The Actual Rule: One, Maybe Two, Never More Than That

priority should go on the single image that's actually your LCP element, the largest, most prominent visual content visible without scrolling, and essentially nothing else. For a typical page, that's one image. Occasionally a genuine case exists for two, a hero image plus one other unusually prominent above-the-fold element, but the number should be small and deliberate, never applied as a blanket default across a loop of images or a whole gallery.

// ✅ One deliberate priority image, everything else loads normally
export default function ProductPage({ product, related }) {
  return (
    <div>
      <Image src={product.mainImage} alt={product.name} width={800} height={800} priority />

      <div className="grid">
        {related.map((item) => (
          <Image key={item.id} src={item.image} alt={item.name} width={200} height={200} />
          // no priority here, these genuinely benefit from normal lazy loading
        ))}
      </div>
    </div>
  );
}

The related products grid, below the main image and likely below the fold on most screens anyway, doesn't need or benefit from eager loading, letting them lazy-load normally is not just acceptable, it's actually the better choice for overall page performance.

How to Actually Identify Your Real LCP Element

Chrome DevTools' Performance panel, or a Lighthouse report, directly identifies which specific element on your page is being measured as the Largest Contentful Paint, rather than guessing based on which image looks most important. This is worth checking directly rather than assuming, since the actual LCP element is sometimes a different image than intuition would suggest, particularly on pages with unconventional layouts.

Checking Your Own Codebase

grep -rn "priority" --include="*.tsx" app/ components/ | grep -i image

If this turns up priority inside a .map() loop, applied to every item in a list or grid, that's almost certainly this exact issue, worth reconsidering down to the single genuinely critical image, or removing it from the loop entirely if nothing in that specific list is actually the page's real LCP element.

The Actual Rule

priority is a scarce resource allocation, not a generic speed setting, and using it on multiple images doesn't compound the benefit, it dilutes it. One deliberate, correctly identified LCP image with priority, everything else loading normally, reliably outperforms a page where several images all compete for the same eager-loading treatment simultaneously.

If you've got priority applied inside a .map() loop or on more than one or two images on any given page, worth checking your actual Lighthouse LCP score before and after trimming it down to just the real LCP element. Drop what you find in the comments, genuinely curious how much this moves the needle in practice across different real projects.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Calling .sort() or .push() Directly on React State Might Not Trigger a Re-render

Anas Sheikh — Thu, 17 Sep 2026 11:43:24 +0000

This is an old, well-known React gotcha that's still genuinely common in real Next.js apps, specifically because the code that triggers it looks completely idiomatic JavaScript, and it works correctly in enough situations that the actual failure mode feels random and hard to pin down the first time you hit it.

The Setup That Looks Completely Normal

'use client';
import { useState } from 'react';

export function QueueList({ initialEntries }: { initialEntries: QueueEntry[] }) {
  const [entries, setEntries] = useState(initialEntries);

  function handleSort() {
    entries.sort((a, b) => a.priority - b.priority); // mutates in place
    setEntries(entries); // same array reference as before
  }

  return (
    <div>
      <button onClick={handleSort}>Sort by priority</button>
      {entries.map((entry) => (
        <div key={entry.id}>{entry.name}</div>
      ))}
    </div>
  );
}

Click the button, and often nothing visibly happens, even though the array genuinely did get sorted internally. The UI just doesn't reflect it, and there's no error anywhere to point at why.

Why This Happens

Array.prototype.sort() sorts the array in place and returns a reference to that same array, not a new one. entries.sort(...) mutates the existing array object directly, then setEntries(entries) passes React that exact same reference it already had. React's default change detection for state uses Object.is comparison, essentially asking "is this the same object as before." Since entries is literally the same array reference, just with its internal contents rearranged, React concludes nothing has changed and skips the re-render entirely, regardless of the fact that the actual order of items inside that array is genuinely different now.

Why This Feels Inconsistent Rather Than Reliably Broken

This is what makes it especially confusing to debug. If any other state update happens around the same time, a parent re-rendering for an unrelated reason, another piece of state changing in the same component, React might re-render anyway, for that unrelated reason, and the sorted array happens to display correctly as a side effect, not because the sort itself was recognized as a real state change. This makes the bug appear to work sometimes and fail other times, depending on what else happens to be triggering renders nearby, when the actual underlying cause, mutating state in place, is completely consistent and never actually changed.

The Same Issue With Other Common Array Methods

// All of these mutate in place and return the same reference,
// so setting state with the result changes nothing as far as React can tell

entries.push(newEntry);
setEntries(entries); // same reference

entries.splice(index, 1);
setEntries(entries); // same reference

entries.reverse();
setEntries(entries); // same reference

push, splice, reverse, and sort all share this exact same trap, they mutate the array in place and return either the same array or an unrelated value, never a fresh, new array reference reflecting the change in a way React's default comparison can detect.

The Actual Fix: Always Create a New Array

function handleSort() {
  const sorted = [...entries].sort((a, b) => a.priority - b.priority);
  setEntries(sorted); // a genuinely new array reference
}

function handleAdd(newEntry: QueueEntry) {
  setEntries([...entries, newEntry]); // new array, not a mutated push
}

function handleRemove(id: string) {
  setEntries(entries.filter((entry) => entry.id !== id)); // filter always returns a new array
}

[...entries].sort(...) spreads the existing array into a brand new one first, then sorts that new copy, leaving the original untouched and producing a genuinely different reference for React to correctly detect as a real change. filter, map, and the spread operator combined with concat all naturally produce new arrays rather than mutating in place, which is exactly why they're the generally recommended pattern for updating array state in React, not just a stylistic preference.

Why This Matters More With Server-Fetched Data Specifically

In a Next.js app, initial data often comes from a Server Component, passed down as a prop, then held in client-side state for interactive filtering, sorting, or reordering. This exact pattern, seed client state from server data, then let the user interact with it, is common enough that this specific mutation trap shows up constantly in dashboards, queues, and any interactive list, list, sort, filter functionality is one of the most common things built on top of server-fetched data displayed client-side.

A Quick Way to Catch This in Your Own Code

Search for direct calls to mutating array methods on state variables, specifically checking whether the result gets spread into something new or passed straight back into the setter as-is:

grep -n "\.sort(\|\.push(\|\.splice(\|\.reverse(" --include="*.tsx" -r components/

For each match, check whether it's operating on a piece of React state, and whether the result is a genuinely new array or the same mutated reference being handed back to setState.

The Actual Rule

Never call a mutating array method directly on a piece of React state and pass the result straight back into its own setter. Spread into a new array first, or use a naturally non-mutating method, map, filter, concat, the spread operator, so every state update produces a genuinely new reference React can reliably detect as an actual change, rather than an in-place mutation that might or might not happen to trigger a re-render depending on unrelated things happening nearby.

If you've hit this exact "the button doesn't seem to do anything, except sometimes it does" confusion before, genuinely curious whether it turned out to be this, mutating state in place, or something else entirely. Drop what actually happened in the comments.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

generateMetadata and Your Page Component Are Probably Querying the Same Data Twice

Anas Sheikh — Wed, 16 Sep 2026 11:30:19 +0000

I wrote earlier about cache() fixing redundant database queries when multiple components in a tree independently call the same query function. There's one specific, extremely common place this exact pattern shows up that's worth calling out directly, because it's not an edge case, it's the default shape of nearly every dynamic page with SEO metadata.

The Setup Almost Every Dynamic Page Has

// app/blog/[slug]/page.tsx
import { getPost } from '@/lib/queries/posts';

export async function generateMetadata({ params }) {
  const { slug } = await params;
  const post = await getPost(slug); // query #1

  return {
    title: post.title,
    description: post.excerpt,
  };
}

export default async function BlogPost({ params }) {
  const { slug } = await params;
  const post = await getPost(slug); // query #2, same post, same request

  return (
    <article>
      <h1>{post.title}</h1>
      <div>{post.content}</div>
    </article>
  );
}

This is the completely standard pattern from the Next.js metadata setup covered in an earlier post, and it's genuinely necessary, generateMetadata needs the post's title and excerpt for the meta tags, the page component needs the post's full content to actually render it. Both run for every single request to this page. Both call getPost(slug) independently. Without a specific fix, that's two full database round trips for what is, semantically, the exact same piece of data, fetched twice, for every single page view.

Why This Specific Case Matters More Than It Might Seem

This isn't a rare pattern someone might occasionally write, it's the default shape of generateMetadata combined with any dynamic page, which means it's quietly doubling database load on nearly every content-driven page across an entire site, blog posts, product pages, any dynamically rendered detail page with SEO metadata. A site with meaningful traffic on these pages is paying for twice the database queries it actually needs, on some of its most frequently visited pages, for no functional reason.

The Fix: Wrap the Query in React's cache()

// lib/queries/posts.ts
import { cache } from 'react';
import { connectDB } from '@/lib/db';
import Post from '@/models/Post';

export const getPost = cache(async (slug: string) => {
  await connectDB();
  return Post.findOne({ slug }).lean();
});

That's the entire fix, no changes needed anywhere else. generateMetadata and the page component both still call getPost(slug) exactly as before, the code looks identical. What changes is that React's request memoization now recognizes both calls, same function, same argument, within the same render pass, and only actually executes the underlying query once, returning the cached result for the second call.

Why This Is Worth Checking Specifically, Not Just Generally

The earlier post on this topic covered the general pattern, multiple components in a tree calling the same query. This specific case is worth checking on its own because it's so easy to miss precisely because generateMetadata and the page component don't look like they're part of the same "component tree" in the way nested components obviously are. They're two separate exported functions in the same file, and it's genuinely easy to write both, each looking completely correct in isolation, without ever noticing they're duplicating a database call for the same request.

A Quick Way to Verify This Is Actually Happening

Add a temporary log inside the un-cached query function and load the page once:

export async function getPost(slug: string) {
  console.log('getPost called for:', slug); // temporary
  await connectDB();
  return Post.findOne({ slug }).lean();
}

If you see that log line twice for a single page load, that's this exact issue, confirmed directly rather than assumed. After wrapping the function in cache(), the same test should show it logging only once per request.

Where This Doesn't Apply

If generateMetadata and the page component genuinely need different data, metadata pulling from a lighter, separate summary endpoint while the page fetches full content from somewhere else entirely, there's no duplication to fix, since they're not actually calling the same underlying function with the same arguments in the first place. This fix specifically applies when both are calling the identical query function, which, for most blog and content-driven page setups, is exactly the common case.

The Actual Rule

Any query function called both inside generateMetadata and inside the page component it belongs to should be wrapped in cache(), as close to a universal default as a rule gets in this specific area. It costs nothing to add, changes no calling code, and directly eliminates a real, silent, doubled database query that exists by default on essentially every dynamically rendered page with SEO metadata.

Go check any page in your own project using generateMetadata alongside a matching page component, specifically whether the underlying query function is wrapped in cache(). If it's not, you're very likely double-querying on every single page load for that route. Drop what you find in the comments.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Setting dynamicParams to false Can Make Brand New Content 404 Until Your Next Deploy

Anas Sheikh — Tue, 15 Sep 2026 09:22:52 +0000

This one's a genuinely reasonable setting that causes a genuinely confusing symptom, a brand new piece of content, added correctly, visible in your CMS, just returns a 404 on the live site, with nothing in your code actually wrong.

What dynamicParams Actually Controls

// app/blog/[slug]/page.tsx
export async function generateStaticParams() {
  const posts = await getAllPosts();
  return posts.map((post) => ({ slug: post.slug }));
}

export const dynamicParams = false; // reject anything not in the list above

export default async function BlogPost({ params }) {
  const { slug } = await params;
  const post = await getPost(slug);
  if (!post) notFound();
  return <article>{post.content}</article>;
}

generateStaticParams runs at build time, pre-rendering a page for every slug it returns. dynamicParams controls what happens for a slug that shows up in a request but wasn't in that build-time list. The default is true, meaning Next.js will attempt to render that path on demand anyway, genuinely useful behavior for content added after the last build. Setting it explicitly to false tells Next.js to immediately 404 anything not in the pre-generated list, full stop, no attempt to render it fresh.

Why Someone Sets This Deliberately

dynamicParams = false is a reasonable, intentional choice in specific situations, guaranteeing that only explicitly known, build-time-verified paths are ever servable, useful for something like a fixed set of product pages where an unexpected slug showing up would genuinely indicate a bug or a malicious request, not legitimate new content. It's not a mistake in that context, it's a deliberate constraint.

Where This Actually Causes Real Problems

For content that genuinely grows over time, a blog, a CMS-driven catalog, anything where new items get added independently of a code deployment, this exact setting means every new item is completely inaccessible, a real 404, until the next build actually happens and includes it in generateStaticParams's output.

1. Blog post published in the CMS at 2:00 PM
2. Someone shares the link
3. Visitor clicks it, gets a 404
4. The post is completely correct in the CMS, the slug is right, everything's fine there
5. The site just has no idea this post exists yet, since the last build predates it

This is exactly the kind of gap that's genuinely confusing to diagnose, since checking the CMS shows everything looks correct, checking the code shows the query logic is fine, and the actual cause, a build-time snapshot that's now stale, doesn't announce itself anywhere obvious.

The Actual Fix, Depending on What You Actually Need

If new content should be servable immediately without waiting for a rebuild, this is almost always the right default, just don't set dynamicParams to false at all, or set it explicitly to true:

export const dynamicParams = true; // or simply omit this line, true is the default

New slugs not in the build-time list get rendered on demand, then, depending on your caching setup, can be cached going forward, giving you both immediate availability and good performance after the first request.

If you genuinely need the strict guarantee dynamicParams = false provides, a fixed, known set of pages where anything else really should 404, pair it with a deliberate process for triggering a new build whenever new content is actually added, a webhook from your CMS triggering a redeploy, rather than relying on a periodic or manual build schedule that leaves a real gap between content going live and the site actually knowing about it.

// A CMS webhook triggering an on-demand revalidation or rebuild
// whenever new content is actually published, closing the gap

Why This Interacts Badly With Good SEO Practices

This is a genuinely important compounding issue. If you've set up automatic sitemap generation, covered in an earlier post, and someone shares a freshly published post before the next build happens, both the visitor clicking the link and, worse, a search engine crawler attempting to index that URL early, encounter a real 404. A crawler hitting a 404 on a URL is a real, negative signal, not a neutral non-event, and repeated early 404s on genuinely valid content can meaningfully hurt how quickly and how well that content ends up indexed once it is actually available.

How to Check If This Is Affecting You

If you're using dynamicParams = false anywhere, specifically check how long the gap actually is between content being published in your CMS and the next site build or deploy happening. If that gap is measured in hours or days rather than minutes, and the content in question is meant to be immediately live, that gap is a real, live problem, not a theoretical edge case.

grep -rn "dynamicParams" --include="*.tsx" app/

The Actual Rule

dynamicParams = false is a deliberate access-control decision, not a performance optimization, and it should only be used where truly unexpected paths genuinely should be rejected. For any content source that grows independently of your deployment schedule, a blog, a CMS-driven catalog, user-generated content, the default true behavior, or an explicit true, is almost always what you actually want, letting new content render on demand rather than waiting on the next build to even acknowledge it exists.

If you're using dynamicParams = false anywhere in a project with content that grows outside your deploy cycle, worth checking today whether new content is actually reachable the moment it's published, or silently 404ing until the next deploy catches up. Drop what you find in the comments.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Using searchParams in a Next.js Page Silently Opts It Out of Static Rendering Too

Anas Sheikh — Mon, 14 Sep 2026 08:49:10 +0000

I wrote earlier about a buried cookies() call silently forcing an entire page into dynamic rendering. searchParams causes the exact same category of behavior, through a completely different, and in some ways more surprising, mechanism, since using it doesn't look like reading anything server-specific at all.

Why This One Is Extra Surprising

cookies() and headers() at least sound like they're reaching into something request-specific, so forcing dynamic rendering feels intuitive once you think about it. searchParams just looks like reading a prop, a completely normal-looking destructure at the top of a page component. There's nothing about the syntax that signals "this is a server-specific value tied to this exact request."

// app/products/page.tsx
export default function ProductsPage({
  searchParams,
}: {
  searchParams: Promise<{ category?: string; page?: string }>;
}) {
  // reading searchParams here means this page can no longer be
  // statically generated, full stop, regardless of what else it does
}

The moment a page component accepts and uses searchParams, Next.js treats the entire page as dynamic. This makes complete sense once you think through why, the query string is part of the actual request URL, and a page reading it necessarily produces different output for /products?category=shoes versus /products?category=hats, which is inherently incompatible with generating one fixed, static HTML output ahead of time. It's correct, intentional behavior. It's just not obviously signaled by the code itself the way reading cookies() is.

Where This Actually Costs You

For a genuinely filterable page, a product listing with category and sort filters, this dynamic behavior is exactly correct and necessary, the whole feature depends on rendering different content per query string. This isn't a bug to fix in that case.

The actual cost shows up when searchParams gets accepted by a page component out of habit, or copied from a similar page, without the page actually using the specific query params in any way that changes its output.

// app/about/page.tsx
export default function AboutPage({
  searchParams, // accepted but never actually used for anything meaningful
}: {
  searchParams: Promise<{ [key: string]: string | undefined }>;
}) {
  return (
    <div>
      <h1>About Us</h1>
      <p>We build things.</p>
    </div>
  );
}

If this component's type signature includes searchParams but the actual rendered output never varies based on it, simply accepting the prop can still be enough to affect how Next.js treats the route, depending on whether the value is actually read and used within the render. A genuinely static about page, forced into unnecessary dynamic rendering because of a leftover parameter or copy-pasted type signature from a different page, loses real caching benefit for no actual functional reason.

How to Tell If This Is Actually Happening

Same check as the earlier cookies() post, run a real build and look at the route summary:

npm run build

A route marked dynamic (ƒ) that you'd expect to be static (○) is worth investigating. If the page genuinely needs to vary based on query parameters, that's correct and expected. If it doesn't, actually use those params to produce different output, the fix is simply not accepting or reading searchParams in that component at all.

The Distinction That Actually Matters

Does this specific page's rendered output genuinely need to differ based on the query string? If yes, dynamic rendering triggered by searchParams is correct, intentional, and not something to fight against, the feature depends on it.

Is searchParams present in the component's signature or destructured, but never actually used to change what gets rendered? That's the case worth fixing, either by removing the unused parameter entirely, or, if the params are genuinely needed for something that doesn't affect the main rendered content, handling that specific piece in a way that doesn't force the whole page dynamic, a client-side read via useSearchParams() inside a small Client Component, for something that only needs to react to params after the initial static render.

// A pattern that keeps the main page static while still reacting to query params
// for a small, specific piece of UI that genuinely needs them
export default function ProductsPage() {
  return (
    <div>
      <h1>Our Products</h1>
      <ProductGrid /> {/* genuinely static content */}
      <QueryAwareBanner /> {/* small client component reading useSearchParams() */}
    </div>
  );
}

The Broader Pattern

This is the same underlying lesson as the cookies() post, applied to a different, less obviously "server-specific" mechanism. Next.js's static-versus-dynamic decision is driven by what a page actually reads and depends on, not by how obviously server-related that code looks at a glance. searchParams, cookies(), and headers() all trigger the same category of behavior, and all three are easy to include without actually needing what they provide, especially when copying a page's structure from a similar one that genuinely did need it.

Go check your own build output for any page accepting searchParams that doesn't actually use it to change what gets rendered. If you find one, that's a free, easy static-rendering win sitting right there. Drop what you find in the comments.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751

Changing an Environment Variable on Vercel Doesn't Do Anything Until You Actually Redeploy

Anas Sheikh — Sun, 13 Sep 2026 09:23:20 +0000

This causes a specific, recurring kind of confusion, someone updates an API key or a config value in their hosting dashboard, refreshes the live site expecting the new behavior, and sees the old value still very much in effect, with no error, no indication anything's wrong, just a value that appears to be stuck.

Why This Happens

Next.js resolves environment variables at different times depending on how they're used, and that distinction matters far more than it initially seems to.

NEXT_PUBLIC_ variables get inlined into the client JavaScript bundle at build time. This was covered in an earlier post about these values leaking into the browser, but the same mechanism has a second, less dangerous but equally confusing consequence, the actual value gets baked directly into the compiled JavaScript during the build step. Once that bundle exists, the value inside it is fixed, permanently, until a new build produces a new bundle. Changing the environment variable in your hosting dashboard afterward has zero effect on a bundle that's already been built and deployed.

Server-only variables read at request time genuinely do update immediately, since process.env.SOME_SECRET read inside a Server Action or route handler is evaluated fresh on every request, at runtime, not baked into anything at build time.

Statically generated pages sit in between. A page generated at build time, using generateStaticParams or simply being a static route with no dynamic data source, has its output, including any environment variable value referenced during that generation, fixed at that build moment. Even a server-only variable, if it's used to generate static content rather than read fresh on each request, won't reflect a later change until the next build regenerates that static output.

A Concrete Example of the Confusion

// next.config.ts
const nextConfig = {
  env: {
    API_BASE_URL: process.env.API_BASE_URL,
  },
};

// Somewhere used inside a page that gets statically generated
const apiUrl = process.env.API_BASE_URL;

Someone updates API_BASE_URL in the Vercel dashboard, pointing to a new endpoint, expecting the live site to immediately start hitting it. If this value feeds into anything statically generated, the already-deployed static output still references the old URL, since it was baked in at the previous build, and nothing about updating an environment variable in a dashboard triggers a new build on its own, that value change and an actual redeploy are two completely separate events.

Why Nobody Warns You About This Upfront

Most environment variable tutorials focus entirely on setup, getting a value into your app at all, and rarely cover the lifecycle question, when exactly does a change to that value actually take effect. It's a genuinely reasonable mental model to assume an environment variable behaves like a live configuration switch, flip it, see the effect immediately, since that's how environment variables often work in simpler, non-static-generation contexts. Next.js's mix of build-time and runtime resolution breaks that mental model in ways that aren't obvious until you've specifically been burned by it.

The Actual Rule

If a value is used anywhere that gets pre-rendered, NEXT_PUBLIC_ variables always, statically generated pages sometimes, changing it in your hosting dashboard requires an actual new deployment before the change takes effect anywhere. If a value is read purely at request time, inside a Server Action, a route handler, or a dynamically rendered page with no static generation involved, a dashboard change genuinely does take effect on the very next request, no redeploy needed.

How to Actually Tell Which Case You're In

Ask whether the specific code reading this variable runs during the build (page generation, next.config.ts, anything feeding generateStaticParams) or during an actual live request (a Server Action, a route handler, a dynamically rendered page). Build-time usage needs a redeploy for any change to matter. Request-time usage picks up a dashboard change immediately.

When in doubt, just redeploy after any environment variable change. This is the safe, low-effort default, a redeploy after an env var update costs a few minutes and completely eliminates the ambiguity, versus spending real time debugging why a "clearly correct" configuration change appears to be having zero effect on the live site.

Why This Matters More for Secrets Rotation Specifically

This has real security implications too, not just convenience ones. If you rotate a compromised API key or secret by updating it in your hosting dashboard, and any part of your app statically baked the old value in, that old, compromised value can remain live and in use until an actual redeploy happens, well after you believed the rotation was already complete. Treating "updated the environment variable" and "the new value is actually live everywhere it matters" as two separate, sequential steps, not one single action, matters especially in exactly this scenario.

If you've ever updated an environment variable and been confused why the change didn't seem to take effect, genuinely curious whether this was the actual cause, or something else entirely. Drop your experience in the comments.

Get the templates: https://pixelanas.gumroad.com

Anas, full-stack Next.js developer building SaaS products and premium templates. X: @ASheikh69751