DEV Community: Shubhra Pokhariya

Next.js 16 Broke My App in 4 Places and None of Them Threw an Error

Shubhra Pokhariya — Wed, 27 May 2026 08:32:54 +0000

The CI was green.

Build passed. No TypeScript errors. No warnings. Everything looked clean. I clicked deploy and went to make tea.

Came back, opened staging, and things were broken in ways that made no sense. A redirect wasn't working. Lint had silently disappeared from the build pipeline. One API route was throwing on the very first real request. And a revalidation call I'd written two weeks earlier was running but doing nothing.

Not one of these showed up during the build. Everything looked completely fine until it wasn't.

This is what actually happened during my Next.js 16 upgrade, and what to check before you ship yours.

1. `middleware.ts` stopped running and told me nothing

My middleware file was fine. It compiled. The export was valid. TypeScript was happy.

After upgrading to Next.js 16, it just stopped running on requests. No error. No deprecation warning. No sign of anything wrong in the terminal. The file was simply ignored.

What happened: Next.js 16 replaced middleware.ts with proxy.ts. Same location in your project. Different filename. Different exported function name.

// Before: middleware.ts
export function middleware(request: NextRequest) {
  return NextResponse.redirect(new URL('/home', request.url))
}

// After: proxy.ts
export function proxy(request: NextRequest) {
  return NextResponse.redirect(new URL('/home', request.url))
}

That's the whole change. File rename, function rename. But because the old file didn't throw anything, I assumed it was still running. I only caught it because a redirect I expected wasn't happening and I spent way too long looking at the wrong thing.

One thing to know: if you need edge runtime behavior specifically, middleware.ts still exists for that use case. In my case, the logic I had there stopped running after the upgrade. Renaming the file and export fixed it immediately. The codemod handles this automatically. But if you manually upgraded the package without running it, or if it missed a file, this one is completely invisible.

Before you ship: rename the file, rename the export, test a route that depends on it.

2. `revalidateTag('products')` compiled, deployed, and silently did the wrong thing

During the migration I wrote this:

revalidateTag('products')

One argument. Totally normal in Next.js 15. I'd written it a couple of weeks earlier and hadn't thought about it since.

In Next.js 16, the single-argument form is deprecated and produces a TypeScript error. But only if your tsconfig is in strict mode. Mine wasn't. It had been set up on an older project years ago and never touched.

So it compiled. It deployed. It ran. And it fell back to legacy invalidation behavior instead of the new SWR-based system. Pages weren't reflecting mutations. No error anywhere, just stale data that I attributed to other things for longer than I should have.

The fix is just adding the second argument:

revalidateTag('products', 'max')          // SWR, the recommended default
revalidateTag('products', { expire: 0 })  // Immediate expiry, for webhooks

The codemod (npx @next/codemod@canary upgrade latest) handles this. But if you wrote any revalidation calls after upgrading, or if the codemod missed a file, check manually.

The real fix is turning on strict mode in your tsconfig. That one change makes this a compile error instead of a silent runtime problem:

{
  "compilerOptions": {
    "strict": true
  }
}

Do it before anything else.

3. `next lint` disappeared and my CI kept saying it passed

This one sounds minor. It wasn't.

next lint is completely removed in Next.js 16. Not deprecated. Not changed. Gone. The eslint option in next.config.ts is also gone. next build no longer runs linting automatically.

My CI was configured to run next lint as a step. After the upgrade, that command no longer existed. Depending on how your CI handles missing commands, it might fail loudly or it might just succeed silently and move on. Mine moved on.

So I was shipping code with no linting running, and the CI was reporting green. I only noticed when an obvious issue slipped through that I expected lint to catch.

The migration is to run ESLint directly:

"scripts": {
  "lint": "eslint .",
  "lint:fix": "eslint . --fix"
}

The codemod creates eslint.config.mjs and updates your package.json scripts. But your CI config is a separate file the codemod does not touch. Check both places.

4. One component was still reading `params` synchronously

The codemod updated most of my pages correctly. But I had a layout file it missed. The component was accessing params directly without awaiting it, which is fine in Next.js 15 but wrong in 16 where params is now a Promise.

// Before — Next.js 15
export default function Layout({ params }: { params: { id: string } }) {
  const id = params.id
}

// After — Next.js 16
export default async function Layout({
  params,
}: {
  params: Promise<{ id: string }>
}) {
  const { id } = await params
}

This one did throw, but only on the first real request to that route in staging, not during the build. The build passed completely clean.

If you have layouts, pages, or route handlers, search the whole codebase for direct params. access and check that every one has been updated. Same goes for searchParams, cookies(), headers(), and draftMode(). All async now, all need awaiting.

The pattern that connects all four

None of these are caching bugs. They're upgrade bugs. The kind where the build passes, the code is technically valid, and the wrong behavior only shows up under a specific condition: a real redirect being triggered, a mutation needing to reflect, a lint issue reaching review, a specific route being hit.

