DEV Community: Peter Ogbonna

Go + templ + HTMX + Tailwind CSS v4 setup in 2026

Peter Ogbonna — Thu, 03 Sep 2026 13:40:50 +0000

I only wanted to style a Go application.

Somehow, I ended up reading tutorials that asked me to run commands Tailwind no longer supports, create configuration files Tailwind v4 no longer needs, and install Node.js for a project that otherwise had nothing to do with Node.js.

After enough dead ends, I found a setup I actually enjoy: Go renders the application, templ gives me typed HTML components, HTMX adds focused interactions, and Tailwind's standalone executable compiles the CSS. No frontend framework and no node_modules directory.

This is the guide I wish I had found.

Why this boring stack is interesting
Where templ fits
A tiny HTMX example
Three ways to add Tailwind
The standalone setup
The commands you will actually use
Example repo
References

Why this boring stack is interesting

I mean boring affectionately :)

The browser sends an HTTP request. Go runs ordinary application code. A templ component renders HTML. HTMX can place a returned fragment into the page. Tailwind compiles the utility classes it finds into a static stylesheet.

There is one main programming language, one server, and HTML remains the application boundary. You do not need a client-side state store just to submit a form or refresh a list.

This stack is especially pleasant for content sites, dashboards, admin tools, CRUD applications, and small products where most interactions naturally map to HTTP requests.

It is not the answer to everything. A browser-based design tool or highly offline application may benefit from a substantial client-side runtime. But many applications are much closer to “request data, change data, render HTML” than their architecture admits.

Where templ fits

Go already has html/template, and it is good. It is in the standard library, widely understood, and performs contextual escaping to produce HTML safely. You do not need templ because the standard library is broken.

I use templ because I prefer its development model for component-heavy interfaces and type system.

Here is a small component:

package views

templ Greeting(name string) {
    <section class="rounded-xl border border-slate-200 p-6">
        <h1 class="text-2xl font-bold">Hello, { name }.</h1>
        <p class="mt-2 text-slate-600">Your page came from Go.</p>
    </section>
}

templ turns this into Go code. The component has a typed parameter, can call other components, and can use familiar Go control flow. Misspell a field or pass the wrong type and the compiler can catch the mistake before the page reaches a user.

The trade-off is code generation: after changing a .templ file, you generate its corresponding Go source.

go tool templ generate

For Go 1.24 and newer, I prefer tracking the generator as a project tool:

go get github.com/a-h/templ
go get -tool github.com/a-h/templ/cmd/templ@latest
go tool templ generate

or you can just install globally and use everytime:

go install github.com/a-h/templ/cmd/templ@latest
templ generate

A tiny HTMX example

templ renders HTML, HTMX decides when a part of the page should ask the server for new HTML.
visit the setup, download the htmx.min.js and put in your public folder

templ GreetingPanel() {
    <section id="greeting">
        <button
            class="rounded-lg bg-emerald-800 px-4 py-2 text-white"
            hx-get="/greeting"
            hx-target="#greeting"
            hx-swap="outerHTML">
            Greet me
        </button>
    </section>
}

templ Greeting() {
    <section id="greeting" class="rounded-xl bg-emerald-50 p-5">
        <p class="font-semibold text-emerald-950">Hello from the server.</p>
    </section>
}

The button means: send GET /greeting, take the HTML response and replace the element identified by #greeting.

http.HandleFunc("GET /greeting", func(w http.ResponseWriter, r *http.Request) {
    if err := views.Greeting().Render(r.Context(), w); err != nil {
        http.Error(w, "could not render greeting", http.StatusInternalServerError)
    }
})

There is no JSON response to decode and no duplicate client-side component to keep in sync. The server returns the next piece of UI.

That is the useful boundary in this stack:

Go owns application state and decisions.
templ owns reusable HTML.
HTMX requests and swaps HTML fragments.
Tailwind owns presentation.

Three ways to add Tailwind

Path 1: the Play CDN

The fastest possible experiment is Tailwind's browser package:

<script src="https://cdn.jsdelivr.net/npm/@tailwindcss/browser@4"></script>

Add that to the page and Tailwind classes work without a build command.

While the CDN approach is extremely simple, you may want to consider not using CDNs in production.

That article discusses broader privacy, security, reliability, and performance trade-offs of third-party JavaScript CDNs. Tailwind's own documentation is more direct about this particular package stating that the Play CDN is designed for development, not production.

Path 2: npm or pnpm

The official package-manager route is entirely valid:

npm install --save-dev tailwindcss @tailwindcss/cli
npx @tailwindcss/cli -i ./views/css/styles.css -o ./public/styles.css --watch

Or with pnpm:

pnpm add -D tailwindcss @tailwindcss/cli
pnpm exec tailwindcss -i ./views/css/styles.css -o ./public/styles.css --watch

This gives you normal dependency declarations and a lockfile, and updates fit the JavaScript package-management workflow. If the project already uses npm for other frontend tooling, this is a fair choice.

