DEV Community: Peter Ogbonna

Understanding Next.js Cache (Part 5)

Peter Ogbonna — Sat, 28 Mar 2026 12:24:28 +0000

If you have built an application using the Next.js App Router, there is a 100% chance you've come across the issue of updating the database but the page still showing the old data.

Welcome to the Server-Side Caching paradigm.

In the React SPA world, if a user hits refresh, the cache is wiped clean. Next.js flipped the script. It caches data on the Server, and by default, it caches everything, aggressively.

To understand why your app is behaving the way it is we'll look at some concepts to understand how the Next.js cache actually works:

The Bakery Analogy (API Data vs Pages)

Think of your Next.js application as a Bakery.

The API Data (The Data Cache) will be our raw ingredients (flour, sugar, eggs) fetched from your database or external APIs.
The Pages (The Full Route Cache) will be the fully baked cake sitting in the display window.

Next.js doesn't just cache the finished HTML (cake), it also caches the raw JSON (ingredients). This means if 50 users from different location visit your site at the exact same time, Next.js doesn't overwhelm your database with 50 queries. It uses the cached ingredients to serve everyone instantly.

The 4 Layers of Caching

The most common point of confusion is what happens when a user hits the refresh button. Let's break down the four layers of the Next.js cache using our kitchen
This now leads us to the 4 layers of caching when dealing with Next.js:

1. Request Memoization (The Countertop/Clipboard)

If three different React components on the same page all call fetch('/api/user'), Next.js deduplicates them. It only makes the network request once and shares the result.

NOTE: The countertop/clipboard is wiped clean after every single page render.

2. Router Cache (The Customer's Plate)

As a user clicks around your app, Next.js stores the React Server Component payloads in the browser's memory. This makes clicking the Back button feel instantaneous.

NOTE: This doesn't survive a refresh either, a hard refresh wipes the browser's memory (washes the plate).

3. Data Cache (The Pantry)

This is where Next.js stores the raw JSON data returned from your database across multiple user sessions.

NOTE: This survives a refresh, if you refresh the page, the browser asks the server for new data, but the server just pulls the same cached data from the pantry.
This is why refreshing often doesn't "fix" stale data!

4. Full Route Cache (The Display Window)

Next.js takes the cached data and your components, rendering them into pure, static HTML at build time.

NOTE: This survives a refresh as it serves the pre-rendered HTML file until the underlying data cache is explicitly invalidated.

Taking Control of the Cache

Caching is fantastic for performance, but dynamic apps need dynamic data. Here is how you take control and tell Next.js to throw away the old ingredients.

1. Opting Out Entirely (No Caching)
If a piece of data changes constantly (like a live stock ticker or bank account balance), tell Next.js not to cache the fetch request at all:

// Fetched fresh on every single request
const res = await fetch('https://api.example.com/data', { 
  cache: 'no-store' 
});

2. Time-Based Revalidation (Stale-While-Revalidate)
Tell Next.js to keep the cache for a specific amount of time before fetching fresh data in the background:

// Revalidate this data every 3600 seconds (1 hour)
const res = await fetch('https://api.example.com/data', { 
  next: { revalidate: 3600 } 
});

3. On-Demand Revalidation (The "Invalidate" Button)
When a user submits a form (like updating their profile), you need to instantly clear the cache for that specific page. You do this inside a Server Action:

'use server'
import { revalidatePath } from 'next/cache';

export async function updateProfile(formData) {
  await db.user.update(formData);

  // Tell Next.js to throw away the cached HTML and data for this route
  revalidatePath('/profile'); 
}

The Grand Finale

Over these 5 articles, we went from understanding the theory of "Fresh vs Stale" to mastering HTTP headers, taming React-Query/Redux client state and finally conquering the Next.js server cache.

Caching is no longer just a backend optimization. It is the beating heart of the frontend User Experience. Master it, and you will build applications that are absolutely instantaneous and save server cost

Now go build something fast.

Automated Caching with RTK Query (Part 4)

Peter Ogbonna — Sat, 28 Feb 2026 14:10:23 +0000

In Part 3, we looked at how Tanstack Query revolutionized caching by moving server state out of our global state managers. But what if you work on a massive enterprise application that is already deeply invested in Redux?

Do you have to rip out Redux to get good caching? Absolutely not.

Welcome to Part 4. Let's talk about the tool that made Redux fun again: RTK Query.

Introduction

If you spend enough time on tech Twitter (X), you will inevitably hear people saying things like "Redux is dead."

This is not true as redux is powering some of the largest, most complex applications on the internet. However, the way we write Redux has fundamentally changed with the introduction of Redux-Toolkit (RTK)

In the old days, fetching a list of users in Redux required a mountain of boilerplate:

Write an Action for FETCH_USERS_REQUEST.
Write an Action for FETCH_USERS_SUCCESS.
Write an Action for FETCH_USERS_FAILURE.
Write a massive Thunk to make the actual API call.
Write a Reducer to handle the isLoading, data, and error states.

It was exhausting. And worst of all? It didn't even cache the data properly. If you navigated away and came back, your Thunk would just fetch it all over again.

In Part 4 of our series, we are looking at RTK Query (Redux Toolkit Query) which was primarily built for data fetching and caching solution integrated directly into Redux.

The Architecture: Centralized vs. Decentralized

In Part 3, we looked at React Query. React Query is largely decentralized. You call useQuery wherever you need it, and it magically syncs up based on a queryKey (like ['users']).

RTK Query takes a different, highly structured approach. It uses the API Slice pattern.

Instead of writing fetch calls scattered across your components, you define your entire API in one central location.

import { createApi, fetchBaseQuery } from '@reduxjs/toolkit/query/react';

export const apiSlice = createApi({
  reducerPath: 'api',
  baseQuery: fetchBaseQuery({ baseUrl: '/api' }),
  endpoints: (builder) => ({
    getUsers: builder.query({
      query: () => '/users',
    }),
    updateUser: builder.mutation({
      query: (user) => ({
        url: `/users/${user.id}`,
        method: 'PUT',
        body: user,
      }),
    }),
  }),
});

// RTK Query auto-generates custom React hooks for you
export const { useGetUsersQuery, useUpdateUserMutation } = apiSlice;

With just that block of code, RTK Query replaces hundreds of lines of legacy Redux boilerplate. It automatically handles the fetching, the isLoading state, the deduplication, and the caching.

Solving the Hardest Problem using "Tags"

In Part 1, we established that cache invalidation (knowing when to throw old data away) is one of the hardest problems in computer science.

RTK Query solves this using an incredibly elegant system called Automated Tag-based Invalidation.

Think of a Tag like a sticky note you put on a piece of data.

providesTags (Applying the label):
When you fetch the list of users, you tell RTK Query to tag that cached data with ['User'].
invalidatesTags (Tearing off the label):
When you run a mutation to update a specific user, you tell RTK Query to invalidate the ['User'] tag.

// Inside your endpoints builder:
getUsers: builder.query({
  query: () => '/users',
  providesTags: ['User'], // Label this data as 'User'
}),
updateUser: builder.mutation({
  query: (user) => ({ url: `/users/${user.id}`, method: 'PUT' }),
  invalidatesTags: ['User'], // Throw away any cache labeled 'User'
}),

The moment updateUser succeeds, RTK Query automatically sees that the ['User'] tag was invalidated. It instantly looks at your app, finds any component currently displaying the getUsers query, and forces a background refetch.

Your UI updates automatically. No manual dispatching. No messy states.

React Query vs. RTK Query: Which should you choose?

Since both tools solve the same problem (Server State caching), which one should you use?

Choose React Query: If you are starting a new project, you don't need a massive global client-state store, or you prefer a lightweight, flexible, decentralized approach.
Choose RTK Query: If you are already using Redux Toolkit. Adding React Query to an existing Redux app means you now have two separate stores to manage and debug. RTK Query drops right into your existing Redux DevTools, keeping your architecture clean and unified.

What’s Next?

Up to this point, we have focused entirely on caching data inside the user's browser (Client-Side Caching). But the frontend world is shifting.

In Part 5, the grand finale of this series, we are crossing the chasm into Server-Side Caching. We will look at Next.js (using App Router) and how it aggressively caches not just data, but entire HTML pages and React Server Components.

Prepare to have your mental model challenged one last time. See you in Part 5.

TanStack Query Changed Everything (Part 3)

Peter Ogbonna — Wed, 18 Feb 2026 12:00:30 +0000

In Part 2, we learnt about the invisible layer of HTTP caching. Now, we move to the application layer.

You can relate to the nightmare associated with managing data coming from the server.

We have all written this code before:

Create a useState for data.
Create a useState for isLoading.
Create a useState for error.
Write a useEffect to fetch the data.
Realize we forgot to handle race conditions like what if the component unmounts before the fetch finishes?
Realize we have no way to deduplicate requests if two components need the same data.

As I argued in my previous article about React Router Loaders, manual state management looks messy and at times, tend to be where bugs go to hide.

Today, we look at TanStack Query (React Query)*. It isn't just a data fetching library; it is an async state manager that brings the stale-while-revalidate strategy (discussed in part 2) directly into your components.

The Philosophy: Server State vs. Client State

The biggest breakthrough TanStack Query brought to the frontend world is the realization that Server State is not the same as Client State.

Client State asks these questions: Is the modal open? What is the current theme? Is the sidebar collapsed? All these belongs in useState, Context, or Zustand).
For Server State, we talk about: The list of users, the current blog post.