The codemod gets most of this. Run npx @next/codemod@canary upgrade latest before you change anything else. Then check three things manually: grep for any revalidateTag( with a single argument, check your CI config for next lint, and turn on strict TypeScript. Those three cover most of what the codemod can miss.

If you're already past the upgrade and dealing with caching behavior specifically, the previous posts in this series cover that. The debugger I built to make cache behavior visible during development and the seven bugs that compile clean and break silently in production.

I also have a full step-by-step migration guide with before/after comparisons at shubhra.dev/tutorials/nextjs-16-cache-components if you want the complete reference.

Which of these hit you? Or something I didn't mention here?

7 Next.js 16 Caching Bugs That Compile Fine and Break Silently in Production

Shubhra Pokhariya — Thu, 21 May 2026 12:06:06 +0000

I lost hours debugging a Next.js 16 caching issue that had no error, no warning, and only showed up in production.

The Next.js 16 caching model is genuinely good. But it introduces a class of bugs that are harder to detect than anything in previous versions: bugs that look correct, compile without errors, deploy successfully, and then silently misbehave in production.

These are the most common ones I've seen across real projects. Every one comes from real production incidents.

(Assumes you have cacheComponents: true enabled in next.config.ts.)

This is a follow-up to my previous post where I built a dev-only debugger to surface these issues during development. That tool helps you detect them. This post breaks down the exact failure cases behind those warnings.

Bug 1: `'use cache'` on the Wrapper Instead of Inside the Function

// This looks cached. It is not.
export const getProducts = someWrapper(async function() {
  'use cache'
  cacheLife('hours')
  return db.query('SELECT * FROM products')
})

The 'use cache' directive tells the Next.js compiler to treat that function as a cache boundary. When you wrap it, the compiler sees the wrapper as the entry point. The inner function may be cached, but the wrapper becomes the execution boundary, so you still end up running it on every request.

No error. No warning. Just a function running on every request when it should be cached.

Fix:

async function _getProducts() {
  'use cache'
  cacheLife('hours')
  cacheTag('products')
  return db.query('SELECT * FROM products')
}

// Wrapper receives the already-cached function
export const getProducts = someWrapper(_getProducts)

The rule is simple: 'use cache' lives inside the data function, never on anything that wraps it.

Bug 2: Deprecated `revalidateTag` That Compiles and Uses Legacy Behavior

// Next.js 15: correct
// Next.js 16: TypeScript error, silently uses legacy behavior in loose tsconfig
revalidateTag('products')

In Next.js 16, revalidateTag without a second argument is deprecated and produces a TypeScript error. But if your tsconfig is not in strict mode (common in older projects), it compiles cleanly and falls back to legacy invalidation behavior instead of the new SWR-based system.

Pages stop reflecting mutations. No error anywhere.

Fix:

revalidateTag('products', 'max')         // SWR, recommended for most content
revalidateTag('products', { expire: 0 }) // Immediate expiry for webhooks/payments

Run npx @next/codemod@canary upgrade latest during your migration, it handles this automatically. But check your tsconfig strictness regardless.

Bug 3: Tag String Mismatch Across Files

// lib/data.ts -- written by developer A
async function getProducts() {
  'use cache'
  cacheTag('product-list')  // Tag is 'product-list'
  return db.query('...')
}

// app/actions/products.ts -- written by developer B
export async function createProduct(data: ProductData) {
  await db.query('INSERT INTO products ...', [...])
  revalidateTag('products', 'max')  // Different string, invalidates nothing
}

Two different strings. Zero errors. The product list never refreshes after a new product is created. Users see stale data until cacheLife expires on its own.

Fix:

// lib/tags.ts -- one source of truth
export const tags = {
  products: 'product-list',
  product: (id: string) => `product-${id}`,
  user: (id: string) => `user-${id}`,
} as const

// Both files import from tags
cacheTag(tags.products)
revalidateTag(tags.products, 'max')

Tag typos become TypeScript errors. The string mismatch bug becomes structurally impossible.

Bug 4: Server Action Mutation Where the Acting User Sees Stale Data

'use server'
export async function updateProductPrice(id: string, newPrice: number) {
  await db.query('UPDATE products SET price = $1 WHERE id = $2', [newPrice, id])
  revalidateTag(`product-${id}`, 'max')
}

revalidateTag with any named profile uses stale-while-revalidate. It marks the cache as stale. The next request still gets the cached version while fresh data loads in the background.

For the admin who just clicked save, that means they navigate to the product page and see the old price. Looks like the save failed. Causes confusion and duplicate mutations.

Fix:

'use server'
import { revalidateTag, updateTag } from 'next/cache'

export async function updateProductPrice(id: string, newPrice: number) {
  await db.query('UPDATE products SET price = $1 WHERE id = $2', [newPrice, id])
  updateTag(`product-${id}`)            // Acting user sees change immediately
  revalidateTag(`product-${id}`, 'max') // Everyone else gets SWR
  revalidateTag('products', 'max')      // Product list also refreshes
}

updateTag expires the cache entry immediately. The next request waits for fresh data. The admin sees their change. Everyone else gets the fast SWR treatment.

Constraint: updateTag only works inside Server Actions. In Route Handlers, use revalidateTag(tag, { expire: 0 }) instead.

Bug 5: `updateTag` in a Route Handler

// app/api/webhooks/stripe/route.ts
import { updateTag } from 'next/cache'

export async function POST(req: Request) {
  const event = await parseStripeWebhook(req)
  if (event.type === 'price.updated') {
    updateTag('products')  // Throws at runtime
  }
  return new Response('ok', { status: 200 })
}

This compiles. It deploys. On the first real webhook call from Stripe, it throws at runtime. updateTag only works inside Server Actions. Calling it anywhere else throws.

Fix:

import { revalidateTag } from 'next/cache'

export async function POST(req: Request) {
  const event = await parseStripeWebhook(req)
  if (event.type === 'price.updated') {
    revalidateTag('products', { expire: 0 })  // Immediate expiry in Route Handlers
  }
  return new Response('ok', { status: 200 })
}

Bug 6: Short `cacheLife` That Silently Affects PPR

async function LiveStockStatus({ productId }: { productId: string }) {
  'use cache'
  cacheLife('seconds')  // Seems right for live stock data
  cacheTag(`stock-${productId}`)
  return fetchStockLevel(productId)
}

cacheLife('seconds'), revalidate: 0, and expire under 5 minutes are automatically excluded from the PPR static shell. They become dynamic holes that run at request time.

One component with cacheLife('seconds') can push parts of the page out of the static shell and turn them into request-time work. No warning. The page still works. It just becomes fully dynamic without any obvious signal.

Fix, if the data can tolerate a short delay:

cacheLife('minutes')  // Now included in the static shell

Fix, if it genuinely needs to be live:

// Parent page
<Suspense fallback={<StockSkeleton />}>
  <LiveStockStatus productId={id} />  {/* Streams in after static shell */}
</Suspense>

The second approach is the correct PPR pattern for truly dynamic data. The static shell renders instantly and the live data streams in after.

Bug 7: Runtime API Inside a Cached Scope

async function UserHeader() {
  'use cache'
  const cookieStore = await cookies()  // Throws at build time
  const user = await getUser(cookieStore.get('user-id')?.value)
  return <div>{user.name}</div>
}

cookies(), headers(), and draftMode() are runtime APIs. They read request-specific data. They cannot live inside a 'use cache' scope because cached output is stored and replayed across requests.

This one at least throws at build time with "Uncached data was accessed outside of Suspense". But the error gives you no component name, no file path, and no useful stack trace. You get to play binary search across your codebase to find it.

Fix:

// Read runtime values OUTSIDE the cached scope
async function UserHeader() {
  const cookieStore = await cookies()
  const userId = cookieStore.get('user-id')?.value
  return <CachedUserProfile userId={userId} />
}

// Pass the VALUE as a serializable prop to the cached component
async function CachedUserProfile({ userId }: { userId?: string }) {
  'use cache'
  cacheLife('hours')
  cacheTag(`user-${userId}`)
  if (!userId) return <GuestGreeting />
  const user = await getUser(userId)
  return <div>{user.name}</div>
}

userId is a string so it becomes part of the cache key automatically. Different users produce different cache entries without any manual key construction.

The Common Thread

None of these have good error messages. Five of the seven compile and deploy without complaint. The other two throw, but either without enough information to find the cause quickly or only after the first real production request.

The pattern across all of them is the same: the new caching model requires explicit correctness. When you get something wrong, it does not always tell you.

If you are in the middle of a Next.js 16 migration and want to catch these during development rather than in production, I ended up building a free dev-only debugger that logs cache misses, dynamic holes, missing tags, and deprecated invalidation calls directly in your terminal. Zero production cost, one .tsx file: Next.js cache debugger.

And if you want these patterns enforced at the type level so the wrong call is a compile error rather than a runtime surprise, the production enforcement layer is Cache Pro Kit.

Have you run into any of these? Or something even stranger? I'm curious what the distribution looks like across different kinds of projects.

I built a free debugger because Next.js 16 'use cache' was completely invisible during development

Shubhra Pokhariya — Tue, 19 May 2026 10:29:28 +0000

I spent an afternoon debugging a component that kept re-fetching on every single request.

It had 'use cache' right there in the code. I was confident it was working. It wasn't.

The problem was placement. 'use cache' was on the wrapper function, not inside the actual data function. That one mistake makes Next.js ignore the directive entirely. No error, no warning, nothing in the terminal. Just a function running on every request when it should have been cached.

Another time I wrote this in a Server Action during a Next.js 16 migration:

revalidateTag('products')

It compiled. It deployed. Pages stopped reflecting mutations. Calling revalidateTag without a second argument is a TypeScript error in Next.js 16, but the runtime fell back to legacy behaviour silently. I only caught it when users started reporting stale data.

Next.js 16's new caching model is genuinely great. But during development it is a complete black box. You add the directive, you assume it works, and you only find out otherwise when something breaks in production.

So I built a small dev-only toolkit to make it visible.

What it catches

1. Silent cache misses

If a function runs more than once with identical arguments, you see this immediately:

[cache-debug] ⚠  POSSIBLE CACHE MISS - RE-EXECUTION WITH SAME ARGS
  fn:   getProductById
  args: ["prod-123"]
  This function ran 2 times with identical args.
  If you expect caching: check 'use cache' is inside this function, not the wrapper.

That warning would have saved me that entire afternoon.

2. Dynamic holes from short cacheLife

cacheLife('seconds') silently excludes a component from the PPR static shell. It becomes fully dynamic. No warning anywhere, just a slower page that you cannot explain.

[cache-debug] ⚡ DYNAMIC HOLE WARNING
  fn:       getLivePrice
  cacheLife 'seconds' is short-lived (< 5 minutes or revalidate: 0).
  Next.js 16 automatically EXCLUDES this from the PPR static shell.
  This function will run at request time, it is NOT prerendered.
  Fix: Use 'minutes' or longer if you want it in the static shell.

3. Missing cacheTag

A cached function with no cacheTag() can only expire by time. You cannot revalidate it on demand. Easy to miss when moving fast, painful to discover later.

[cache-debug] 🏷  MISSING cacheTag WARNING
  fn:   getProductById
  No cacheTag() found. This function cannot be invalidated on demand.
  It will only expire when cacheLife runs out.
  Fix: Add cacheTag('your-tag') inside the function.

4. Deprecated revalidateTag

In Next.js 16, revalidateTag('tag') without a second argument is a TypeScript error. The logInvalidation helper catches it before your CI does:

[cache-debug] ✗  DEPRECATED revalidateTag - MISSING SECOND ARG
  tag:     products
  revalidateTag('products') without a profile is deprecated in Next.js 16.
  Fix: revalidateTag('products', 'max')

5. updateTag outside a Server Action

Calling updateTag outside a Server Action throws at runtime. The toolkit catches it at dev time before it reaches production.

6. Repeated fetches

detectRepeatedFetch surfaces the same URL being hit multiple times in one render. Usually means a cache layer is missing entirely.

How to use it

Step 1: Enable in .env.local

CACHE_DEBUG=true

Do not add this to .env.production. The NODE_ENV guard already ensures it is off in production, but keeping env files clean is good practice.

Step 2: Wrap your cached functions

The 'use cache' directive must stay inside the original function. withCacheDebug is a regular wrapper and cannot be a cache boundary. If you put 'use cache' on the wrapper, the instrumentation gets cached instead of the data function, which is exactly the mistake the POSSIBLE CACHE MISS warning is designed to catch.

import { cacheLife, cacheTag } from "next/cache";
import { withCacheDebug } from "@/lib/cache-debug";

async function _getProductById(id: string) {
  "use cache";
  cacheLife("hours");
  cacheTag(`product-${id}`, "products");
  return db.query("SELECT * FROM products WHERE id = $1", [id]);
}

export const getProductById = withCacheDebug(_getProductById, {
  name: "getProductById",
  cacheLife: "hours",
  tags: ["product-{id}", "products"],
});

const product = await getProductById("prod-123");

Zero API change. The exported function works exactly the same everywhere you already call it.

Step 3: Log invalidation calls in Server Actions

"use server";
import { revalidateTag, updateTag } from "next/cache";
import { logInvalidation } from "@/lib/cache-debug";

export async function updateProductPrice(id: string, newPrice: number) {
  await db.query("UPDATE products SET price = $1 WHERE id = $2", [newPrice, id]);

  logInvalidation("updateTag", `product-${id}`, {
    isServerAction: true,
    context: "admin price update",
  });
  updateTag(`product-${id}`);

  logInvalidation("revalidateTag", "products", {
    profile: "max",
    isServerAction: true,
    context: "admin price update",
  });
  revalidateTag("products", "max");
}

Honest limitations

Process-scoped. Execution maps reset on cold start. In serverless environments each invocation may be a fresh process, so you will only see re-execution data within the same warm instance. For local dev with a long-running server it works exactly as intended.
Best-effort concurrency. Under concurrent rendering with identical args, both calls may log FIRST RUN rather than a miss. Detection does not affect correctness.
Cannot inspect Next.js internals. The debugger counts executions to detect likely misses. It cannot read Next.js's internal cache store directly.

None of these affect production because the tool is not present there.

At a glance

What it detects	Without this tool
FIRST RUN / CACHE MISS / NEW KEY	Not visible
Dynamic hole from short cacheLife	Not visible
Missing cacheTag	Not visible
Deprecated revalidateTag	TypeScript error, easy to miss
updateTag outside Server Action	Runtime throw
Repeated fetches in one render	Not visible

Zero external dependencies. TypeScript 5.0+ with strict mode. Next.js 16 only -- updateTag does not exist in Next.js 15. Double-gated on NODE_ENV === 'development' AND CACHE_DEBUG=true so nothing ships to production. No overhead, no bundle impact.

Get it

Free forever, one .tsx file: shubhra.dev/snippets/nextjs-use-cache-debugger

If you want the production enforcement layer that pairs with this -- type-safe tag registry, safeRevalidate that blocks the deprecated single-arg call at compile time, serverActionInvalidate that enforces the correct invalidation order -- that is the Cache Pro Kit.

If you are new to the Next.js 16 caching model and want to understand what 'use cache', cacheLife, and cacheTag are actually doing before using this toolkit, the practical migration guide covers the full picture. There is also a 15-question quiz if you want to test your understanding.

If you are in the middle of a Next.js 16 caching migration and something is behaving unexpectedly, this will make it visible. What has been the most frustrating or confusing part of the new caching model for you?

Lighthouse Said It Was Fast. My Users Kept Clicking the Same Button.

Shubhra Pokhariya — Wed, 06 May 2026 09:46:33 +0000

The bug wasn’t performance. It was silence.

I ran into this while building a Next.js dashboard.

There was a button that triggered a report generation flow. Some client-side processing, then an API call.

Lighthouse looked great. API response was around 80ms.

But session recordings told a different story.

Users were clicking the button 3 to 5 times in a row.

No errors in logs. No failed requests. Everything technically worked.

So I watched one of the recordings more carefully.

The moment the user clicked, nothing changed on screen.

No loading state.
No disabled button.
No visual feedback at all.

The UI looked exactly the same before and after the click.

That was the issue.

80ms response, zero perceived response

The backend was fast.

The interface just didn’t acknowledge the interaction.

From the user’s point of view, the click didn’t go through.

So they clicked again.

And again.

Not because they were impatient. Because the UI stayed silent.

Where most of us focus (and where it falls short)

We spend a lot of time optimizing load performance.

FCP, LCP, bundle size, Lighthouse scores. All worth caring about.

But most of the time a user spends on your app happens after the page has loaded.

That’s where trust is decided. In the interactions.

The 200ms line

There’s a threshold that shows up consistently in real usage.

If the UI responds within roughly 100 to 200ms, it feels instant.

Between 200 and 500ms, the delay becomes noticeable.

Beyond that, people start questioning whether their action worked.

A slow app is frustrating. An app that feels unresponsive gets abandoned.

What INP actually measures

INP (Interaction to Next Paint) focuses on one thing:

How long it takes for the user to see a response after they interact.

Not when your API returns.
Not when your function finishes.

When something visibly changes on the screen.

That’s what closes the loop.

The fix was not “make it faster”

The fix was: acknowledge the interaction immediately.

Instead of doing all the work first:

button.addEventListener("click", async () => {
  await processData();
  await syncWithServer();
  setLoading(false);
});

Flip it:

button.addEventListener("click", async () => {
  setLoading(true); // immediate visual feedback

  await scheduler.yield(); // let the browser paint

  await processData();
  await scheduler.yield();

  await syncWithServer();

  setLoading(false);
});

If scheduler.yield() is not available yet in your environment, a simple fallback works:

const yieldToMain = () => new Promise((r) => setTimeout(r, 0));

Same total work. Same total time.

Completely different experience.

Users stopped clicking multiple times.

The pattern you already use

You’ve seen this in every modern app.

You tap like. It updates instantly. The server confirms later.

That’s optimistic UI.

Here is the same idea in a simple form:

async function handleLike(postId) {
  setLiked(true);
  setCount((c) => c + 1);

  try {
    await api.like(postId);
  } catch {
    setLiked(false);
    setCount((c) => c - 1);
  }
}

In React and Next.js setups, this maps cleanly to useOptimistic and Server Actions.

The idea stays the same:

Show the result immediately. Reconcile in the background.

Why this matters more than Lighthouse 100

Lighthouse runs in controlled conditions.

Your users don’t.

They’re on slower devices, switching tabs, running background apps, dealing with network jitter.

You can ship a perfect score and still have interactions that feel off.

INP exposes that gap.

If you want to go deeper

This bug was the entry point for me.

I ended up breaking this down properly across INP, optimistic UI, task yielding, and how this fits into modern Next.js setups like Server Actions and streaming.

I wrote it up in detail here:
https://shubhra.dev/tutorials/performance-first-ui-mastery-guide-2026

That one goes deeper into how to actually implement this in real apps. This post is just the moment where the problem becomes obvious.

A quick way to test this

While working through this, I built a small quiz to check if I actually understood the idea or was just agreeing with it.

Here’s one of the questions:

A user clicks a button.
The server responds in 80ms.
They click four more times.

What actually failed?

Most people still go to backend performance first.

If that was your instinct too, you’ll probably find the rest useful:

https://shubhra.dev/quiz/performance-first-ui

It’s short. Focused on real interaction problems. No trick questions.

One practical takeaway

Next time you write a click handler, check the order:

Does something change on screen immediately?
Or does all the work happen before the user sees anything?

That one decision is often the difference between a UI that feels fast and one that feels broken.

If you’ve run into this in your own apps, I’m curious what caused it and how you approached it.

Why Most React Infinite Scroll Hooks Fail in Production (and the One That Fixed It for Me)

Shubhra Pokhariya — Thu, 30 Apr 2026 11:28:52 +0000

I used to believe infinite scroll was one of the simplest features to implement.

Fetch data → append to a list → load more on scroll.

Easy, right?

That’s exactly how most tutorials show it.

And honestly… it works.

Until it doesn’t.

The Bug That Changed Everything

One bug completely changed how I think about infinite scroll.

A user changed a filter → the list reset → new data loaded.

Everything looked correct.

Then a couple of seconds later…

the old results came back and overwrote the new ones.

No errors. No warnings.

Just silently broken UI.

What actually happened?

A slow request from the previous state finished late and updated the UI with stale data.

That was the moment I realized:

Infinite scroll doesn’t break in demos.It breaks with real users, real timing, and real networks.

Where Things Start Falling Apart

After that, I started noticing the same issues again and again:

Stale requests overwriting fresh data after reset
Retry logic fetching the wrong page
IntersectionObserver continuing to fire after errors
Duplicate requests in React Strict Mode
Loading states that never resolve

These problems rarely show up locally.

But in production, they show up fast.

What I Actually Needed

Not another demo.

Something I could trust in a real app.

So I built a hook around one idea:

Control the async flow. Don’t just “load more data”

What This Hook Handles

✔ Cancels stale requests (no overwrite bugs)
✔ Smart retry logic (correct page every time)
✔ Proper observer cleanup (no leaks)
✔ React 18+ Strict Mode safe
✔ Clear initial vs pagination loading states
✔ Manual loadMore, reset, and retry
✔ Zero dependencies

Basic Usage

const {
  items,
  isInitialLoading,
  hasMore,
  error,
  loadMoreRef,
  retry,
  reset
} = useInfiniteScroll({
  fetchFn: async (page, signal) => {
    const res = await fetch(`/api/posts?page=${page}`, { signal });
    return res.json();
  },
  pageSize: 20,
});
return (
  <div>
    <ul>
      {items.map((item) => (
        <li key={item.id}>{item.title}</li>
      ))}
    </ul>

    {/* Sentinel element */}
    <div ref={loadMoreRef} />

    {error && <button onClick={retry}>Retry</button>}
  </div>
);

Real Use Case: Reset on Filter Change

This is where most bugs happen.

useEffect(() => {
  reset(); // cancels old request + reloads safely
}, [filter]);

Without proper handling, this is exactly where stale data bugs appear.

Why AbortController Matters So Much

Before using it:

old requests still resolved
stale data overwrote the UI

After using it:

old requests get cancelled immediately
they never reach your state

That single change removes an entire class of bugs.

One Honest Note

This hook handles most real-world issues.

But for very large lists, you should still use virtualization
(like react-window or tanstack/virtual).

Infinite scroll solves loading.

Virtualization solves rendering.

Try It Yourself

You can grab the full hook here:

👉 https://shubhra.dev/snippets/use-infinite-scroll

MIT licensed
free to copy and modify
built for real production cases

Final Thought

I didn’t build this because infinite scroll is hard.

I built it because the small edge cases are what break real products.

Slow APIs. Fast users. Overlapping requests.

That’s where things actually fall apart.

Curious - what broke for you?

Have you ever hit a weird infinite scroll bug in production?

Something like:

duplicate data
stale UI
loading that never stops

Would genuinely love to hear what you ran into.

I Turned My Blog Into a Full Developer Platform (Tutorials + Snippets + Quizzes + Tools)

Shubhra Pokhariya — Tue, 28 Apr 2026 12:25:37 +0000

I’ve been working on building a developer platform with tutorials, reusable code snippets, interactive quizzes, and practical tools. This post shares what changed and what I’m building now.

For the past few months, I’ve been a little quiet here.

If you’ve been active on Dev.to regularly, you probably noticed I wasn’t reading as many posts, commenting, or sharing like I used to. And honestly, I missed that.

This community has always been one of my favorite places to learn and grow. Reading how others think, build, and solve problems has helped me a lot in my own journey.

So stepping away from that wasn’t easy.

Why I Went Quiet

I reached a point where I felt like just writing blog posts wasn’t enough for me anymore.

Don’t get me wrong, I still love writing. But I kept thinking:

What if I could make something more useful than just articles?

Something that helps people not only read, but also:

try things quickly
test their understanding
and actually use code in real projects

That idea stayed in my mind for a while.

And instead of talking about it, I decided to just build it.

What I’ve Been Working On

I took my simple blog and slowly turned it into something more complete.

Now it’s not just posts. It includes:

Tutorials that go step by step

Here’s how one of the tutorials looks:

Small, practical code snippets you can directly use

A quick example of a reusable snippet in action:

Quizzes to test concepts in a quick way

Here’s a quick look at how the quiz works:

Here’s a small taste of what the quizzes look like:

1. What does the === operator do?

Checks for value equality only
Checks for reference equality only
Checks for both value and type equality without coercion
Assigns a value

→ Correct answer: Checks for both value and type equality without coercion

2. What is a closure in JavaScript?

A way to immediately end a function
A function that retains access to its outer scope
A syntax error
A loop

→ Correct answer: A function that retains access to its outer scope

3. What will typeof null return?

'null'
'undefined'
'object'
'number'

→ Correct answer: 'object'

A couple of products built from things I personally needed

It’s still growing, still improving, and definitely not perfect.

But it feels closer to what I actually wanted to create.

What Changed for Me

Earlier, I was mostly focused on sharing information.

Now I’m trying to focus more on usefulness.

Instead of just explaining things, I want to:

make it easier to apply them
keep things simple and practical
and help someone save time when they’re stuck

Even the smallest snippet can be helpful if it solves a real problem.

I Missed This Community

One thing I realized during this time is how much I value this space.

Reading posts here, seeing different approaches, and learning from others is something I genuinely enjoy.

I missed that part.

So I’m coming back, not just to share, but also to read, learn, and engage again.

What You’ll See From Me Now

I’ll start sharing more regularly again, but with a slightly different approach.

You’ll see things like:

small useful snippets
short explanations
occasional deep tutorials
and some interesting questions or quizzes

Nothing too heavy. Just practical and helpful.

If You Want to Check What I Built

Here’s how everything comes together:

If you’re curious, you can take a look here:

https://shubhra.dev/

No pressure at all. Just sharing what I’ve been working on.

One Small Thought

Sometimes we feel like we need to keep posting consistently no matter what.

But taking a step back to build something meaningful can be just as important.

For me, this phase helped me rethink what I actually want to create and share.

And I’m glad I took that time.

I’m looking forward to reading your posts again and being more active here.

If you’ve been working on something quietly too, I’d love to hear about it.

Performance First UI Taught Me More Than Any Framework Ever Did

Shubhra Pokhariya — Mon, 12 Jan 2026 10:40:43 +0000

The slowest app I ever worked on had a perfect performance score.

That sentence used to confuse me.

Everything was optimized. Bundles were trimmed. Images were compressed. Lighthouse smiled back at me like a proud teacher.

And yet, users kept behaving strangely.

They clicked twice.

They hesitated.

They abandoned flows halfway through.

At first, I blamed users. Then devices. Then networks.

Eventually, I blamed myself.

That was the moment I started understanding performance first UI.

Speed is not what developers think it is

As developers, we grow up believing speed is a number.

Milliseconds.

Scores.

Graphs.

But users never see numbers. They feel moments.

The moment after a click.

The moment after a tap.

The moment when they expect acknowledgment.

If nothing happens in that moment, something breaks not technically, but emotionally.

The day I stopped trusting Lighthouse alone

Lighthouse is useful. It taught an entire generation to care about performance.

But in 2026, relying on Lighthouse alone is like judging a car by how fast it accelerates on an empty track.

Real users drive in traffic.

They scroll while data loads.

They click while JavaScript executes.

They type while hydration finishes.

That’s where performance first UI lives, not at load time, but during interaction.

Interaction is the real contract with the user

A page load is an introduction.

An interaction is a promise.

When a user clicks a button, they are not asking for data. They are asking for reassurance.

Did you hear me?

Are you working?

Can I trust you?

If your interface stays visually silent, the promise is broken.

Why Interaction to Next Paint quietly changed everything

Interaction to Next Paint does something rare in web metrics.

It measures reality.

Not when logic finishes.

Not when promises resolve.

But when pixels change.

This sounds obvious, but it reframes how you write UI code.

Because suddenly, doing work before paint feels dangerous.

If this shift in thinking around Interaction to Next Paint resonated with you, I’ve explored it in much more depth in my long-form guide Performance First UI Mastery: A Critical Guide for 2026 Developers, where I break down real-world examples, beginner-to-advanced concepts, and how this mindset plays out in modern Next.js apps.

The hidden enemy of modern interfaces

Most INP problems are not caused by slow servers.

They are caused by good intentions.

Too much logic inside event handlers
Too many state updates
Too many components reacting at once

Everything works. Everything is correct. Everything is just slightly late.

And that slight lateness compounds.

The small habit that fixed most of my issues

The biggest improvement I ever made to interaction performance was embarrassingly simple.

I stopped doing real work before showing feedback.

Instead of:

Click → compute → update UI

I switched to:

Click → update UI → compute

Nothing fancy. No new libraries.

Just respect for the paint cycle.

Why modern Next.js makes this mindset possible

Next.js quietly evolved alongside performance first UI thinking.

Partial Prerendering lets interfaces appear ready before they are complete.
Streaming lets content arrive without blocking interaction.
Server Actions let the UI move first and confirm later.
Edge Middleware removes entire decision trees from the client.

Used correctly, these tools keep the browser free to respond.

Performance is not about doing less, it’s about doing things later

This was a hard lesson for me.

I used to chase minimalism. Fewer features. Smaller bundles.

But performance first UI taught me something better.

You can do a lot, just not all at once.

Defer what the user cannot see.

Delay what the user does not care about yet.

Focus on what the user just did.

The business side developers rarely talk about

Here’s an uncomfortable truth.

A sluggish interaction costs more than a slow page load.

Because interaction delay happens when the user is already invested.

They clicked.

They intended.

They were ready.

Losing them here hurts conversion far more than a slow landing page.

Performance is becoming a human skill again

In 2026, AI can generate components.

AI can refactor code.

AI can optimize assets.

But AI cannot feel hesitation.

It cannot sense when a transition feels awkward.

It cannot sense when feedback arrives too late.

That sensitivity is now the developer’s real value.

What performance first UI actually demands from us

It demands patience.

It demands that we observe our own interfaces instead of trusting dashboards.

It demands that we click our own buttons slowly and ask:

Does this feel respectful?

Not impressive.

Not clever.

Respectful.

Final thought

Performance first UI is not a trend. It is a correction.

A return to building software that listens.

If your UI responds instantly, users forgive imperfections.

If it hesitates, they remember.

In the end, performance is not about speed.

It is about trust.

How CSS Animation Helped Me Build Interfaces That Feel Alive

Shubhra Pokhariya — Mon, 22 Dec 2025 06:24:42 +0000

I always believed great UI was about color, spacing, structure, and typography. I spent years improving those things. I obsessed over grids. I experimented with type scales. I rewrote layout systems again and again.

Yet something still felt missing.

Every interface I created worked perfectly, but emotionally it felt silent. It behaved like a machine. Nothing moved unless a page refreshed. Nothing acknowledged the user. I did not realize how empty that silence was until I compared my projects with modern interfaces around the web.

Some apps felt warm and alive, even though their layouts were simple. Their buttons breathed. Their cards shifted gently when hovered. Even status messages faded in and out like they had personality.

I kept asking myself

How are they doing that?

That question pushed me toward CSS Animation.

Not as a design trend
but as a missing piece of expression.

My First Real Encounter With Motion

My turning point arrived inside a dashboard project. Everything looked clean and minimal. The data tables worked. The navigation was solid. The code was tidy.

But the experience lacked a pulse.

One evening while polishing the UI, I decided to animate only a single button. Not to impress anyone, but to understand how it would feel. I added a soft hover lift and a clearer color transition. Nothing dramatic.

The moment I refreshed the browser
the UI reacted like it suddenly woke up.

The button rose slightly.

The shadow deepened.

It felt like the interface acknowledged me.

It was such a small change that the code barely filled a few lines, and yet the product felt more professional instantly.

That tiny success completely changed how I saw CSS Animation.

Why Motion Matters To Users

Modern users expect movement even if they cannot explain why.

Motion tells the brain something is happening.

It guides attention with subtle cues.

It communicates structure faster than text.

When a button lifts
you know it is clickable.

When content fades gently
you understand that something changed without reading anything.

Motion replaces confusion with instinct.

Once I understood that, I saw animation everywhere:

apps, websites, mobile UI, operating systems, ecommerce stores.

Motion has become the language of modern interaction.

CSS Animation Is Not Just Decoration

Before learning it deeply, I believed animation was fancy.

I assumed it slowed pages down.

I thought it was extra work for no real benefit.

All of that was wrong.

CSS Animation can improve usability in extremely practical ways:

Guiding users to the next step
Confirming they clicked something
Building visual rhythm
Reducing visual shock
Improving brand identity
Creating focus without clutter

Motion is not frosting on top of UI. It is part of UI itself.

The Mindset Shift That Helped Me Learn Faster

The biggest challenge was learning how to think about motion.

I stopped asking How do I make this look cool?

and started asking What should the user feel here?

When they open a page, maybe they should feel welcomed.

When they press save, maybe they should feel confirmed.

When they hover over content, maybe they should feel engaged.

That mindset turned animation into storytelling.

Why CSS Animation Works So Well With Modern UI

CSS Animation is not heavy, nor complicated, nor dependent on JavaScript.

It is built to run smoothly if you animate the right properties.

Transforms and opacity create GPU-powered motion that feels fluid even on average devices.

The more I practiced, the more confident I became because I saw that animation can stay clean and fast when done with purpose.

The Most Surprising Part

Clients noticed the improvements immediately.

They could not describe what changed in technical language,

but they kept saying the same thing -
"This feels better.",

Not This looks better, but This feels better.
That sentence taught me something powerful:

Users care about feeling, not code.

A New Way Of Seeing My Projects

Today I build interfaces very differently.

I do not start by applying motion everywhere.

I begin by searching for moments where the UI speaks to users.
Moments that deserve attention, and moments that need softness.

Sometimes it is a card hover.

Sometimes it is a hero title reveal.

Sometimes it is a form success message.

Motion is now part of my design decisions, not an afterthought.

Want To Learn How I Apply CSS Animation To Real UI

I recently wrote a deep story and breakdown on my blog showing how CSS Animation reshaped my understanding of UI feeling and movement.

You can read it here:

👉 https://blog.shubhra.dev/css-animation-level-up-ui

If you are a developer who wants your UI to feel more human, this will help you see animation differently.

Final Thought

The moment you experience your first animated interaction that feels natural, not flashy, you understand why motion matters.

CSS Animation is not only a visual tool, it is emotional design.

And once you learn it, you never see UI the same way again.

The CSS Positioning Chaos: Why Your Elements Run Away (And How I Finally Mastered the 5 Keys)

Shubhra Pokhariya — Fri, 28 Nov 2025 07:54:55 +0000

There is a special kind of chaos that only frontend developers understand.

The kind where your layout looks perfect one second and then suddenly one button escapes to the top corner of the screen like it has its own dreams and ambitions.

That chaos usually has a name: CSS Positioning.

Every developer goes through this phase.

Every beginner gets confused.

And honestly, even after years of working with CSS, I still smile whenever someone asks me:

“Why does my element move when I scroll?”

Because that question reminds me of my own journey, a journey full of tiny mistakes, confused evenings, and small victories that made CSS feel less like a puzzle and more like a friend.

Recently, I wrote a full blog post on my main site where I broke down CSS Positioning in the simplest, most practical way I could.

Today I wanted to share a little behind the scenes of that post and also explain why CSS Positioning deserves more love than it gets.

The Phase Where CSS Positioning Made Me Doubt My Career Choices

Let me tell you something honestly.

In my early days of coding, nothing confused me more than absolute and relative.

I remember placing a badge inside a hero section and the moment I refreshed the page, it flew somewhere completely unrelated.

I thought I broke the browser. I even restarted my laptop once thinking something was wrong with VS Code.

Little did I know it was just CSS Positioning doing its usual drama.

static was too simple
relative felt too subtle
absolute felt too free
fixed felt too stubborn
sticky felt like magic

And because I did not understand their personalities, I kept fighting them instead of letting them help me.

It took me weeks to finally understand that CSS Positioning is not just about moving elements around.

It is about understanding how the browser thinks.

How it calculates boundaries.

How it decides the containing block.

How each element follows a very logical set of rules.

Once I understood this, the fear disappeared.

And CSS started feeling like a superpower.

The Beauty Behind Understanding CSS Positioning

When you truly understand CSS Positioning, you begin to see your layout differently.

Static becomes your calm baseline.
Relative becomes your gentle adjustment tool.
Absolute becomes the creative freedom you use when you want elements to float exactly where you want.
Fixed becomes your loyal companion for floating buttons and sticky helpers.
Sticky becomes the modern magic that makes long pages feel smoother.

The moment you master these five:

your designs stop breaking
your elements stop running away
and your confidence grows instantly

This is why CSS Positioning is not just a “topic” — it is a core foundation that every modern frontend layout quietly depends on.

The Best Way To Learn CSS Positioning Is Not Memorizing It

One of the main things I shared in my WordPress post is something simple but important:

CSS Positioning is not learned through memorization.

It is learned through experience.

You learn it by:

building small boxes
adding a badge
scrolling a page
trying absolute without relative
trying sticky inside a tiny container
placing a button with fixed
and observing every single behavior

This hands‑on curiosity is what transforms CSS Positioning from confusing to intuitive.

And once it clicks, you will wonder how you ever struggled with it.

Why This Topic Deserves More Attention

We often jump directly into Flexbox, Grid, animations, Tailwind, frameworks, and component libraries.

But behind all of them, positioning still plays a silent role.

The moment something goes wrong,

the moment a layout shifts,

the moment an element overlaps,

the moment a menu disappears,

we all return to the same root question:

“Where is this element positioned, and relative to what?”

Understanding CSS Positioning early saves so much frustration later.

Final Thoughts

CSS Positioning is not scary.

It is simply misunderstood.

And once you understand how these five values behave, you will start designing with more confidence, clarity, and creativity.

Whether you are:

a beginner trying to place a small badge
a student building a landing page
or someone revisiting fundamentals after years

CSS Positioning is one of those topics that rewards you every time you give it attention.

If you want the full detailed breakdown, the real examples, and the step‑by‑step mental model, check out my complete WordPress guide:

👉 CSS Positioning: The 5 Keys to Master Static, Relative, Absolute, Fixed, Sticky

How CSS Grid Changed the Way I Build Web Layouts

Shubhra Pokhariya — Fri, 21 Nov 2025 08:36:47 +0000

I remember the first time I tried building a multi-section landing page. Everything seemed fine until I had to align cards, features, and hero sections across different screen sizes. Flexbox was great, it helped me align items neatly along a row or a column. Buttons were easy to center, cards aligned without stress, and navigation bars looked clean. But when it came to arranging rows and columns simultaneously, I felt like I was juggling invisible boxes.

At that point, I realized that while Flexbox is incredibly useful, it wasn’t enough for some layouts I wanted to build. That’s when I discovered CSS Grid, and it felt like a whole new world opened up. Suddenly, I could control both rows and columns, manage spacing effortlessly, and create layouts that scaled beautifully on different devices. Unlike Flexbox, which works one direction at a time, Grid lets you think of your layout in two dimensions, like designing a chessboard where each piece has its own space, but the whole board adapts as needed.

Why CSS Grid Matters

CSS Grid isn’t just a new layout tool. it’s a paradigm shift in how we approach web design. Here are a few reasons why I love using it:

Two-Dimensional Control – With Grid, you can define both rows and columns simultaneously. This makes complex layouts much simpler than using multiple Flexbox wrappers.
Simpler Responsiveness – Media queries, auto-fit, and minmax make responsive design feel natural. You define the structure once, and it adapts gracefully across devices.
Cleaner Code – Less nested markup, fewer hacky margins, and more maintainable CSS. Your code feels organized, and it’s easier for others (or future you) to understand.
Flexible Combinations – Grid and Flexbox aren’t competitors. I often use Grid to structure sections and Flexbox inside grid items for precise alignment.

Think of Flexbox as a Swiss Army knife, perfect for one-dimensional tasks. CSS Grid is more like a blueprint: it plans the structure of your entire layout. And when you combine them, building even complex sections becomes surprisingly intuitive.

Breaking Down the Basics

Before diving into full layouts, it’s helpful to understand the building blocks:

Grid Container – Turn any parent container into a grid by setting display: grid. Everything inside becomes a grid item automatically.
Grid Items – Direct children of the container that you can place and size using Grid properties.
Grid Template Columns – Define how many columns your grid will have and their proportions. For example:

.container {
  display: grid;
  grid-template-columns: repeat(3, 1fr);
}

Gap – Replace manual margins with gap for both rows and columns.

.container {
  gap: 20px;
}

Fraction Units (fr) – Divide space proportionally. For example, 1fr 2fr gives the first column 1 part and the second column 2 parts.

Auto-Fit & Auto-Fill – Make responsive columns that adjust automatically depending on available space.

Once you understand these fundamentals, you can start building layouts that scale across devices without headaches.

My First Real Project

When I tried my first product grid, I was amazed at how effortless it felt. Previously, I’d spend hours tweaking margins and floats to make cards line up evenly. With CSS Grid:

.products {
  display: grid;
  grid-template-columns: repeat(auto-fit, minmax(250px, 1fr));
  gap: 30px;
}

Even with varying content lengths, everything stayed aligned beautifully. Adding hover effects, card spacing, and images became smooth and predictable. I realized I could build dashboards, landing pages, and product sections without overcomplicating the markup.

Making it Fully Responsive

Responsive design used to be the part I dreaded. CSS Grid made it easy:

@media (max-width: 1024px) {
  .grid {
    grid-template-columns: repeat(2, 1fr);
  }
}

@media (max-width: 600px) {
  .grid {
    grid-template-columns: 1fr;
  }
}

With a few media queries, the layout automatically collapses to fit tablets and mobile screens. No extra wrappers, no messy margin hacks, no complicated nesting. Just clean, intuitive, and flexible layouts.

Beyond the Basics

Once I mastered the fundamentals, I started experimenting:

Nested Grids – Perfect for dashboards or multi-section layouts.
Hero Sections – Divide the screen visually between text and imagery, all fully responsive.
Aligning Items – Centering, stretching, and fine-tuning placement is straightforward with justify-items and align-items.
One of my favorite things is combining Grid and Flexbox. For example, using Flexbox inside a Grid card keeps buttons, icons, and text perfectly aligned without extra CSS gymnastics.

Lessons I Learned While Mastering CSS Grid

When I first started experimenting with CSS Grid, I made some mistakes that slowed me down. These are things I wish I knew from the start:

Not declaring the grid container properly – Sometimes I’d forget display: grid, and nothing seemed to work.
Rigid column widths – Using fixed pixels made layouts brittle, especially on mobile screens. Switching to flexible fractions (fr) solved this instantly.
Too many nested grids too soon – I tried to nest grids for every tiny section, which made the code messy and hard to debug.
Skipping mobile testing – A layout may look perfect on desktop but break completely on smaller screens if you don’t check.
Not thinking about combining Flexbox – Some elements inside a grid need precise alignment. Using Flexbox inside a grid item is a game-changer.

Learning from these mistakes helped me write cleaner, more maintainable code and made creating responsive layouts much faster.

Flexbox and CSS Grid: How I Use Them Together

I often get asked: Should I stick to Flexbox or switch entirely to Grid?

Here’s how I see it now:

Flexbox is perfect when you’re dealing with a single row or column. Think navbars, simple card layouts, or aligning buttons, anywhere you need to align elements along one direction.
CSS Grid shines when you need two-dimensional control,rows and columns simultaneously. Dashboards, product sections, or multi-part landing pages are great examples.

The trick is not to see them as competitors. I often structure the page using Grid for the main layout and then use Flexbox inside specific grid items to align content perfectly. This combination saves time and keeps layouts consistent across devices.

Where to Go From Here

If you want a practical, step-by-step guide with real-life examples, screenshots, and fully explained techniques, I’ve written a complete blog post that goes deep into CSS Grid. It covers everything from simple product grids to advanced layouts, nested grids, auto-fit/minmax, and more.

You can check out the full guide here: CSS Grid Responsive Layouts Made Easy: A Complete Guide

Takeaways

CSS Grid transforms the way you build web layouts, making complex designs intuitive and manageable.
Combine Grid and Flexbox to get the best of both worlds.
Start small, experiment with product sections or hero layouts, then gradually explore nested grids and advanced properties.

If you’ve ever struggled with alignment, responsiveness, or messy layouts, CSS Grid can be a game-changer. And with a little practice, it’ll feel natural, clean, and even enjoyable to work with.

Understanding Flexbox: A Beginner’s Journey to Perfect CSS Alignment

Shubhra Pokhariya — Mon, 10 Nov 2025 10:53:28 +0000

I still remember the day I met Flexbox.

Not the “oh wow this is cool” kind of meeting, but the “why is nothing aligning right?!” kind.
My divs were misbehaving, my buttons refused to center, and I had started questioning every life choice that led me to CSS.

That was the moment I realized:

understanding Flexbox isn’t about memorizing properties, it’s about changing how you think about layout.

The Moment Everything Clicked

I used to picture HTML elements like rigid boxes, stacked on top of each other, bumping into margins, floating aimlessly.

Then one day, while debugging yet another layout mess, someone said:

“Stop fighting the boxes. Let them flex.”

It sounded poetic… and confusing.

But when I applied display: flex; for the first time, it was like the page suddenly listened.

My boxes started behaving like a team, aligning, wrapping, adjusting naturally without me wrestling with float or endless position: absolute;.

That’s when Flexbox stopped feeling like a feature… and started feeling like a mindset.

What Flexbox Really Does

Here’s the simplest way I can describe it:

Flexbox lets your elements negotiate space inside a container.

They decide based on your rules who gets to stretch, who stays compact, and how they all align together.

When you declare:

display: flex;

you’re basically saying:

“Hey container, you’re in charge now. Make your children behave intelligently.”

From there, a few key properties become your toolkit:

1) justify-content

