DEV Community: Anas Sheikh

Your Server Component Might Be Fetching Data Three Times Slower Than It Needs To

Anas Sheikh — Wed, 30 Sep 2026 09:34:25 +0000

This is one of the easiest performance mistakes to write without noticing, since the code reads completely naturally, top to bottom, each line waiting for the one before it to finish, exactly the way most people learn to write async code in the first place.

The Setup That Reads Perfectly Naturally

// app/dashboard/page.tsx
export default async function DashboardPage() {
  const user = await getUser();
  const posts = await getPosts();
  const comments = await getComments();
  const analytics = await getAnalytics();

  return (
    <Dashboard
      user={user}
      posts={posts}
      comments={comments}
      analytics={analytics}
    />
  );
}

Four await calls, one after another. Clean, readable, and exactly how sequential code naturally gets written when each line is just "get the next thing I need." The problem is that none of these four calls actually depend on the results of the others, getPosts doesn't need anything from getUser, getComments doesn't need anything from getPosts, and so on. They're all independently fetchable at the same time, and writing them sequentially means the total page load time is the sum of all four, not the time of the single slowest one.

Why This Costs More Than It Looks Like It Should

If each of these four calls takes roughly 150 milliseconds, a genuinely reasonable time for a real database query, the sequential version takes roughly 600 milliseconds total, each one waiting for the previous one to fully complete before even starting. Run the same four calls concurrently instead, and the total time is roughly 150 milliseconds, the time of the single slowest call, since they're all genuinely happening at once rather than queued up one behind another for no actual reason.

This is a real, measurable difference on a page real users are waiting for, and it's entirely avoidable, since nothing about these four pieces of data actually requires this sequential order, the code just happens to be written in a shape that imposes one anyway.

The Actual Fix: Promise.all for Independent Fetches

export default async function DashboardPage() {
  const [user, posts, comments, analytics] = await Promise.all([
    getUser(),
    getPosts(),
    getComments(),
    getAnalytics(),
  ]);

  return (
    <Dashboard
      user={user}
      posts={posts}
      comments={comments}
      analytics={analytics}
    />
  );
}

Promise.all starts all four requests essentially simultaneously and waits for all of them to complete together, rather than starting each one only after the last one finished. Same data, same final render, a fraction of the total wait, purely by removing an ordering constraint that was never actually necessary in the first place.

Where This Gets Genuinely Trickier: Partial Dependencies

Not every case is this clean. Sometimes one piece of data genuinely depends on another, and mixing dependent and independent fetches needs a bit more care than a single flat Promise.all.

// ❌ Everything sequential, even though posts and analytics don't need each other
export default async function DashboardPage() {
  const user = await getUser();
  const posts = await getPostsForUser(user.id); // genuinely depends on user
  const analytics = await getAnalytics(); // does NOT depend on user at all
  return <Dashboard user={user} posts={posts} analytics={analytics} />;
}

// ✅ Only the genuine dependency stays sequential, everything else runs alongside it
export default async function DashboardPage() {
  const analyticsPromise = getAnalytics(); // starts immediately, not awaited yet

  const user = await getUser();
  const posts = await getPostsForUser(user.id); // genuinely needs user.id first

  const analytics = await analyticsPromise; // was already running this whole time

  return <Dashboard user={user} posts={posts} analytics={analytics} />;
}

Starting getAnalytics() without immediately awaiting it lets that request begin running in the background while getUser and getPostsForUser proceed through their genuine, necessary sequence. By the time the code actually needs the analytics result, it's very likely already finished, or at least has been running the whole time instead of only starting after everything else completed.

How to Actually Spot This in Your Own Code

Look for multiple await statements in a row where each one calls a genuinely independent function, nothing on the left side of an earlier line appears as an argument to a later one. That absence of a real data dependency is the signal, these calls have no actual reason to be sequential, and wrapping them in Promise.all is very likely a free, meaningful performance improvement with zero behavior change.

grep -B2 -A2 "await get" app/**/page.tsx

Scanning for clusters of consecutive await calls to different functions, then checking whether any of them genuinely reference the previous line's result, is a quick, practical way to find real waterfall candidates across an existing codebase.