The downside in a Go only project is that Tailwind introduces an additional toolchain: Node.js, a package.json, a lockfile, install commands in CI, and a local node_modules directory. You normally ignore node_modules rather than commit it, but it still exists on each development machine and build environment.

None of that is catastrophic, it was simply machinery I did not otherwise need.

Path 3: The standalone executable (recommended)

Tailwind also publishes a self-contained CLI for Linux, macOS, and Windows. It performs the build ahead of time and emits an ordinary CSS file, without requiring Node.js or npm on your machine.

That is the path I use.

The Standalone Setup

1. Download the correct binary

Open the official Tailwind CSS releases page and choose the executable for your operating system and CPU and download.

2. Put it somewhere sensible

You have two good options.

Keep it inside the project, for example in ./bin/tailwindcss, and invoke that exact path:

./bin/tailwindcss -i ./views/css/styles.css -o ./public/styles.css --watch

Or put it in a directory already on your PATH, so you can run tailwindcss anywhere.

Go developers often already have their Go tool directory on PATH. Find the location with:

go env GOPATH

For Linux users that becomes $HOME/go/bin and %USERPROFILE%\\bin for windows users. Copying Tailwind executable there saves a separate PATH change only if that directory is already on your PATH, else add the folder to PATH

3. Create the Tailwind entry file

Here is the entire minimum Tailwind v4 entrypoint:

/* views/css/styles.css */
@import "tailwindcss";

It does not require tailwind.config.js or tailwindcss init for the basic setup. Tailwind v4 moved toward CSS-first configuration.

If you execute the build from your repository root, automatic source detection will usually find the class names in your .templ files and generate the plain css which you'll hook up to your <link /> tag

4. Compile the stylesheet

During development:

tailwindcss -i ./views/css/styles.css -o ./public/styles.css --watch

For a production build:

tailwindcss -i ./views/css/styles.css -o ./public/styles.css --minify

The browser receives /public/styles.css; it never knows or cares how that file was produced.

The commands you will actually use

Once everything is installed, the working loop is small:

# Generate Go code from .templ files once
go tool templ generate

# Regenerate templates as they change
go tool templ generate --watch

# Rebuild CSS as Tailwind classes change
tailwindcss -i ./views/css/styles.css -o ./public/styles.css --watch

# Run the Go application
go run .

Run the watchers in separate terminals, or let a task runner coordinate them, a small Makefile is enough

The Tailwind watcher rebuilds CSS and it does not restart your Go process, templ provides its own reload workflow.

templ/tailwind rebuild, server restart, and browser reload are three different jobs.

I also put together a complete example repository containing this setup:

Browse the example Go + templ + HTMX + Tailwind v4 repository

References

Manage State like a Pro: Frontend Edition

Peter Ogbonna — Thu, 20 Aug 2026 16:32:06 +0000

AI models write code better and faster than devs, but what AI cannot do reliably for your specific product is make the fundamental system design decisions like:

"Where should this piece of data actually live, who owns it, and what happens to the user experience when the network fails, the user refreshes, or a link is shared?"

The modern frontend engineer’s primary value has shifted from writing code to evaluating trade-offs.

If you put every piece of data into a global Redux store or local useState, you aren't just writing messy code, you are making a system design error. To build fast, resilient interfaces, you need to treat state management as a distribution problem across three distinct domains: Server State, Client State, and URL State.

Take a look at this example

You must have come across this type of code before...

// Wrong: Blending 3 different types of state into one

const [products, setProducts] = useState([]); // Server Data
const [searchQuery, setSearchQuery] = useState(""); // URL/Navigation Intent
const [isFilterModalOpen, setIsFilterModalOpen] = useState(false); // Local UI

useEffect(() => {
  // Syncing server state based on local client variables
  fetchProducts(searchQuery).then(setProducts);
}, [searchQuery]);

When you mix these together, your application breaks down in subtle, frustrating ways:

Stale Data: You manually fetch server data, cache it in React memory, and forget to revalidate it when the database changes.
State Blackout: The user customizes their search view, hits refresh, and gets reset to page one because the view state only lived in ephemeral browser memory
Bloated Memory: Temporary UI toggles (like "is dropdown open") leak into global stores, making the app harder to debug and test.

To fix this, we need to categorize data by ownership and lifecycle, not just syntax.

The 3 Pillars of Frontend State Architecture

┌─────────────────┬───────────────────────────────┬──────────────────────────────────┐
│ State Category  │ What It Really Is             │ Best Tooling / Pattern           │
├─────────────────┼───────────────────────────────┼──────────────────────────────────┤
│ 1. Server State │ External data owned by the DB │ Next.js Cache, TanStack Query,   │
│                 │ (Async, cached, shared)       │ RTK Query, SWR                   │
├─────────────────┼───────────────────────────────┼──────────────────────────────────┤
│ 2. URL State    │ Navigation intent             │ `searchParams`, React Router,    │
│                 │ (Shareable, persistent)       │ `window.location`                │
├─────────────────┼───────────────────────────────┼──────────────────────────────────┤
│ 3. Client State │ Ephemeral UI memory           │ `useState`, `useReducer`,        │
│                 │ (Local, temporary, interactive)│ Zustand, React Context            │
└─────────────────┴───────────────────────────────┴──────────────────────────────────┘