It’s all about horizontal alignment.

Want everything centered across the main axis?

   justify-content: center;

Boom, your elements snap right into place.

2) align-items

Now we’re talking vertical balance.

Need everything to line up perfectly in the middle?

   align-items: center;

It’s like gravity for your UI.

3) flex-direction

By default, items align in a row (left to right).

Change it to a column, and suddenly your layout flows top-to-bottom.

   flex-direction: column;

It’s like rotating your design without touching HTML.

4) flex-wrap

Ever had a row that overflowed like an overstuffed suitcase?

With this, elements gracefully wrap to the next line instead of breaking everything.

   flex-wrap: wrap;

5) align-content

When you have multiple rows, this property decides how the rows themselves align inside the container.

It’s subtle but powerful when you’re designing grids or dashboards.

Why Developers Fall in Love with Flexbox

Because it feels logical.

You stop micromanaging every pixel and start describing relationships.

It’s not about positioning boxes anymore, it’s about teaching your layout how to behave.

Once I understood that, my workflow changed:

No more nested div chaos
No more guessing why a button won’t center
And best of all, my designs finally stayed responsive without writing 50 media queries

When to Use It

Flexbox shines for one-dimensional layouts, anything in a row or column.

If you’re building:

navbars
cards in a single line
buttons spaced evenly
or vertically centered login forms