Server state is "borrowed" as it's data that exists remotely, owned by the server (somebody else), hence can become stale without you knowing.

TanStack Query is designed explicitly to manage server state.

A Side-by-Side Comparison

Let's look at the difference.

The Old Way - using useEffect:

function UserProfile() {
  const [user, setUser] = useState(null);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(() => {
    let isMounted = true;
    fetch('/api/user')
      .then((res) => res.json())
      .then((data) => {
        if (isMounted) {
            setUser(data);
            setIsLoading(false);
        }
      })
      .catch((err) => {
         if (isMounted) setError(err);
      });

    return () => { isMounted = false };
  }, []);

  if (isLoading) return <div>Loading...</div>;
  if (error) return <div>Error!</div>;
  return <div>{user.name}</div>;
}

The New way - using TanStack Query:

// UserProfile.jsx
import { useQuery } from '@tanstack/react-query';

function UserProfile() {
  const { data: user, isLoading, error } = useQuery({
    queryKey: ['user'],
    queryFn: () => fetch('/api/user').then((res) => res.json()),
  });

  if (isLoading) return <div>Loading...</div>;
  if (error) return <div>Error!</div>;
  return <div>{user.name}</div>;
}

It looks similar, but under the hood, TanStack Query is doing something magical, which is Global Caching.

If you use this <UserProfile /> component in 5 different places on your screen, React Query will deduplicate the requests. It will only fetch once and serve the result to all 5 components instantly.

The Configuration: `staleTime` vs `gcTime`

TanStack Query uses the combo of these two to handle caching

1. `staleTime` (The "Freshness" Timer)

This controls when data is considered old.

Default is 0 (Zero).

If staleTime is 5000 (5 seconds), the data remains Fresh for 5 seconds. During this time, if another component asks for this data, it uses the cache preventing a background refetch.
After 5 seconds, the data becomes Stale, TanStack Query will still serve it instantly but will trigger a background refetch to update it.