Why This Matters More on Pages With Several Independent Data Sources

A dashboard, a page with several distinct widgets or sections each backed by their own query, is exactly where this pattern accumulates the most cost, since it's common to have four, five, or more genuinely independent pieces of data feeding one page, each one innocently written as its own await line, each one adding its full latency on top of all the others instead of overlapping.

The Actual Rule

Before awaiting multiple async calls sequentially, check whether any of them genuinely need a previous call's result. If none do, Promise.all turns their combined wait time from a sum into a maximum, for free, with no behavior change. For a genuine mix of dependent and independent calls, start the independent ones early without immediately awaiting them, so they run in the background while the real, necessary sequence proceeds.

I check every Server Component I write for exactly this pattern now, across client work and the dashboards and templates I build at pixelanas.com, since it's one of the highest-value, lowest-effort performance fixes available, and I've written about related data-fetching patterns on the blog too.

Go check your own dashboard or any data-heavy page for consecutive await calls with no genuine dependency between them. If you find some, wrapping them in Promise.all is very likely a free 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

Calling revalidateTag on an Already-Uncached Fetch Does Nothing, and Next.js Won't Tell You

Anas Sheikh — Tue, 29 Sep 2026 09:06:50 +0000

This is a genuinely quiet failure mode, since calling revalidateTag never errors, never warns, and appears to complete successfully every single time, whether or not it actually invalidated anything at all.

The Setup That Looks Correct

// lib/queries/posts.ts
export async function getPosts() {
  const res = await fetch('https://api.example.com/posts', {
    next: { tags: ['posts'] },
    cache: 'no-store', // added later, maybe for a different, unrelated reason
  });
  return res.json();
}

// actions/posts.ts
'use server';
import { revalidateTag } from 'next/cache';

export async function createPost(formData: FormData) {
  await db.posts.create({ /* ... */ });
  revalidateTag('posts'); // runs without error, but does genuinely nothing here
}

The tag is there. The revalidation call is there. Nothing throws. And this specific combination doesn't actually do what it looks like it does.

Why This Specific Combination Is a No-Op

cache: 'no-store' tells Next.js to never cache this fetch's result at all, fetch it fresh, every single time, full stop. Tagging with next: { tags: [...] } only matters for a fetch whose result is actually being cached, since the tag is metadata attached to a cache entry, used to find and invalidate that entry later. If there's no cache entry in the first place, because no-store explicitly prevented one from ever being created, the tag has nothing to attach to, and revalidateTag('posts') has nothing to actually invalidate when it runs. It completes, technically successfully, having done nothing, since there was never anything cached for it to clear.

Why This Is Easy to End Up With Without Noticing

This combination rarely gets written deliberately in one sitting, it usually accumulates. A fetch starts out cached, tagged, and working correctly with revalidateTag. Later, someone adds cache: 'no-store' to that same fetch, for a completely unrelated reason, debugging a different staleness issue, following advice for a different part of the app, copying a pattern from elsewhere, without registering that it silently makes the existing tag, and everything relying on revalidateTag('posts') elsewhere in the codebase, functionally inert.

The Same Silent Gap at the Route Level

This isn't limited to the fetch call itself. A route-level override has the identical effect on every fetch within that route, regardless of what caching options those individual fetch calls specify:

// app/blog/page.tsx
export const dynamic = 'force-dynamic'; // forces every fetch on this route to be uncached

export default async function BlogPage() {
  const posts = await getPosts(); // tags and cache options here are now irrelevant
  return <PostList posts={posts} />;
}

export const dynamic = 'force-dynamic' overrides caching behavior for the entire route, meaning any tags option on any fetch within it becomes similarly inert, even if that specific fetch call looks completely correctly configured for tag-based revalidation on its own.

Why Nothing Warns You About This

Both cache: 'no-store' and next: { tags: [...] } are individually valid, correct options, and Next.js has no way to know that combining them on the same fetch reflects a genuine mismatch in intent rather than a deliberate choice, since there's nothing inherently wrong with either option on its own. The framework can't distinguish "I meant to cache this and tag it, but also told it never to cache" from "I have some other genuine reason for both of these together," so it simply does exactly what each option says, individually, with no cross-check between them.