1. Server State: You Don't Own It

The Mental Model: Server state is data that lives on a remote database (user profiles, product lists, checkout carts). You do not own this data on the client - you're merely borrowing a temporary snapshot of it.

Because server state is asynchronous and shared across multiple users, its main challenges are staleness, caching, deduplication, and revalidation.

When to use it: Any data that originates from a database or external API.
How to manage it: Stop putting API response data into local useState or traditional Redux stores. Use dedicated server-state tools like TanStack Query, SWR, or Next.js Server Components with Data Caching.

// Right: Server state managed by a tool built for caching & revalidation
const { data: user, isLoading } = useQuery({
  queryKey: ['user', userId],
  queryFn: () => fetchUser(userId),
  staleTime: 1000 * 60 * 5, // 5 minutes before re-fetching
});

2. URL State: The Forgotten Source of Truth

The Mental Model: URL state is the input parameter for your entire screen. It represents navigation intent, what specific view, page, or filtered slice of data the user wants to see right now.

If a user configures a complex search filter on an e-commerce site, that view should exist as a shareable link. If you trap those filters inside React’s useState, you strip the web of its best native feature: the link.

When to use it: Search queries, category filters, pagination numbers, active tabs, sorting directions, and selected view modes (grid vs. list).
How to manage it: Sync UI controls directly to URL search parameters (?search=shoes&page=2).

// URL State as the single source of truth for view parameters
export default async function CatalogPage({ searchParams }) {
  const { category, page } = await searchParams;

  // The server/API reads directly from the URL context
  const products = await getProducts({ category, page: Number(page) || 1 });

  return <ProductGrid products="{products}"/>;
}

3. Client State: Ephemeral UI Memory

The Mental Model: Client state is purely local, temporary UI memory. It does not come from a database, and it doesn't need to survive a page share or a browser refresh.

If the user closes the tab, this data can safely disappear without ruining their experience.

When to use it: Modal open/close toggles, hover states, active tab animations, form input drafts before submission, dark mode toggles, and multi-step wizard progress.
How to manage it: Keep it close to where it's used with useState or useReducer. If it needs to be accessed globally across unrelated components (like a sidebar collapse state), use a lightweight client store like Zustand.

// Simple, isolated local client state
const [isSidebarOpen, setIsSidebarOpen] = useState(false);

Evaluating the Trade-offs

When designing a feature, ask yourself these three sequential questions to determine where state belongs:

                     [New Piece of State]
                              │
              Does it come from an API/Database?
             ┌────────────────┴────────────────┐
            YES                                NO
             │                                 │
     (1. SERVER STATE)              Should this view be shareable 
  Use: Next.js / TanStack           or survive a page refresh?
                                   ┌───────────┴───────────┐
                                  YES                      NO
                                   │                       │
                            (2. URL STATE)          (3. CLIENT STATE)
                          Use: searchParams        Use: useState / Zustand

Practical Example - an E-Commerce Product Page

The Product List Data: This is server state. It should be fetched and cached via server components or a query hook so it can revalidate in the background.
The Active Category & Search Term: This is URL state (/products?category=shoes&q=nike). If the user emails this link to a friend, the friend sees the exact same Nike shoes.
The "Filter Drawer Open" Toggle: This is client state The friend doesn't need the filter drawer to automatically pop open just because the sender had it open.

Conclusion

Writing syntax is rapidly becoming an automated commodity. You can prompt an AI tool to write a complex reducer or a fetch handler in seconds.

However, choosing where state lives, how it expires, and how it travels across the network requires engineering judgment.

By cleanly separating your architecture into Server State (remote truth), URL State (navigation truth), and Client State (interactive truth), you build applications that are inherently faster, far more resilient, and built to scale.

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

Go + templ + HTMX + Tailwind CSS v4 setup in 2026

Table of contents

Why this boring stack is interesting

Where templ fits

A tiny HTMX example

Three ways to add Tailwind

Path 1: the Play CDN

Path 2: npm or pnpm

Path 3: The standalone executable (recommended)

The Standalone Setup

1. Download the correct binary

2. Put it somewhere sensible

3. Create the Tailwind entry file

4. Compile the stylesheet

The commands you will actually use

References

Manage State like a Pro: Frontend Edition

Take a look at this example

The 3 Pillars of Frontend State Architecture

1. Server State: You Don't Own It

2. URL State: The Forgotten Source of Truth

3. Client State: Ephemeral UI Memory

Evaluating the Trade-offs

Practical Example - an E-Commerce Product Page

Conclusion

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 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)`