Flexbox is your best friend.

For full grid layouts (like dashboards or galleries), CSS Grid is the next step.

But for most UI tasks, Flexbox is faster, simpler, and more intuitive.

The “Aha!” Lesson

The moment you stop thinking in pixels and start thinking in relationships, CSS becomes fun again.

You realize Flexbox isn’t about commands, it’s about conversation between elements.

And once you feel that click, you’ll never go back.

Read My Full Flexbox Deep-Dive

This was a gentle walk through the why behind Flexbox.

If you’d like a more practical, step-by-step guide with examples and clear visual breakdowns, you can read my full post here:

👉 How to Fix Common CSS Alignment Issues : A Simple Flexbox Guide for Beginners

That one dives into real-world alignment bugs, explains each fix visually, and includes a quick property reference for beginners.

Final Thought

CSS can feel confusing at first, but once you understand the patterns behind it, everything starts to flow.

Flexbox is one of those patterns that makes you fall back in love with frontend again.

So next time you’re stuck trying to center a div, take a deep breath, set display: flex;, and let your layout breathe.

Breaking Code, Building Skills: Lessons from My Early JavaScript Errors

Shubhra Pokhariya — Sun, 02 Nov 2025 10:57:59 +0000

Every coder has that one day when nothing works and the console turns bright red.