How to Actually Catch This

Check whether revalidateTag calls are actually having an effect, not just whether they run without error. Trigger the mutation, then check whether the next read genuinely reflects the change:

// A quick manual check: create a post, then immediately check whether
// the posts list reflects it without a hard refresh or waiting on
// the fetch's own natural cache lifetime to expire

If the change doesn't show up until a hard refresh or the cache's own natural expiration, despite revalidateTag having run, that's this exact mismatch, worth checking the actual fetch options and any route-level dynamic export for a conflict between "never cache this" and "this is tagged for cache invalidation."

The Actual Rule

A revalidateTag call only does real work against a fetch that is actually being cached under that tag, not merely tagged. cache: 'no-store' on the same fetch, or dynamic = 'force-dynamic' at the route level, both silently remove the cache entry that tag was supposed to point at, and the revalidation call becomes a harmless, successful-looking no-op. When adding or changing caching options on an existing fetch, it's worth explicitly checking whether that fetch is relied on elsewhere for tag-based revalidation, since the two settings can drift out of sync without either one looking wrong in isolation.

I run into this specific mismatch most often on projects where caching gets tuned incrementally over time, exactly the kind of pattern I try to catch early in the SaaS dashboards and templates I build at pixelanas.com. If this kind of caching nuance is useful, I go deeper into related patterns on the blog.

If you've got a revalidateTag call somewhere in your codebase, worth actually verifying it's doing real work right now, not just that it runs without error. Check the fetch it's supposed to be targeting for a cache: 'no-store' or route-level force-dynamic quietly canceling it out. 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

You Added a Content-Security-Policy Header and Your Next.js App Went Blank. Here's Why.

Anas Sheikh — Mon, 28 Sep 2026 08:43:12 +0000

You read that a Content-Security-Policy header is a good security hardening step. You add a sensible-looking policy to your Next.js config, deploy, and the site loads as a blank or half-working page with a wall of red errors in the console.

Nothing is wrong with your code. The policy is doing exactly what you told it to do, and what you told it to do happens to block Next.js itself.

The Header That Breaks Everything

// next.config.ts
const nextConfig = {
  async headers() {
    return [
      {
        source: '/(.*)',
        headers: [
          {
            key: 'Content-Security-Policy',
            value: "default-src 'self'; script-src 'self'",
          },
        ],
      },
    ];
  },
};

export default nextConfig;

script-src 'self' says scripts may only load from your own origin as external files. That sounds right, until you remember Next.js injects small inline <script> tags into every page, for hydration data, for the router, for streaming. Inline scripts are exactly what script-src 'self' forbids, so the browser refuses to run them, hydration never completes, and the page looks dead.

The Tempting Wrong Fix

value: "default-src 'self'; script-src 'self' 'unsafe-inline'"

This makes the errors disappear, and it also removes most of the protection you added the header for. 'unsafe-inline' tells the browser to run any inline script, including one an attacker managed to inject through an XSS hole. A CSP with 'unsafe-inline' in script-src still exists, but it no longer does the main job a CSP is supposed to do.

The Actual Fix: A Per-Request Nonce

A nonce is a random, single-use value generated for each request. You put it in the CSP header, and you attach the same value to the scripts you trust. The browser then only runs inline scripts carrying the matching nonce, and an injected script has no way to guess it.

Next.js supports this through middleware:

// middleware.ts
import { NextResponse } from 'next/server';
import type { NextRequest } from 'next/server';

export function middleware(request: NextRequest) {
  const nonce = Buffer.from(crypto.randomUUID()).toString('base64');

  const csp = [
    "default-src 'self'",
    `script-src 'self' 'nonce-${nonce}' 'strict-dynamic'`,
    `style-src 'self' 'nonce-${nonce}'`,
    "img-src 'self' blob: data:",
    "object-src 'none'",
    "base-uri 'self'",
  ].join('; ');

  const requestHeaders = new Headers(request.headers);
  requestHeaders.set('x-nonce', nonce);
  requestHeaders.set('Content-Security-Policy', csp);

  const response = NextResponse.next({ request: { headers: requestHeaders } });
  response.headers.set('Content-Security-Policy', csp);
  return response;
}