It's default is zero, because TanStack Query assumes your data is always out of date.

2. `gcTime` (The "Garbage Collection" Timer)

Formerly known as cacheTime.

This controls how long unused data stays in memory.

Default is 300000 (5 minutes).

If you navigate away from the UserProfile page, the data is no longer being used.
React Query keeps it in memory for 5 minutes in case you come back.
If you return within 5 minutes, the data appears instantly else, the data is gone and you get a refetch.

Solving the Hardest Problem (Invalidation)

In Part 1, we said invalidation is the hardest problem in CS.

TanStack Query solves this with invalidateQueries.

Imagine you have a mutation to update a user's name.

const mutation = useMutation({
  mutationFn: updateUser,
  onSuccess: () => {
    // This tells TanStack Query the 'user' data is now dirty. It uses the 'queryKey' to identify which to invalidate
    queryClient.invalidateQueries({ queryKey: ['user'] });
  },
});

When this runs:

The mutation succeeds.
React Query marks the ['user'] cache as Stale immediately.
Any component currently displaying the user triggers a background refetch, hence automatically updating the UI!

What’s Next?

TanStack Query is the standard for general Frontend applications. But what if you are using Redux? What if you want this caching power but integrated tightly with your global store?

In Part 4, we will explore RTK Query (Redux Toolkit Query). We will see how it takes these same concepts and applies them to the Redux ecosystem.

See you in Part 4.

The Invisible Layer: Mastering HTTP Caching (Part 2)

Peter Ogbonna — Mon, 16 Feb 2026 22:45:36 +0000

"I updated the data in the database, but the user is still seeing the old version!"

If you've ever screamed this while frantically hard-refreshing your browser, you have met the HTTP Cache.

In Part 1, I discussed the mindset of caching. Today, we look at the mechanics.

Most frontend engineers don't realize the massive conversation happening in the Network Tab. Conversations in the Response Headers determines whether your request even reaches the server at all.

This is why it's important to master the Invisible Layer to understand caching better and know what happens under the hood, most of the library you use are built on this.

The Browser’s Decision Tree

When you call fetch('/api/user') for example, the browser doesn't immediately go to the internet, it goes through a strict checklist.

Memory/Disk Check: Do I have a copy of this locally?
Expiration Check: If yes, is it fresh (based on max-age)?
The Short Circuit: If it is fresh, the browser returns the data immediately. It never talks to the server.

This behavior is controlled by the Cache-Control header.

Now these 3 concepts will help you understand how Caching works on the Network (HTTP) layer

1. The Rules: `Cache-Control`

This is the most important header in web performance. It tells the browser exactly how to behave.

`max-age` (The Timer)

Cache-Control: max-age=3600

This tells the browser that "This data is good for 1 hour (3600 seconds). Do not ask the server for this data again until that time is up."

The Trap: If you deploy a critical bug fix 5 minutes later, users with the cached version won't see it for another 55 minutes.

`no-cache` vs `no-store` (The Great Confusion)

This is the most common interview question and production mistake regarding caching.

no-store says "Never save this."

Use this for sensitive data (banking info) or data that changes every millisecond.

no-cache says "Go ahead and save it, but you must check with the server before using it."

Now this forces the browser to ask the server, "Is this version still good?" every single time.

Read more: MDN Web Docs: Cache-Control

2. The Receipt System: `ETags` and `Last-modified (304)`

Imagine you have a large list of 5,000 products. You don't want to download that 2MB file every time, but you also need to know if it changed.

This is where Conditional Requests come in.

For the First request, server sends the data + an ETag (a unique hash/fingerprint of the file).
For the Second request, The browser sends that ETag back in a header called If-None-Match.
From the Server’s response, If the hash is the same, the server sends a 304 Not Modified.

The Win: You saved the user from downloading 2MB. The browser just reuses the version it already had.

3. The "Stale-While-Revalidate" Strategy

If you learn one thing from this article, let it be this. It is the gold standard for modern web performance.

Cache-Control: max-age=60, stale-while-revalidate=600

This tells the browser:

If the data is less than 60 seconds old, show it instantly (Fresh).

If it's between 60 seconds and 600 seconds old, show the old data immediately, but in the background, fetch the new data and update the cache for next time (Stale-while-revalidate).

This eliminates the "loading spinner" entirely while still keeping the data relatively fresh.

Deep Dive: web.dev: Love your cache (stale-while-revalidate)

Why This Matters for React Developers

You might be thinking, "I'm a frontend dev, I don't configure server headers!"

Here is the truth, You can't fix with JavaScript what you broke with HTTP.

If your API sends Cache-Control: no-store, your fancy React Query setup will struggle to maintain a cache effectively because the browser is fighting against it. If your API sends max-age=31536000 (1 year) for a user profile, your users will never see their profile updates.

You need to check these headers in the Chrome DevTools Network Tab.

The 3 Key Takeaways:

The Browser is Smart; it tries to save you work by storing files locally, so you need to know how to tell it when to stop using those files.
The "Receipt" System: Instead of downloading a whole file, the browser can just ask the server, "Has this changed?" If the server says "No" (304 Not Modified), you save time and data.
User Experience: Using stale-while-revalidate allows your app to show old data instantly while it fetches new data in the background, eliminating need for loading spinners.

Deep Dive Resources

If you want to become a true expert on this layer, I highly recommend reading these specifications:

MDN HTTP Caching Guide: The comprehensive manual on how browsers handle storage.
Google's Web.dev Guide: A practical guide on configuring headers for performance (and Lighthouse scores).
Cloudflare's CDN Learning Center: Excellent for understanding how Edge caching (CDNs) interacts with browser caching.

What’s Next?

Now that we understand the Invisible Layer, we can finally move to the Application Layer.