That was me too. I remember sitting in front of my laptop, watching endless error messages appear, wondering if maybe coding just wasn’t for me. But slowly, one bug at a time, I began to understand that those “failures” were actually little teachers hiding behind red text.

Each error shaped how I think, how I stay calm, and how I solve problems. Today, I want to share the first five coding errors that helped me grow into a more confident developer and taught me valuable lessons about patience, logic, and persistence.

1. How a Simple Syntax Error Turned Into My Favorite Lesson

My first coding error was the simplest one, and yet it felt like a disaster.

I had written my first JavaScript function and proudly hit “Run,” only to be greeted with:

Uncaught SyntaxError: Unexpected token

I stared at my code for ages, convinced something mysterious was wrong, only to realize I had forgotten a closing parenthesis. That tiny bracket had caused the chaos.

function greet(name {
  console.log("Hello, " + name);
}

The fix was almost funny when I saw it:

function greet(name) {
  console.log("Hello, " + name);
}

That was my first lesson in humility. Coding errors are not enemies; they’re mirrors showing exactly where you stopped paying attention. Every syntax mistake reminds me to slow down, breathe, and read what the computer is actually telling me.

2. The Mystery of Undefined That Every Coder Faces

Feeling more confident, I started building a tiny to-do app in JavaScript. Everything seemed fine until one line broke my confidence completely:

TypeError: addTask is not a function

After an hour of confusion, I found the culprit. I had written addtask in one place and addTask in another. That one lowercase letter changed everything. JavaScript didn’t care about my intention; it followed the exact name.

function addtask(task) {
  tasks.push(task);
}
addTask("Learn JavaScript");

The corrected version worked instantly:

function addTask(task) {
  tasks.push(task);
}
addTask("Learn JavaScript");

That day, I learned that naming consistency is not just good practice, it’s a form of respect for your future self and for anyone reading your code. Many beginners think they have logic issues when in fact, they just have naming errors. Consistency clears more bugs than you’d expect.

3. The React Moment That Finally Made “Undefined” Click

When I started learning React, I moved from simple syntax errors to more mysterious ones.

I remember building a UserCard component that was supposed to display a name:

function UserCard({ user }) {
  return <p>{user.name}</p>;
}

<UserCard />

My console flashed with:

TypeError: Cannot read properties of undefined (reading 'name')

At first, I thought React had a bug. But no, the problem was mine. I hadn’t passed the user prop at all.

<UserCard user={{ name: "Shubhra" }} />

That fix worked immediately.

It also taught me one of the most important lessons about JavaScript coding errors, never assume data exists until you’ve confirmed it.

Now, I always handle this safely:

function UserCard({ user }) {
  return <p>{user?.name || "Anonymous User"}</p>;
}

That little question mark (?.) has saved me from countless crashes since.

4. The Next.js Fetch Coding Error That Tested My Patience

My next big challenge came in a Next.js project where I needed to fetch data from an API. The setup looked perfect, but the console threw a scary red message:

Error: fetch failed

I checked my connection, rechecked my endpoint, and even switched networks. Nothing worked. Finally, after far too long, I saw the real issue, I had typed htp:// instead of https://.

await fetch("htp://api.example.com/data");

It looked right at a glance, but one missing “s” broke everything.

Once corrected, it ran beautifully:

const res = await fetch("https://api.example.com/data");

That bug taught me patience and the power of slowing down.

When you face coding errors like this, it’s not always about fixing, sometimes it’s about observing. Debugging isn’t rushing to solve; it’s tracing your logic calmly, one small step at a time.

5. When a Logic Mistake Made Everything Click

My final lesson came from a bug that didn’t crash my code, it just gave me the wrong answer.

I wrote a small loop to total expenses:

const prices = [100, 200, 300];
let total = 0;

for (let i = 0; i <= prices.length; i++) {
  total += prices[i];
}

The result was NaN, and I couldn’t figure out why.

Then I noticed the condition: I had used <= instead of <. That tiny sign caused the loop to access prices[3], which didn’t exist.

Corrected version:

for (let i = 0; i < prices.length; i++) {
  total += prices[i];
}

That one small fix changed everything. Logic errors like this are the best teachers. They don’t shout in red text, they whisper. They make you think more deeply and check your assumptions.

What These Coding Errors Taught Me

Looking back, each of these moments shaped me as a developer.

Syntax errors taught me precision.
Undefined function errors taught me discipline.
React property errors taught me data awareness.
Fetch errors taught me patience.
Logic errors taught me analytical thinking.

Together, they gave me a mindset: that debugging isn’t punishment, it’s exploration.

Each fix gave me confidence, and each small victory reminded me why I love building things from scratch.

Debugging and Growth Go Hand in Hand

When I began, I thought great developers wrote perfect code. Now I know they write buggy code, but they fix it thoughtfully. Debugging is where confidence, creativity, and calm meet.

Those first five coding errors built the foundation of my developer journey. They taught me to think clearly, to listen to my console without fear, and to enjoy the learning process.

If you are facing your own set of errors, don’t fight them.

Ask your code what it’s trying to teach you.

That’s how confusion turns into confidence and every mistake becomes a milestone.
👉 Read the full story here: My First 5 Coding Errors

DEV Community: Shubhra Pokhariya

Next.js 16 Broke My App in 4 Places and None of Them Threw an Error

1. middleware.ts stopped running and told me nothing

2. revalidateTag('products') compiled, deployed, and silently did the wrong thing

3. next lint disappeared and my CI kept saying it passed

4. One component was still reading params synchronously

The pattern that connects all four

7 Next.js 16 Caching Bugs That Compile Fine and Break Silently in Production

Bug 1: 'use cache' on the Wrapper Instead of Inside the Function

Bug 2: Deprecated revalidateTag That Compiles and Uses Legacy Behavior

Bug 3: Tag String Mismatch Across Files

Bug 4: Server Action Mutation Where the Acting User Sees Stale Data

Bug 5: updateTag in a Route Handler

Bug 6: Short cacheLife That Silently Affects PPR

Bug 7: Runtime API Inside a Cached Scope

The Common Thread

I built a free debugger because Next.js 16 'use cache' was completely invisible during development

What it catches

How to use it

Honest limitations

At a glance

Get it

Lighthouse Said It Was Fast. My Users Kept Clicking the Same Button.

The bug wasn’t performance. It was silence.

80ms response, zero perceived response

Where most of us focus (and where it falls short)

The 200ms line

What INP actually measures

The fix was not “make it faster”

The pattern you already use

Why this matters more than Lighthouse 100

If you want to go deeper

A quick way to test this

One practical takeaway

Why Most React Infinite Scroll Hooks Fail in Production (and the One That Fixed It for Me)

The Bug That Changed Everything

Where Things Start Falling Apart

What I Actually Needed

What This Hook Handles

Basic Usage

Real Use Case: Reset on Filter Change

Why AbortController Matters So Much

One Honest Note

Try It Yourself

Final Thought

I Turned My Blog Into a Full Developer Platform (Tutorials + Snippets + Quizzes + Tools)

Why I Went Quiet

What I’ve Been Working On

What Changed for Me

I Missed This Community

What You’ll See From Me Now

If You Want to Check What I Built

One Small Thought

Performance First UI Taught Me More Than Any Framework Ever Did

Speed is not what developers think it is

The day I stopped trusting Lighthouse alone

Interaction is the real contract with the user

Why Interaction to Next Paint quietly changed everything

The hidden enemy of modern interfaces

The small habit that fixed most of my issues

Why modern Next.js makes this mindset possible

Performance is not about doing less, it’s about doing things later

The business side developers rarely talk about

Performance is becoming a human skill again

What performance first UI actually demands from us

Final thought

How CSS Animation Helped Me Build Interfaces That Feel Alive

My First Real Encounter With Motion

Why Motion Matters To Users

CSS Animation Is Not Just Decoration

The Mindset Shift That Helped Me Learn Faster

Why CSS Animation Works So Well With Modern UI

The Most Surprising Part

A New Way Of Seeing My Projects

Want To Learn How I Apply CSS Animation To Real UI

Final Thought

The CSS Positioning Chaos: Why Your Elements Run Away (And How I Finally Mastered the 5 Keys)

The Phase Where CSS Positioning Made Me Doubt My Career Choices

The Beauty Behind Understanding CSS Positioning

The Best Way To Learn CSS Positioning Is Not Memorizing It

1. `middleware.ts` stopped running and told me nothing

2. `revalidateTag('products')` compiled, deployed, and silently did the wrong thing

3. `next lint` disappeared and my CI kept saying it passed

4. One component was still reading `params` synchronously

Bug 1: `'use cache'` on the Wrapper Instead of Inside the Function

Bug 2: Deprecated `revalidateTag` That Compiles and Uses Legacy Behavior

Bug 5: `updateTag` in a Route Handler

Bug 6: Short `cacheLife` That Silently Affects PPR