Next.js reads the nonce from the request's CSP header and applies it to the framework's own inline scripts automatically. For any script you add yourself, read the nonce and pass it along:

// app/layout.tsx
import { headers } from 'next/headers';
import Script from 'next/script';

export default async function RootLayout({ children }: { children: React.ReactNode }) {
  const nonce = (await headers()).get('x-nonce') ?? undefined;

  return (
    <html lang="en">
      <body>
        {children}
        <Script src="https://analytics.example.com/script.js" nonce={nonce} strategy="afterInteractive" />
      </body>
    </html>
  );
}

'strict-dynamic' in the policy lets a nonced script load further scripts it depends on, which keeps things like analytics loaders working without you allowlisting every domain by hand.

The Tradeoff Nobody Mentions Upfront

A nonce has to be unique per request, and it has to be baked into the HTML the server sends. That means any page using it must be rendered dynamically on each request. A statically generated page is built once ahead of time, so it cannot contain a fresh nonce for every visitor.

This is the same static versus dynamic rendering boundary covered in my earlier posts on cookies() and searchParams. Reading the nonce from headers() opts the route into dynamic rendering, so turning on nonce-based CSP across your whole site gives up static generation for every route it covers.

For a mostly static marketing site, that is a real cost. Two reasonable ways to handle it:

Apply the strict nonce policy only where it matters most, like authenticated dashboards and anything handling user input, and use a hash-based or more permissive policy for purely static pages.

Use hash-based CSP for static pages, where the script contents are known at build time, so each inline script's hash can be allowlisted instead of requiring a per-request nonce.

How to Test It Without Breaking Production

// Ship this first, it reports violations without blocking anything
{
  key: 'Content-Security-Policy-Report-Only',
  value: "default-src 'self'; script-src 'self' 'nonce-...'",
}

Content-Security-Policy-Report-Only logs every violation to the console and to a reporting endpoint without actually blocking a thing. Run it for a while, fix what it flags, then switch to the enforcing header. This is how you avoid the blank-page deploy from the top of this post.

The Actual Rule

A strict CSP and Next.js's inline scripts are incompatible unless you use nonces or hashes, and nonces mean dynamic rendering. Do not reach for 'unsafe-inline' to make errors go away, since that removes the protection you were adding. Start in report-only mode, decide which routes genuinely need the strictest policy, and accept that those routes will render per request.

I go through this same tradeoff when hardening client projects and the templates at pixelanas.com, and I write up more of these security and rendering details on the blog as I run into them.

If you have a CSP on a Next.js app right now, check whether it contains 'unsafe-inline' in script-src. If it does, it is worth knowing how much protection it is really giving you. 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

That Third-Party Script Tag You Copy-Pasted Is Probably Hurting

Anas Sheikh — Sun, 27 Sep 2026 09:35:19 +0000

Chat widgets, analytics snippets, ad network tags, review platform embeds, nearly all of them ship with a copy-paste <script> snippet meant for a plain HTML page, and pasted directly into a Next.js app without modification, several of them quietly do real damage to your actual performance metrics for content that has nothing to do with the widget itself.

The Copy-Paste That Looks Harmless

// app/layout.tsx
export default function RootLayout({ children }) {
  return (
    <html>
      <head>
        <script src="https://widget.example.com/embed.js"></script>
      </head>
      <body>{children}</body>
    </html>
  );
}

This is exactly the snippet most third-party services hand you, drop this in your <head>, done. It works, the widget shows up. It also, by default, blocks the browser from continuing to parse and render the rest of the page until this script finishes downloading and executing, regardless of whether the widget is something a visitor actually needs immediately, a chat bubble in the corner, or something they'll never notice loading a beat later.

Why This Specifically Matters for Your Core Web Vitals

A plain <script> tag with no special handling is render-blocking by default. For a chat widget, a review platform embed, most analytics tools, none of which are part of the actual content a visitor came to see, this render-blocking behavior directly delays your Largest Contentful Paint and can hurt Time to Interactive, real, measured metrics that affect both user experience and search ranking, all for a script whose own functionality genuinely doesn't need to block anything.

What next/script Actually Solves