In Part 3, we will be looking at React Query (TanStack Query), to see how to implement an efficient caching system with it.

See you in Part 3.

The Frontend Caching Handbook (Part 1)

Peter Ogbonna — Thu, 12 Feb 2026 15:35:15 +0000

I want you to imagine a scenario.

You walk into a coffee shop and order a Latte, the barista makes it, hands it to you and you take a sip, it tastes perfect. You turn around to grab a napkin, turn back to the counter and the latte is gone...

You ask for it again. The barista sighs, grinds the beans again, steams the milk again, and hands you a new cup.

This sounds ridiculous, right? Yet this is exactly how many frontend applications behave today.

We fetch a list of products. The user navigates to a product detail page, then clicks "Back" only to meet a Spinner because the list is being fetched again.

Welcome to Part 1 of my series on Frontend Caching. Before we dive into caching with tools like Tanstack Query, RTK Query, or Next.js (which we will cover in later articles), we need to fix our mindset.

We need to stop optimizing for "easy coding" and start optimizing for "instant experiences".

Why Caching is Not Optional

For a long time, caching was seen as a backend concern (Redis, database caching) or a purely "performance optimization" task you do at the end of a project.

But that's not the case, Caching affects user experience and cost, so should be taken into consideration at the initial stage of building.

Caching solves three specific problems:

Latency (The UX Killer): Even on 5G, a network request takes time. Reading from memory takes nanoseconds.
Bandwidth (The Cost Killer): Why download the same 500KB JSON payload five times in one session? Those extra requests are costing unnecessary extra money
Server Load (The Scale Killer): Your backend engineers will thank you if you stop hammering the API for data that hasn't changed.

The Core Concept: Fresh vs Stale Data

To understand caching, you must understand the concept of Staleness.

In a perfect world, our frontend would always be perfectly synced with the database. But the moment you fetch data to the client, it is technically stale. Something could have changed on the server the millisecond after your request finished.

Hence, Caching is the art of accepting staleness for a defined period.

This is the mental shift, instead of asking: "Is this data perfectly up to date?" You should ask: "Is this data fresh enough for the user right now?"

If I’m looking at a list of blog posts, does it matter if a new post was added 2 seconds ago? Probably not! I can show the cached list instantly as that data is stale but acceptable.

But If I’m looking at my bank account balance? That better be fresh

The Three Layers of Caching

As frontend engineers, we usually deal with three distinct layers. Understanding where your data lives is half the battle.

1. The Browser Cache (HTTP)
This is the invisible layer. Before your React or Vue code even runs, the browser checks if it already has the resource. This is controlled by HTTP headers (Cache-Control, ETag and the likes).

The Browser Cache is usually automatic if configured correctly on the server, though hard to manipulate manually from JavaScript.

2. The CDN / Edge Cache
This lives between your user and your server. It stores copies of your content closer to the user geographically.

One advantage is fast delivery of static assets, though if you cache dynamic API responses here, you risk showing different user different data which can be a nightmare to debug

3. Application Memory (The Client State)
This is where we will focus most of this series. This is using React Query, RTK Query and the likes, or even a simple object in your code.

Here you have instant access and complete control over invalidation logic. Though it vanishes when the user refreshes the page (unless you persist it).

The Hardest Problem in Computer Science - Invalidation

You’ve likely heard the quote by Phil Karlton:

There are only two hard things in Computer Science: cache invalidation and naming things.

Invalidation is knowing when to delete the cache.

Imagine you cache a User Profile. The user updates their name on a Settings page.

You send the PUT request to update the name.

The server confirms it's updated.

The Trap is this: You navigate back to the Profile page, and your cache still holds the old name now the user thinks the app is broken.

You have to tell the cache: "Hey, the data associated with User Profile is now dirty. Fetch it again next time."

Technology has evolved so well that we have tools that aids us build better performant web applications...

What's Next?

In this series, we'll be moving from "No idea" to "Master". We aren't just going to learn how to use the tools; we are going to learn why they work the way they do.

Here is the roadmap:

Part 2: The Invisible Layer – Mastering HTTP Headers (because you can't fix with JS what you broke with Headers).

Part 3: The State Manager Revolution – deep dive into Tanstack Query.

Part 4: The Redux Powerhouse – Implementation with RTK Query.

Part 5: The Full Stack – Server-side caching in Next.js.

See you in Part 2.

Beyond Clean Code: Mastering Parallel Data Fetching with React Router's defer

Peter Ogbonna — Tue, 23 Dec 2025 16:04:55 +0000

In my previous post, I discussed how to get rid of Messy State by moving from useEffect to React Router Loaders.

We successfully cleaned up our components, but we introduced a new challenge; The "Waiting Game."

Because standard Loaders fetch data before the route renders, if your API takes 3 seconds to respond, your user is stuck looking at the old page until that loader finishes. To the user, it feels like the app is frozen or the link is broken.

Today, we solve that with the Defer Pattern.

Understanding the Logic: What exactly is "defer"?

To understand defer, you have to think about how a normal loader works. Usually, a loader is like a waiter who won't leave the kitchen until every single dish in your order is cooked. If the steak takes 20 minutes, you don't even get your water until the steak is done.

defer changes the rules. It allows the waiter to bring the water and appetizers (Fast Data) immediately, while the steak (Slow Data) is still cooking.

The Magic of the Promise

When you use defer, you aren't returning raw data; you are returning a Promise.

The Loader: Tells React Router, "Here is some data I have now, and here is a 'ticket' (the promise) for data that is coming later.
The Component: Renders immediately. It doesn't wait for that "ticket" to resolve.

The Implementation: v6 vs v7

For v6, to make this work, we need a three-part harmony: the defer utility, the <Await> component, and React's built-in <Suspense>.
However, React Router recently evolved, in v7, we don't need defer as the router is smart enough to handle promises automatically.

Step 1: Edit the Loader

Instead of using await for every fetch, we only await the critical data.

In React Router v6

// for v6.4+ we use the "defer"
import { defer } from "react-router-dom";

export async function loader({ params }) {
  // CRITICAL DATA: We `await` this. The page won't load until we have them.
  const productReq = await fetch(`/api/product/${params.id}`);
  const product = await productReq.json();

  // NON-CRITICAL DATA: No `await` here! We pass the promise directly.
  const reviewsPromise = fetch(`/api/product/${params.id}/reviews`).then(res => res.json());

  return defer({
    product,
    reviews: reviewsPromise 
  });
}

In React Router v7

// for v7 we use don't use the "defer"
export async function loader({ params }) {
  // CRITICAL DATA: We `await` this. The page won't load until we have them.
  const productReq = await fetch(`/api/product/${params.id}`);
  const product = await productReq.json();

  // NON-CRITICAL DATA: No `await` here! We pass the promise directly.
  const reviewsPromise = fetch(`/api/product/${params.id}/reviews`).then(res => res.json());

  return {
    product,
    reviews: reviewsPromise 
  };
}

Step 2: The UI (Unwrapping the Promise)

Regardless of which version you use, the UI implementation is the same.

Since reviews is a Promise, we can't just .map() over it instantly. We use the <Await> component to "unwrap" it once it arrives.

import { useLoaderData, Await } from "react-router-dom";
import { Suspense } from "react";

export default function ProductPage() {
  const { product, reviews } = useLoaderData();

  return (
    <div>
      <h1>{product.title}</h1> {/* Renders instantly */}

      <Suspense fallback={<p>Loading reviews...</p>}>
        <Await resolve={reviews} errorElement={<p>Error loading reviews!</p>}>
          {(resolvedReviews) => (
            <ul>
              {resolvedReviews.map(r => <li key={r.id}>{r.comment}</li>)}
            </ul>
          )}
        </Await>
      </Suspense>
    </div>
  );
}

Why this is a UX Game Changer

1. Faster Perceived Performance

The user sees the "shell" of the page and the primary content almost instantly. They can start reading the product description while the reviews are still "streaming" in over the wire.

2. No more "All-or-Nothing" UI

In the old useEffect days, if one API call failed, you often ended up with a giant error screen. With <Await>, you get an errorElement property. If the reviews fail, only that section shows an error. The rest of your page stays functional.

3. Better than "Global" Loading Spinners

Instead of a giant spinner that covers the whole screen, you can use Skeleton Screens in your fallback to reserve space, preventing that annoying "layout shift" when data pops in.

When to defer and when not to

Since the focus is user experience, wrong use can act against the goal

Scenario	Use Standard await	Use defer
Crucial Data (SEO/Meta tags)	✅ Yes	❌ No
Fast APIs (< 200ms)	✅ Yes	❌ No
Slow Analytics/Logs	❌ No	✅ Yes
Secondary Page Content	❌ No	✅ Yes

Conclusion

Introducing Loaders cleaned up our code in Part 1, but defer makes our apps feel like professional-grade software. By strategically choosing what data to wait for and what data to stream, you give your users a snappier, more reliable experience.

What’s your favorite way to improve user experience? Let me know in the comments!

Stop Writing Messy States: Why I Swapped useEffect for React Router Loaders

Peter Ogbonna — Thu, 18 Dec 2025 14:33:49 +0000

We have all been there... You create a new component, and the first thing you do is set up the trinity of data fetching state:

loading
error
data

Then, you write the inevitable useEffect hook. It usually looks something like this:

const [user, setUser] = useState(null);
const [loading, setLoading] = useState(true);
const [error, setError] = useState(null);

useEffect(() => {
  const fetchData = async () => {
    try {
      const response = await fetch(url);
      if (!response.ok) throw new Error('Network response was not ok');
      const result = await response.json();
      setUser(result);
    } catch (err) {
      setError(err);
    } finally {
      setLoading(false);
    }
  };
  fetchData();
}, [url]);

if (loading) return <Spinner />;
if (error) return <ErrorMessage />

The Problem:

Boilerplate: We just wrote 20 lines of code just to get data from A to B.

Render-then-Fetch: The component has to mount (render) first before the effect kicks in to start fetching. This causes a waterfall effect and slower perceived performance.

State Management Hell: You are manually managing loading and error states in every single component that needs data.

The Solution: React Router Loaders introduced in v6

React Router v6.4+ introduced a paradigm shift: Loaders

Loaders are a part of the Data APIs which lets you handle data fetching, actions/mutations and error handling directly in your route definitions

The idea is simple: Fetch-then-Render.

Instead of the component asking for data after it mounts, the Router fetches the data before it renders the component. If the data isn't ready, the component doesn't load. If there is an error, the Router handles it elsewhere.

Here is how to clean up your code in 3 steps:

It's assumed you're working on a react application with react-router installed

Step 1: Setup Router that supports Data APIs

This will involve reconfiguring the router setup see Picking a Router

//App.jsx

// From this
import {BrowserRouter, Routes, Route} from "react-router"
import UserProfile from "./user"

function App() {
  return (
   <BrowserRouter>
      <Routes>
        <Route path="/" element={<UserProfile />} />
      </Routes>
    </BrowserRouter>
  )
}

//To this
import {RouterProvider, createBrowserRouter} from "react-router"
import UserProfile from "/user"

const router = createBrowserRouter([
  {
    path: '/user',
    element: <UserProfile />
  }
])

function App() {
  return (
    <RouterProvider router={router} />
  )
}

Step 2: Write a loader function

You define a function that fetches your data.

// utils.js
export const userLoader = async () => {
  const res = await fetch('https://api.example.com/user');

  if (!res.ok) {
    throw Error("Could not fetch user details");
  }

  return res.json();
}

Step 3: Connect it to the Route

In your Router configuration (using createBrowserRouter), you plug the loader directly into the route.

// App.jsx
import { createBrowserRouter, RouterProvider } from 'react-router-dom';
import { userLoader } from './utils';
import UserProfile from './user';
import ErrorPage from './errorPage';

const router = createBrowserRouter([
  {
    path: '/user',
    element: <UserProfile />,
    loader: userLoader,       // <--- The magic happens here
    errorElement: <ErrorPage /> // <--- Handles errors automatically!
  }
]);

function App() {
  return <RouterProvider router={router} />;
}

Step 3: Consume the Data

Now, look at how clean your component becomes. No useEffect, No useState for loading or errors. Just one hook: useLoaderData

// user.jsx
import { useLoaderData } from 'react-router';

export default function UserProfile() {
  const user = useLoaderData(); // Data is already here!

  return (
    <div>
      <h1>{user.name}</h1>
      <p>{user.email}</p>
    </div>
  );
}

In the ErrorPage, you can get error message and handle error by grabbing the useRouteError hook from "react-router", implementation is similar to useLoaderData

Why this is Clean Code?

Separation of Concerns: Your UI component is responsible for UI, not fetching logic. The fetching logic lives in the loader.
Automatic Error Handling: If the API fails, React Router catches the error and renders the errorElement defined in the route. Hence, your component doesn't need to check if (error).
Performance: The browser starts fetching the data as soon as the user clicks the link, in parallel with loading the code for the new page.

Conclusion

useEffect is a powerful tool but using it for data fetching in 2025 is often unnecessary complexity. By switching to Loaders, you delete code, prevent bugs, and make your application feel snappier.

Give your useEffect a break and let the Router do the heavy lifting.

Understanding APIs and Streamlining Development with Postman

Peter Ogbonna — Fri, 08 Dec 2023 12:33:47 +0000

In the digital age, APIs (Application Programming Interfaces) serve as the backbone of modern software development, enabling seamless communication between different applications, services, and systems. They facilitate the exchange of data and functionalities, allowing developers to create innovative solutions from an already existing structure.
In this blog post, we are going to look at the foundational concepts of APIs, their importance in development and how postman came in to revolutionize api testing and streamlined development experience.

What is an API?

As the name implies, Application Programming Interface defines the rules and protocols that enable different software applications to communicate with each other. It acts as an intermediary, allowing one piece of software to access and interact with another.

A simple analogy of how apis work is just like a traditional restaurant where you step in and you place your order through the waiter and the waiter gets your order to the kitchen and returns with your order. In this analogy, the waiter is the api, the customer is the client/user and the Kitchen is the server. In other words, apis basically act as an intermediary to allow one piece of software to access and interact with another, they make this possible without revealing the codebase or database of the server, you get what your ask for

APIs have a versatile area of applications not limited to softwares alone, we also have:

Hardware APIs: These are software that allow you to interact with hardware components, for example, a printer API lets your software communicate with the printer to produce physical copies
Software Library APIs: These provide pre-built functions and routines that developers can use to perform specific tasks, they embed complex functionalities, this helps to save a bunch of time!
Web APIs: This is perhaps the most common type, they enable communication between different web services. They allow you to fetch data from a remote server, like a restaurant offering takeout service from its menu. This will be the focus for today.

APIs come in various types, including RESTful APIs, SOAP APIs, and GraphQL, each with its own specifications and purposes. The mostly used is the RESTful API

The Importance of APIs in Development

The significance of APIs in modern development cannot be overstated. They offer several key benefits:

Integration: APIs allow disparate systems to seamlessly work together, fostering interoperability and enabling the creation of integrated solutions.
Efficiency: Developers can leverage existing APIs to access functionalities or data, reducing development time and effort.
Scalability: APIs provide a scalable foundation for applications, allowing them to adapt and grow as requirements change.
Innovation: APIs empower developers to build upon existing services and functionalities, encouraging innovation and the creation of new products.

The Anatomy of an API call

Understanding an API call involves grasping several key components and considerations:

Endpoint: The URL that specifies the location and resource being accessed or manipulated. It determines where the API request is sent. Each api has a unique endpoint
HTTP Method (HTTP Verb): - Indicates the type of action being performed on the resource (GET, POST, PUT, DELETE, etc.).
Headers: Additional information sent with the request, including authentication tokens, content types, or metadata.
Parameters: Query parameters or request body data (in the case of POST, PUT, PATCH) sent along with the request to provide additional information or modify the request. To learn more, visit: HTTP verbs
Authentication: If required, methods for authenticating the requester's identity, such as API keys, OAuth tokens, or other authentication mechanisms.
Response: The data returned by the API call, typically in JSON or XML format. It includes the requested information or an acknowledgment of the action performed.
Status Codes: Indicate the success or failure of the request, each code has a unique message, be it success or failure (e.g., 200 for success, 404 for not found, 500 for server errors). To learn more about status code, visit: Status Code MDN
.

Introducing Postman

Amidst the varieties of tools available for API development and testing, Postman stands out as a powerful and user-friendly option. It offers a comprehensive suite of features that streamline the API development lifecycle.

Key Benefits of Postman:

User-Friendly Interface: Postman's intuitive interface simplifies the process of designing, testing, and debugging APIs, making it accessible for both beginners and seasoned developers.
Collaboration: It facilitates team collaboration by allowing seamless sharing of API collections, environments, and tests, enabling efficient teamwork and knowledge sharing.
Automated Testing: Postman enables the creation of automated tests, ensuring the reliability and consistency of APIs across different environments.
Documentation: With its documentation capabilities, Postman assists in generating comprehensive API documentation, simplifying the process of understanding and consuming APIs.
Mock Servers: Developers can create mock servers to simulate API endpoints, allowing for testing without depending on the actual backend implementation.

Conclusion

APIs serve as the backbone of interconnected digital ecosystems, enabling the creation of robust and innovative applications. Among the tools available for API development and testing, Postman emerges as a versatile solution, empowering developers to streamline their workflow, enhance collaboration, and build reliable APIs efficiently.

In conclusion, understanding the importance of APIs and harnessing the capabilities of tools like Postman can significantly contribute to the success and efficiency of software development endeavors in today's interconnected world.

CRUD Todo App - React and Redux-toolkit

Peter Ogbonna — Tue, 18 Apr 2023 02:25:09 +0000

Introduction

We’ll make a simple Todo-list app that performs all four CRUD (Create, Read, Update, Delete) operations- on the front-end, using React and Redux-Toolkit: live link

If you are familiar with Redux you can jump straight to the Implementation

What to get in this article:

Why Redux?
Redux vs Redux-Toolkit
How Redux Works
Implementation
Helpful Links

Why Redux?

Redux is a state management library, that helps centralize your application’s state and logic. It comes with a DevTool which makes it easy to trace when, where, why and how your application’s state changed.
It works with any UI layer and popularly used with Reactjs.
And you might be wondering, what’s the difference between Redux and Redux-Toolkit, let’s take a look at that.

Redux vs ReduxToolkit

Redux is the core library for managing application state, while Redux-Toolkit is a companion library that provides additional utilities for working with Redux. You can use Redux on its own, but many developers find that Redux-Toolkit makes it even easier and more efficient to work with Redux even the Redux team recommends Redux-Toolkit as the approach for writing Redux logic, because it is a newer library that provides a set of utilities for working with Redux. It provides a simpler API for common tasks, as well as performance optimizations that can help to improve the performance of your application for example, the library uses Immer under the hood to provide immutable updates to the store, which can help to avoid unnecessary re-renders. Redux-Toolkit comes with functions for creating and managing Redux stores, as well as middleware for handling asynchronous actions, this can help to make your code more organized and maintainable.
Simply put, Redux-Toolkit is designed to make it easier and more efficient to write Redux applications

How Redux works

In Redux, you basically create an action and dispatch the action using the usedispatch hook.
Redux provides a predictable state container that helps manage the state of your application in a centralized manner, a store. A “store” is a container that retains your application’s global state, each component can access the store without having to send down props from one component to another.

The five major terminologies in Redux:

In major Redux applications you’ll find these major components working hand in hand. I will give brief explanation of each of these terminologies, it might not be clear enough, but follow through, while building our app it will become clearer. We’ll briefly discuss the main terminologies in a typical Redux app

Store: A single source of truth that holds the entire state tree of your application.
Actions: Actions are the medium used to send data from your application to your Redux store, they are plain JavaScript objects that represent an intention to change the state, they contain a type property that describes the action as well as a payload (an additional data necessary to carryout the action) to update the state.
Reducers: Reducers are Pure functions that take the current state and an action and return a new state. They should not modify the current state directly, but instead return a new state object.
Dispatch: To update the state, an action must be dispatched to the store using the `dispatch` function. This triggers the store to call the corresponding reducer function with the current state and the dispatched action. Just think of the `dispatch` function as `setState`
Selector: To access data from the store. We do this by using the `useSelector` hook from react-redux

Just think of Dispatch and Selector as

const [name, setName] = useState("Grey");

// Dispatch (update the state)
setName("Dan");

// Selector (get the state)
console.log(name)

Implementation

Installation

To get started, you only need two npm packages
npm install @reduxjs/toolkit react-redux

Create a Redux Store

src/redux/store.js

import { configureStore } from '@reduxjs/toolkit';

export const store = configureStore({
  reducer:{},
});

Add the Redux Store to Index.js parent file

src/index.js

import { Provider } from 'react-redux';
import { store } from './redux/store';

<Provider store={store}>
   <App />
</Provider>

When done importing these necessary components, ensure to wrap your component with the provider and include the store you added recently, this enables your whole app to access the Redux store

Create a Slice

Of course, Redux- Toolkit introduced slice. A slice is a part of the application’s state that can be updated independently. It contains a set of actions and a reducer that handles those actions. Think of a slice as a certain feature you want to apply different action to it, on different occasions, now each action in the feature (slice) uses the same state, having initial value of initialState. In this app, I have 3 actions running in the same slice. All the actions reside in the reducers object

src/redux/reducer.js

import { createSlice } from '@reduxjs/toolkit';

const initialState = [];

const todoReducer = createSlice({
  name: 'todos',
  initialState,
  reducers: {};
});

export const reducer = todoReducer.reducer;

With this, we can go ahead to add our slice Reducers to the store in src/redux/store.js

import { configureStore } from '@reduxjs/toolkit';
+ import { reducer } from './reducer';

export const store = configureStore({
+  reducer: reducer,
});

This is the basic configuration needed using Redux-toolkit, we are ready to go Redux baby!
Let’s go about creating actions in src/redux/reducer.js

To Add Note

import { createSlice } from '@reduxjs/toolkit';

const initialState = [];

const todoReducer = createSlice({
  name: 'todos',
  initialState,
  reducers: {
+    // Adding new todo
+   addTodo: (state, action) => {
+      return [...state, action.payload];
+    },
  },
});

+ export const { addTodo} = todoReducer.actions;
export const reducer = todoReducer.reducer;

The state is the current state, with initial value of initialState, action.payload is the value passed into the addTodo function in src/components/TextField/TextField.jsx
We use our actions to work with the store with the help of the useDispatch hook from react-redux, this is how we Dispatch as explained earlier

src/components/TextField/TextField.jsx

import { addTodo } from '../../redux/reducer';
import { useDispatch } from 'react-redux';
const dispatch = useDispatch();

dispatch(
    addTodo({
    id: Math.floor(Math.random() * 100),
    item: text,
})

The addTodo action takes in the value passed in, which is an object of two key: value pairs and adds it to the array, hence updating the state. Therefore making the state an array of objects with two keys: id and text.

To Delete Note:

import { createSlice } from '@reduxjs/toolkit';

const initialState = [];

const todoReducer = createSlice({
  name: 'todos',
  initialState,
  reducers: {
    // Adding new todo
addTodo: (state, action) => {
     return [...state, action.payload];
   },
+ deleteTodo: (state, action) => {
+      return state.filter((item) => {
+        return item.id !== action.payload;
+      });
+    },
  },
});

+ export const { addTodo, deleteTodo} = todoReducer.actions;
export const reducer = todoReducer.reducer;

The deleteTodo function checks for a matching id to the one passed in through our dispatch function, to update the state, while removing the matched id from the array
Here, the action.payload is id
from src/components/Note/Note.jsx

import { deleteTodo } from '../../redux/reducer';
import { useDispatch } from 'react-redux';
const dispatch = useDispatch();
dispatch(deleteTodo(id));

Update Note:

updateTodo: (state, action) => {
      return state.map((todo) => {
      const item = todo.item;
      if (todo.id === action.payload.id) {
         return {
            ...todo,
            [item]: action.payload.text,
          };
        }
        return todo;
      });
    },

The updateTodo function updates the value of a selected item from the array of objects(different list items), then updates it’s item value by the text.

This function takes an object of two key value pairs as seen in src/components/Note/Note.jsx

import {updateTodo } from '../../redux/reducer';
updateTodo({ id, text: inputRef.current.value });

The id is a numeric value used to identify an item from the list, the text is a string used to update the text of the identified item.

Access the state

This is where selector comes in, as explained earlier we use it by using the useSelector hook from react-redux. It helps us extract data from the Redux store state, using a selector function

import { useSelector } from 'react-redux';
import Note from '../Note/Note';

function ShowTodo() {
  const list = useSelector((state) => state);
  return (
    <>
      {list &&
        list.map((item) => (
          <Note text={item.item} key={item.id} id={item.id} />
        ))}
    </>
  );
}

export default ShowTodo;

And that is how we access data from our store.
Hope you got value!

DEV Community: Peter Ogbonna

Understanding Next.js Cache (Part 5)

The Bakery Analogy (API Data vs Pages)

The 4 Layers of Caching

1. Request Memoization (The Countertop/Clipboard)

2. Router Cache (The Customer's Plate)

3. Data Cache (The Pantry)

4. Full Route Cache (The Display Window)

Taking Control of the Cache

The Grand Finale

Automated Caching with RTK Query (Part 4)

Introduction

The Architecture: Centralized vs. Decentralized

Solving the Hardest Problem using "Tags"

React Query vs. RTK Query: Which should you choose?

What’s Next?

TanStack Query Changed Everything (Part 3)

The Philosophy: Server State vs. Client State

A Side-by-Side Comparison

The Configuration: staleTime vs gcTime

1. staleTime (The "Freshness" Timer)

2. gcTime (The "Garbage Collection" Timer)

Solving the Hardest Problem (Invalidation)

What’s Next?

The Invisible Layer: Mastering HTTP Caching (Part 2)

The Browser’s Decision Tree

1. The Rules: Cache-Control

max-age (The Timer)

no-cache vs no-store (The Great Confusion)

2. The Receipt System: ETags and Last-modified (304)

3. The "Stale-While-Revalidate" Strategy

Why This Matters for React Developers

The 3 Key Takeaways:

Deep Dive Resources

What’s Next?

The Frontend Caching Handbook (Part 1)

Why Caching is Not Optional

The Core Concept: Fresh vs Stale Data

The Three Layers of Caching

The Hardest Problem in Computer Science - Invalidation

What's Next?

Beyond Clean Code: Mastering Parallel Data Fetching with React Router's defer

Understanding the Logic: What exactly is "defer"?

The Magic of the Promise

The Implementation: v6 vs v7

Step 1: Edit the Loader

Step 2: The UI (Unwrapping the Promise)

Why this is a UX Game Changer

1. Faster Perceived Performance

2. No more "All-or-Nothing" UI

3. Better than "Global" Loading Spinners

When to defer and when not to

Conclusion

Stop Writing Messy States: Why I Swapped useEffect for React Router Loaders

The Problem:

The Solution: React Router Loaders introduced in v6

Step 1: Setup Router that supports Data APIs

Step 2: Write a loader function

Step 3: Connect it to the Route

Step 3: Consume the Data

Why this is Clean Code?

Conclusion

Understanding APIs and Streamlining Development with Postman

What is an API?

The Importance of APIs in Development

The Anatomy of an API call

Introducing Postman

Key Benefits of Postman:

Conclusion

CRUD Todo App - React and Redux-toolkit

Introduction

Why Redux?

Redux vs ReduxToolkit

How Redux works

The five major terminologies in Redux:

Implementation

Installation

Create a Redux Store

Add the Redux Store to Index.js parent file

Create a Slice

The Configuration: `staleTime` vs `gcTime`

1. `staleTime` (The "Freshness" Timer)

2. `gcTime` (The "Garbage Collection" Timer)

1. The Rules: `Cache-Control`

`max-age` (The Timer)

`no-cache` vs `no-store` (The Great Confusion)

2. The Receipt System: `ETags` and `Last-modified (304)`