Next.js provides next/script specifically to give you real control over when and how a third-party script loads, rather than accepting the plain HTML default of "block everything until this finishes."

import Script from 'next/script';

export default function RootLayout({ children }) {
  return (
    <html>
      <body>
        {children}
        <Script src="https://widget.example.com/embed.js" strategy="lazyOnload" />
      </body>
    </html>
  );
}

The strategy prop is where the actual decision happens, and choosing the right one for a given script matters far more than just using next/script at all.

The Strategies, and What They're Actually For

beforeInteractive loads and executes before the page becomes interactive, before hydration. This is reserved for genuinely critical scripts the page cannot function correctly without, a polyfill required for the page to render at all, certain bot detection required before any interaction. Using this for a chat widget or analytics script defeats the entire purpose, it's just as render-blocking as the plain, unmodified <script> tag, applied to something that never needed that priority.

afterInteractive (the default when strategy isn't specified) loads after the page becomes interactive, a reasonable default for most analytics and tracking scripts that need to start running reasonably early but don't need to block initial render.

lazyOnload loads during idle browser time, well after everything else has finished, appropriate for genuinely low-priority scripts, a chat widget, a social media embed, anything a visitor doesn't need in the first few seconds and won't notice arriving slightly later.

Where People Get This Wrong

Using the plain, unmodified <script> tag from a provider's documentation, skipping next/script entirely, which defaults to fully render-blocking behavior in every case, since a plain HTML script tag has no strategy concept at all.

Using next/script but leaving every third-party embed on the default afterInteractive strategy, regardless of actual priority. A genuinely low-priority widget, a review platform badge, a social share button set, sitting on afterInteractive still competes for the browser's attention earlier than it needs to, when lazyOnload would serve it identically from the visitor's perspective while doing measurably less damage to earlier, more important metrics.

Setting beforeInteractive on something that isn't actually critical, sometimes copied directly from an example without understanding what that specific strategy is reserved for. This is the most damaging mistake, since it explicitly requests the most aggressive, most blocking loading behavior available, for a script that almost certainly didn't need it.

A Practical Way to Choose the Right Strategy

Ask honestly, does the page genuinely not function correctly without this script running before anything else. If the honest answer is no, and for the overwhelming majority of third-party embeds it is no, beforeInteractive is off the table. Between afterInteractive and lazyOnload, the real question is whether a visitor would notice or care if this specific widget took an extra second or two to actually appear. If not, lazyOnload is almost always the better choice, genuinely no different from the visitor's perspective, meaningfully better for your actual performance metrics.

Checking Your Own Third-Party Scripts

grep -rn "<script" --include="*.tsx" app/

Any raw <script> tag this turns up, not using next/script at all, is a candidate worth converting. For every existing next/script usage, check whether the strategy actually matches the script's real priority, rather than whatever the default happened to be when it was added.

I audit exactly this on client projects and keep it deliberate across the templates I build at pixelanas.com, since a slow Lighthouse score caused entirely by a chat widget nobody consciously chose to prioritize is one of the more avoidable, easy-to-fix performance issues out there.

The Actual Rule

Every third-party script needs a deliberately chosen loading strategy, not whatever a provider's copy-paste snippet or a framework default happens to apply. beforeInteractive for genuinely critical scripts only, afterInteractive for scripts that need to run reasonably early, lazyOnload for everything else, which, in practice, is most third-party embeds most sites actually use.

If you've got third-party scripts loaded as plain <script> tags, or sitting on a strategy nobody actually chose deliberately, worth auditing them against a real Lighthouse report before and after. 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 default.tsx in a Next.js Parallel Route Can 404 Your Entire Page, Not Just One Slot

Anas Sheikh — Sat, 26 Sep 2026 08:44:48 +0000

This is a genuinely surprising failure mode the first time you hit it, since the natural assumption is that an unmatched parallel route slot would just render nothing, not take down a page that has nothing to do with the slot in question.

The Setup From an Earlier Post, Extended

Building on the intercepting route modal pattern from an earlier post, the @modal slot renders the modal when a specific route is intercepted. But a parallel route slot needs to render something for every URL within its scope, not just the one specific route it was built for.

app/
├── @modal/
│   ├── (.)photo/
│   │   └── [id]/
│   │       └── page.tsx    // renders when a photo route is intercepted
│   └── (missing: default.tsx)
├── photo/
│   └── [id]/
│       └── page.tsx
├── settings/
│   └── page.tsx             // a completely unrelated route
├── layout.tsx
└── page.tsx

Why Visiting an Unrelated Page Can Break Entirely

The @modal slot is defined at the root layout level here, which means it's part of every route rendered under that layout, not just the photo routes it was actually built for. Next.js needs to know what @modal should render for every single route within its scope, including /settings, which has nothing to do with photos or modals at all. If there's no page.tsx inside @modal matching /settings, and critically, no default.tsx file to serve as a fallback for exactly this situation, Next.js has no content to render for that slot on that route, and without a fallback, it treats this as a genuine 404 for the entire page, not just an empty modal slot.

Why This Specific Failure Mode Is So Confusing

The intercepting modal pattern itself works perfectly, clicking a photo from the grid correctly shows the modal, refreshing correctly shows the full page, exactly the behavior covered in the earlier post. The /settings page, something that looks completely unrelated to any of that photo and modal logic, is what actually breaks, with a full 404, and nothing about that page's own code gives any indication why. The actual cause lives entirely in the parallel route configuration at the layout level, several files away from the page that's actually failing, which makes this a genuinely disorienting bug to trace the first time.

The Fix: A default.tsx for Every Parallel Slot

// app/@modal/default.tsx
export default function Default() {
  return null; // this slot simply renders nothing when there's no active modal
}

default.tsx tells Next.js exactly what to render for this slot whenever the current route doesn't match anything more specific within it. Returning null here is completely correct and intentional, for any route that isn't specifically showing a modal, @modal should render nothing, and default.tsx is what makes that an explicit, defined behavior instead of an unhandled gap that produces a full 404.

Why This Is Easy to Miss When First Setting Up Parallel Routes

Most tutorials and examples for intercepting routes focus entirely on the specific route being intercepted, since that's the actual feature being demonstrated, and default.tsx is easy to treat as an afterthought or skip in a quick example, since the demo itself often only ever navigates between the two or three routes that were actually set up correctly. The gap only becomes visible once someone navigates to a genuinely unrelated route that was never part of the original example, exactly the kind of route a real, full application has plenty of.

The Broader Rule

Every parallel route slot needs a default.tsx, without exception, the moment that slot exists anywhere in a layout that also renders routes the slot has no specific content for. This isn't an edge case fallback for rare situations, it's the default, expected behavior for the overwhelming majority of routes in any real application, since a slot built for one specific interaction, a modal, a sidebar variant, is inherently the exception, not the rule, across a site's full set of routes.

Checking Your Own Parallel Routes

find app -type d -name "@*"

For every parallel route slot this turns up, confirm a default.tsx exists directly inside it. If it doesn't, any route within that layout's scope that isn't specifically handled by that slot is at genuine risk of a full 404, not a minor rendering gap, the moment someone actually navigates there.

I set up a default.tsx as the very first file whenever I add a parallel route slot to any project now, client work included, for exactly this reason, it costs one trivial file and prevents a genuinely confusing, hard-to-trace production bug. If you're exploring more Next.js patterns like this, I write about them regularly at pixelanas.com/blog.

If you're using parallel routes anywhere, run the check above right now and confirm every slot has its fallback file. If one doesn't, you've got a real, ready-to-happen 404 waiting on some route you haven't tested yet. 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 useEffect Runs Twice in Development (And Why You Shouldn't "Fix" It)

Anas Sheikh — Fri, 25 Sep 2026 19:59:30 +0000

This causes a very specific, very common reaction, a developer sees a console.log inside useEffect fire twice in the browser console during local development, assumes something's genuinely broken, and starts debugging a bug that doesn't actually exist.

What's Actually Happening

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

export function Tracker() {
  useEffect(() => {
    console.log('Effect ran'); // logs twice in development, once in production
    trackPageView();
  }, []);

  return null;
}

In development, with React's Strict Mode enabled, which the Next.js App Router enables by default, React deliberately mounts a component, runs its effects, unmounts it, and immediately remounts it again, running the effects a second time. This is not a bug, and it's not accidental, it's a specific, intentional development-only behavior designed to help surface exactly the kind of bug this pattern causes in the first place, effects with real, unintended side effects or missing cleanup.

Why React Does This on Purpose

React is preparing for a future where components can be safely paused, discarded, and remounted, for features like offline support and certain rendering optimizations, and that capability genuinely requires effects to be safely re-runnable, mount, unmount, mount again, without producing broken or duplicated behavior. The double-invoke in development is a deliberate stress test, if your effect breaks when run twice in a row, mount, unmount, mount, it's revealing a genuine correctness gap, code that assumes it only ever runs once, which was never actually a safe assumption to begin with, even before Strict Mode made it visible.

Why the Instinct to "Fix" This Is Usually Wrong

Seeing double logs or double network calls in development and reaching for a way to suppress it, disabling Strict Mode entirely, or adding a fragile useRef guard specifically to prevent the second invocation, treats the symptom as the problem. The actual problem, if there is one, is that the effect wasn't written to safely handle being cleaned up and re-run, which is a real gap worth fixing properly, not hiding by preventing Strict Mode from ever revealing it again.

// ❌ A common "fix" that just hides the signal instead of addressing what it revealed
const hasRun = useRef(false);

useEffect(() => {
  if (hasRun.current) return;
  hasRun.current = true;
  trackPageView();
}, []);

This pattern specifically defeats the entire point of Strict Mode's double-invoke check, and worse, it can behave inconsistently across React versions and concurrent rendering scenarios in ways that are genuinely harder to reason about than just writing the effect correctly in the first place.

The Actual Fix: Write Effects That Are Safe to Run Twice

For something like an analytics call, the real question worth asking is whether firing it twice in development actually matters, and for most analytics providers, it doesn't, in production, without Strict Mode's double-invoke, it only fires once anyway. The development-only double log is not the same as double-counting real production analytics data, a distinction worth confirming directly rather than assuming.

useEffect(() => {
  // In production, this fires once. In development, Strict Mode fires it
  // twice, which is expected and does not reflect production behavior.
  trackPageView();
}, []);

For an effect that sets up something genuinely stateful, a subscription, an interval, an event listener, the actual fix is a real, correct cleanup function, which is precisely what Strict Mode's double-invoke is designed to verify you've written:

useEffect(() => {
  const interval = setInterval(() => {
    checkForUpdates();
  }, 5000);

  return () => clearInterval(interval); // correctly cleans up, safe to run twice
}, []);

With a correct cleanup function, the double-invoke in development runs cleanly, set up, tear down, set up again, exactly the pattern Strict Mode exists to confirm your code actually handles safely. If removing the cleanup function causes something to visibly break or duplicate in development, that's Strict Mode doing its job, not React misbehaving.

Where This Actually Matters for Real Bugs, Not Just Console Noise

This connects directly to the stale fetch race condition covered in an earlier post, an effect fetching data without a cleanup function that ignores stale responses is exactly the kind of effect that also breaks under Strict Mode's double-invoke in development, showing a flash of duplicated or incorrect state before settling, which is a genuine, useful early warning for a bug that would otherwise only surface in production under real network timing variance.

The Actual Rule

A useEffect that produces visibly different or broken behavior when Strict Mode runs it twice in development almost always has a real gap, missing or incorrect cleanup, not properly guarding against being re-invoked, that would eventually cause a genuine bug in production too, just under different, harder-to-reproduce conditions. The fix is writing the effect to genuinely handle mount, unmount, remount correctly, not suppressing the specific mechanism designed to reveal that it doesn't.

I keep Strict Mode enabled across every project I build, client work and the templates at pixelanas.com alike, specifically because catching this category of bug in development, as annoying as the double logs are at first, is far cheaper than debugging the same underlying issue once it surfaces as an intermittent, hard-to-reproduce production bug instead.

If you've disabled Strict Mode, or added a ref-based guard specifically to suppress double-invoked effects, worth reconsidering whether that's hiding a real, fixable gap rather than actually solving anything. Drop your own experience with this in the comments.

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

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

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