DEV Community: Ogasawara Kakeru

Next.js ~Prefetching~

Ogasawara Kakeru — Sun, 18 Oct 2026 02:51:43 +0000

In this section, I gann talk about story about App Router that is enabled to use Cache Components + Partial Prefetching (cacheComponents: true and partialPrefetching: true are set in next.config.ts). New app that is created by create-next-app is enabled to use them by default.

Default action

Router prefetches each routes of App Shell automatically.
App Shaell includes static contents and session data from cookies() and headers().
App Shell is a static shell (HTML + RSC payload) in which the URL-dependent portions have been replaced with a fallback.

In case of `<Link prefetch={true}>`

If URL to navigation (searchparamsor dinamic parms)is comfirmed, the root of component tree is re-renderd.
And then, three prefetches followed are included.
- A fallback of <Suspense>: Parts that are not cached remains as a fallback, and are streamed when requesting.
- use cache: private:Runs in server, and is cached in browser.
- use cache that is passed as a param of runtime value.

Example

If prefetch a link to /search?q=shoes, searchParams is resolved from link of URL, cached result of search() is prepared before click. Browser re-uses it untill stale time has passed or searchParams has been changed.

Additional Information

The cached data that is prefetched is treated as fresh data during term of stale.
Refferencies: Adopting Partial Prefetching / Optimizing prefetching / prefetch refference

Next.js ~revalidatePath vs revalidateTag ~ A Practical Guide to On-Demand Cache Invalidation

Ogasawara Kakeru — Sat, 10 Oct 2026 02:30:34 +0000

Why on-demand revalidation matters

A blog is the ideal candidate for caching: posts change rarely, but they are read constantly. Next.js lets you serve pages from the cache fir speed, and then gives you two fuctions, revalidatePath and revalidateTag, to throw away stale content the moment something changes.

Without them you are stuck with two weak options. You can set a time-based revalidate interval and accept that a typo fix may take minutes or hours to appear. Or you can redeploy the whole site every time you edit a post.

In this article we will look at what each function does, how to wire it into a real blog, how updateTag fits in since Next.js 16, and how to decide which one to reach for.

The mental model: pages and tags

Next.js caches your data and your rendered pages, and you can invalidate that cache from two directions: by the URL that shows the content, or by a label attached to the data itself.

revalidatePath works from the URL side. You say "this page is stale."
revalidateTag works from the data side. You say "everything built from this data is stale."

Tags are attached where you fetch or cache data. With fetch, you pass them in the next options:

// lib/posts.ts
export async function getPosts() {
  const res = await fetch('https://cms.example.com/posts', {
    next: { tags: ['posts'] },
  })
  return res.json()
}

export async function getPost(slug: string) {
  const res = await fetch(`https://cms.example.com/posts/${slug}`, {
    next: { tags: ['posts', `post-${slug}`] },
  })
  return res.json()
}

If you use Cache Components (cacheComponents: true) and the use cache directive, you attach tags with cacheTag instead:

import { cacheTag } from 'next/cache'

export async function getPost(slug: string) {
  'use cache'
  cacheTag('posts', `post-${slug}`)
  // ...query your database or CMS
}

Notice that a single post carries two tags: a broad one (posts) and a specific one (post-my-slug). That small habit pays off later.

revalidatePath: refresh a specific page

revalidatePath invalidates cached data for one path, so the next visit to that page gets fresh content. It is the most direct tool when you know exactly which URL changed.

import { revalidatePath } from 'next/cache'

revalidatePath('/blog')                 // the blog index
revalidatePath('/blog/my-first-post')   // one specific post

You can call it from a Server Action or a Route Handler. It does not return a value.

Dynamic routes and the type argument

Blog posts usually live at a dynamic route like /blog/[slug]. You have two ways to target them. Pass the concrete URL to refresh one post, or pass the route pattern with a second argument to refresh every post at once:

revalidatePath('/blog/[slug]', 'page')    // every post page
revalidatePath('/blog/[slug]', 'layout')  // the layout and everything beneath it
revalidatePath('/', 'layout')             // the whole site

The second argument is 'page' or 'layout'. It is required when the first argument contains a dynamic segment, and optional for a plain URL. Use 'layout' sparingly: invalidating '/' with 'layout' clears the entire site.

What it does not do

It only refreshes the paths you name. If the same post title also appears on your homepage, an RSS feed, a tag archive and a "related posts" sidebar, each of those paths needs its own call, or a different tool. That limitation is exactly where revalidateTag comes in.

revalidateTag: refresh everything built from some data

revalidateTag invalidates cached data by label, across every page that uses it. You tag the data once, and a single call refreshes the index, the post page, the RSS route and anything else that read it.

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

export async function publishPost(slug: string) {
  // ...save the post to your database or CMS

  revalidateTag('posts', 'max')          // lists, archives, feeds
  revalidateTag(`post-${slug}`, 'max')   // this one post
}

The second argument in Next.js 16

In Next.js 15, the signature is revalidateTag(tag). In Next.js 16, revalidateTag takes a second argument: a cache-life profile such as 'max'. With a profile, the tag is marked stale and visitors keep getting the cached version while a fresh one is generated in the background (stale-while-revalidate). The single-argument form is deprecated, so pass a profile in new code. Check the revalidateTag reference for the profiles available in your version.

Why the broad-plus-specific tag habit works

Because each post carries both posts and post-<slug>, you choose how wide to go at invalidation time:

Edited one post's body: invalidate post-<slug>.
Published or deleted a post: invalidate posts, so every list updates.

You never have to remember which pages show which posts.

updateTag: when the author must see the change immediately

updateTag is a Next.js 16 function for Server Actions that makes the very next render show fresh data, so the person who just saved sees their own edit right away.

Picture an admin form where you hit "Save" on a post and get redirected to it. With stale-while-revalidate, revalidateTag might show you the old version for one more load, which feels like the save failed. updateTag avoids that.

// app/admin/actions.ts
'use server'
import { updateTag } from 'next/cache'
import { redirect } from 'next/navigation'

export async function savePost(slug: string, formData: FormData) {
  // ...write the changes to your database

  updateTag(`post-${slug}`)
  redirect(`/blog/${slug}`)
}

The trade-off is scope. Unlike revalidateTag, updateTag can only be used in Server Actions, so it will not work in a Route Handler such as a CMS webhook. A simple rule of thumb:

Someone is waiting on the result in your own UI: updateTag.
Background or external trigger, where a brief stale period is fine: revalidateTag.

Choosing between them

For most blogs, tags should be your default and paths your shortcut. A new post touches many pages, and tagging the data means you never have to list every URL that displays it.

	`revalidatePath`	`revalidateTag`	`updateTag`
Targets	A URL or route pattern	Any data carrying the tag	Any data carrying the tag
Reach	Only the named path	Every page using the tag	Every page using the tag
Where you set it up	Nothing to prepare	`next: { tags }` or `cacheTag`	`cacheTag`
Callable from	Server Actions, Route Handlers	Server Actions, Route Handlers	Server Actions only
Freshness	Next visit to that path	Stale-while-revalidate with a profile (Next.js 16)	Immediate, read-your-own-writes
Best blog use	One-off page fix, site-wide layout change	New or edited post via CMS webhook	Admin "Save" button

Some concrete blog scenarios:

You fixed a typo in one post: revalidateTag('post-<slug>', 'max'), or revalidatePath('/blog/<slug>') if you do not use tags.
You published a new post: revalidateTag('posts', 'max') so the index, archives, homepage and feed all update.
You changed the site navigation or footer: revalidatePath('/', 'layout').
You saved a post from your admin page: updateTag('post-<slug>').

You can also combine them in one action: a tag for the data, plus a path for a page that is built from data you did not tag.

Putting it together: a blog with a CMS webhook

A complete setup needs three pieces: tagged data fetching, a protected webhook that your CMS calls on publish, and optionally a Server Action for your own admin UI.

1. Tag your data

// lib/posts.ts
const CMS = process.env.CMS_URL!

export async function getPosts() {
  const res = await fetch(`${CMS}/posts`, { next: { tags: ['posts'] } })
  return res.json()
}

export async function getPost(slug: string) {
  const res = await fetch(`${CMS}/posts/${slug}`, {
    next: { tags: ['posts', `post-${slug}`] },
  })
  return res.json()
}

2. Revalidate from a webhook

Most headless CMS products can send an HTTP request when content is published. Point it at a Route Handler and verify a shared secret before touching the cache:

// app/api/revalidate/route.ts
import { revalidateTag, revalidatePath } from 'next/cache'
import { NextRequest, NextResponse } from 'next/server'

export async function POST(req: NextRequest) {
  const { secret, slug } = await req.json()

  if (secret !== process.env.REVALIDATE_SECRET) {
    return NextResponse.json({ error: 'Invalid secret' }, { status: 401 })
  }

  revalidateTag('posts', 'max')
  if (slug) revalidateTag(`post-${slug}`, 'max')

  // A page built from untagged data, such as a hand-written about page
  revalidatePath('/about')

  return NextResponse.json({ revalidated: true, now: Date.now() })
}

The secret check matters. Without it, anyone who finds the URL can purge your cache repeatedly and force your site to rebuild pages on demand.

3. Use updateTag in your own admin form

If you also edit posts through your own UI, use the Server Action from earlier so you see your changes instantly. The CMS webhook and the admin action both target the same tags, so every page stays consistent regardless of where the edit came from.

Common gotchas

Most revalidation bugs come from a handful of repeat mistakes.

Calling them in the wrong place. These functions run on the server, in Server Actions or Route Handlers. They do not work in Client Components.
Testing only in development. Caching behaves differently under next dev. Verify with next build && next start.
Expecting instant regeneration. Revalidation marks content stale. Fresh content is produced on the next visit, not at the moment you call the function.
Forgetting the dynamic-route type. revalidatePath('/blog/[slug]') without 'page' or 'layout' will not do what you expect.
Using only broad tags. If every fetch uses posts, every edit refetches everything. Add a per-post tag like post-<slug>.
Leaving the webhook open. Always verify a secret, and avoid logging it.
Revalidating '/' with 'layout' out of habit. It works, but it throws away your entire cache. Keep it for genuinely site-wide changes.

Tags are also easy to mistype. Define them in one small helper so both your fetch code and your invalidation code share the same strings:

// lib/tags.ts
export const tags = {
  posts: 'posts',
  post: (slug: string) => `post-${slug}`,
}

Conclusion

revalidatePath and revalidateTag solve the same problem from opposite ends. revalidatePath says "refresh this page," and revalidateTag says "refresh everything built from this data." For a blog, where one post shows up on many pages, tagging your data and invalidating by tag is the approach that scales.

Start with this recipe: tag every fetch with a broad tag and a per-item tag, call revalidateTag from a secured CMS webhook, use updateTag in your own admin actions, and keep revalidatePath for one-off fixes and layout-wide changes. Your readers get cached speed, and your edits go live when you say they do.

React.js ~Testing Accesibility of Fragment Refs~

Ogasawara Kakeru — Wed, 07 Oct 2026 12:15:46 +0000

Testing Accessibility with Fragment Refs

In my previous post, I introduced Fragment Refs. A reader pointed out that removing wrapper elements is nice, but accessibility needs careful testing. So let's actually test it.

1. What I want to check

Fragment Refs let you control a group of sibling DOM nodes without a wrapper element. Because the DOM structure stays flat, I want to check two things:

Does focus() move focus to the element I expected?
Does the tab order stay natural?

I did not test with a screen reader in this post.

2. Test setup

import { Fragment, useRef } from 'react';

function Sections({ posts }) {
  const fragmentRef = useRef(null);

  return (
    <>
      <button onClick={() => fragmentRef.current.focus()}>
        Focus the first heading
      </button>

      <Fragment ref={fragmentRef}>
        {posts.map((post) => (
          <h2 key={post.id} tabIndex={0}>
            {post.title}
          </h2>
        ))}
      </Fragment>
    </>
  );
}

I tested with React 19.3.0-canary-17eca7b0-20261006 in jsdom.

3. Results

Check	Result
`focus()` target	The first `<h2>` (`focusLast()` moves focus to the last one)
Tab order	Natural: button → h2 → h2 → h2, following DOM order

The DOM stays flat (<button>…</button><h2>…</h2><h2>…</h2>…), so no wrapper element appears in the tab order.

4. Pitfalls I found

Elements without tabIndex can't receive focus, so focus() skips them. If no child is focusable, nothing happens, and no error or warning is shown.
When the fragment has zero children, focus() does nothing and doesn't throw.
tabIndex={0} on a heading adds it to the tab order even though it isn't interactive. If you only need programmatic focus, use tabIndex={-1}: focus() still works, and the headings drop out of the tab order.

5. Conclusion

Fragment Refs keep the DOM flat, and in my tests focus() moved focus to the first focusable sibling and the tab order followed DOM order. The main risk is silent failure: if no child is focusable, focus() does nothing and reports nothing. So when the siblings are interactive, check that at least one child can actually receive focus. Screen reader behavior is not covered here and needs separate testing.

Next.js ~Cache Systems~

Ogasawara Kakeru — Sun, 04 Oct 2026 10:47:32 +0000

The cache systems of Next.js(especially App Router) are made to allow you to optimize performance and minimize data transfer costs.

Eventhough those systems are strong, it matters to put four cache layers in order to avoid unexpected behavior (e.g. data not updating).

💡 Four cache layers in Next.js

In Next.js, there are three caches in server component and one cache in client component.

Cache Name	Storage Location	What Is Cached	Purpose / Feature	Lifetime (Timing)
① Request Memoization	Server	Return values of `GET` fetch requests.	Automatically combines multiple API calls with the same path and arguments into a single call to prevent duplicate fetches during one render pass.	Single request lifetime. Disappears completely after the page finishing rendering.
② Data Cache	Server	Data fetched from external APIs or databases.	Reduces the number of direct hits to your database or third-party APIs across multiple user requests.	Persistent indefinitely by default (survives redeploys). Can be revalidated via time-based rules or on-demand tags.
③ Full Route Cache	Server	Page's HTML and RSC Payload	Generates static pages at build time or during background revalidation to drastically improve initial page load speed.	Persistent until the next redeploy or until its underlying Data Cache is updated/invalidated.
④ Router Cache	Client	RSC Payload for navigated pages	Ensures pages switch instantly on the client side without layout shifts or delay when users click links or go back/forward.	Session-only. Clears completely upon hard reload, or after a specific period of inactivity (depends on dynamic/static route types).

⚙️ Details for each caches and how to control them.

① Request Memoization（prevent redundant API calls）

When render a single page, eventhough multiple components call the same fetch('/api/user') , React combines them into a singlr call automatically.

Advantage: Need not to do props drilling
Caution: This is only a fuction of React and is applied to fetch (GET). axios or query for DB are not eligible. If you want to combine them, you have to wrap them with cache() .

② Data Cache（Permanent Cache for data）

Server caches data fetched by API.

Updating Cache: It is updated using the revalidatePath and revalidateTag methods introduced earlier, or by specifying a time interval (ISR) such as fetch(url, { next: { revalidate: 3600 } })

③ Full Route Cache（Staticization During Building）

Next.js caches the entire page as a static HTML when judged that the page doesn't have any dynamic data-such as cookies or search parameters.

How to Disable: If you use imformation that is only known at the time of request-such as cookies() or headers()-in your code(Dynamic Function), this cache will be automaticlly bypassed, and the page will be rendered dynamically.

④ Router Cache（Speeding Up Browser Back Button Functionality, etc.）

Hold the imformation of the route temporarily on the browser.

How to Disable: If you execute revalidatePath in the server action, Cache is cleared and the screen is rewriteen.

⚠️ 【IMPORTANT】A big change in Next.15

Previous versions of Next.js (such as v14) were based on the philosophy of “aggressively caching everything by default (opt-out approach),” which led to confusion among developers who found that “the data isn’t updating!”

Since old Next.js(v14 or so.) had a theory that "Cache everything strongly as default(Opt-out format)", this used to cause confusings that "Data isn't cached".

In Next.js 15, defalt has been changed to "Non-cache(Opt-in format)".

fetch isn't cached by default

In classic Next.js, fetched data is cached automatically. However, From Next.js 15, requests run every rendering until you define { cache: 'force-cache'} .
Route Handlers of GET is no longer cached by default

Mordan APIs in Route Handler such as /api/time request everytime.
Default actions of Router Cache in client has been cahnged

If you navigate to other pages, data used to be stable in 30 seconds in browser. However, in Next.js15, data isn't cached by default and latast dat a is displayed on the screen.

React.js ~New feature in React 19.3~

Ogasawara Kakeru — Tue, 29 Sep 2026 12:08:11 +0000

Let's dive into new features in React.js 19.3

1.View Transitions

Basic usage

View Transitions is the <ViewTransition> component that Animates Adding and Removing Elements, transition, and sizing.

import { ViewTransition, useState, startTransition } from 'react';

export default function Component() {
  const [showItem, setShowItem] = useState(false);

  return (
    <>
      <button
        onClick={() => {
          startTransition(() => {
            setShowItem((prev) => !prev);
          });
        }}>
        {showItem ? '➖' : '➕'}
      </button>

      {showItem && (
        <ViewTransition>
          <Video video={videos[0]} />
        </ViewTransition>
      )}
    </>
  );
}

Example of defining the type of the transition

Different animations (e.g. enter, exit, update, share) are applied automatically.

Case that multiple animations are needed：

import { ViewTransition, addTransitionType, useState, startTransition } from 'react';

export default function Carousel() {
  const [selected, setSelected] = useState(0);

  return (
    <>
      <button
        onClick={() => {
          startTransition(() => {
            addTransitionType('previous');
            setSelected(c => c > 0 ? c - 1 : videos.length - 1);
          });
        }}>
        ⬅️
      </button>

      <button
        onClick={() => {
          startTransition(() => {
            addTransitionType('next');
            setSelected(c => c + 1 < videos.length ? c + 1 : 0);
          });
        }}>
        ➡️
      </button>

      <ViewTransition
        enter={{
          'next': 'from-right',
          'previous': 'from-left'
        }}
        exit={{
          'next': 'to-left',
          'previous': 'to-right'
        }}
      >
        <Video video={videos[selected]} />
      </ViewTransition>
    </>
  );
}

Combination with Suspense

You can animate the transition from the fallback to the final content by wrapping boundary of Suspense with View Transition

import { Suspense, useState, startTransition, use, ViewTransition } from 'react';

export default function Component() {
  const [showItem, setShowItem] = useState(false);

  return (
    <>
      <button
        onClick={() => {
          startTransition(() => {
            setShowItem((prev) => !prev);
          });
        }}>
        {showItem ? '➖' : '➕'}
      </button>

      {showItem && (
        <ViewTransition update="auto" default="none">
          <Suspense fallback={<VideoPlaceholder />}>
            <LazyVideo />
          </Suspense>
        </ViewTransition>
      )}
    </>
  );
}

function LazyVideo() {
  const video = use(fetchVideo());
  return <Video video={video} />;
}

2.Fragment Refs

Basic usage

Using Fragment Refs enables low-level control over DOM nodes within a group of sibling elements that do not share a single parent DOM element.

import { Fragment, useRef, useEffect } from 'react';

function Component() {
  const fragmentRef = useRef(null);

  useEffect(() => {
    const fragmentInstance = fragmentRef.current;
    fragmentInstance.focus(); // Move the focus
  }, []);

  return (
    <Fragment ref={fragmentRef}>
      {posts.map(post => (
        <Heading key={post.id}>
          {post.title}
        </Heading>
      ))}
    </Fragment>
  );
}

An example of Usage

//InView Component
import { Fragment, useRef, useEffect, useSate } from 'react';

function InView({ onChange, children }) {
  const fragmentRef = useRef(null);

  useEffect(() => {
    const fragmentInstance = fragmentRef.current;
    const observer = new IntersectionObserver(([entry]) => {
      onChange(entry.isIntersecting);
    });

    fragmentInstance.observeUsing(observer);

    return () => {
      fragmentInstance.unobserveUsing(observer);
    };
  }, [onChange]);

  return <Fragment ref={fragmentRef}>{children}</Fragment>;
}

export default function App() {
  const [isVisible, setIsVisible] = useState(true);

  return (
    <div>
      <div>Scroll down</div>

      <InView onChange={setIsVisible}>
        <Card title="First section" />
        <Card title="Second section" />
      </InView>

      <div>Scroll up</div>
    </div>
  );
}

3.Browser API

Basic usage

Calling use(browser()) enables to exclude the component that depends on browser API from SSR.

import { Suspense, use } from 'react';
import { browser } from 'react-dom';

function TimeZone() {
  use(browser()); // This component becomes Suspense on the server, while runs normally on the client.

  const timeZone = new Intl.DateTimeFormat().resolvedOptions().timeZone;

  return <p>{timeZone}</p>;
}

export default function App() {
  return (
    <>
      <p>Your current time zone is:</p>
      <Suspense fallback="Loading...">
        <TimeZone />
      </Suspense>
    </>
  );
}

Use under certain condition

function TimeZone({ defaultValue }) {
  if (defaultValue) {
    return <p>{defaultValue}</p>; // If defaultValue exists, returns `p` tag
  }

  use(browser()); // Otherwise, executes the browser API.
  const localTimeZone = new Intl.DateTimeFormat().resolvedOptions().timeZone;

  return <p>{localTimeZone}</p>;
}

export default function App() {
  return (
    <>
      <div>
        <p>The event's time zone is:</p>
        <TimeZone defaultValue="America/New_York" /> {/* Rendering on the server */}
      </div>

      <hr />

      <div>
        <p>Your current time zone is:</p>
        <Suspense fallback="Loading...">
          <TimeZone /> {/* Running on the client */}
        </Suspense>
      </div>
    </>
  );
}

Use of useQuery

function useBrowserQuery(query, options) {
  if (options.initialData === undefined) {
    use(browser()); // If initialData doesn't exist, executes on browser.
  }

  return useQuery(query, options);
}

function ProductDetails({ productId, initialData }) {
  const product = useBrowserQuery(`/api/products/${productId}`, {
    initialData,
  });

  return <h1>{product.name}</h1>;
}

4.React Server Components - Improving Context

Before improving(Need wrapper component)

// user-context.js
'use client';
import { createContext } from 'react';

export const UserContext = createContext(null);

export function UserProvider({ currentUser, children }) {
  return <UserContext value={currentUser}>{children}</UserContext>;
}

// server-component.js
import { UserProvider } from './user-context';

export async function Layout({ children }) {
  const currentUser = await getCurrentUser();

  return (
    <UserProvider currentUser={currentUser}>
      {children}
    </UserProvider>
  );
}

After improving(Render Context directly)

You can render Context from 'use client' module on the server component directly without wrapper component(Provider).

// user-context.js
'use client';
import { createContext } from 'react';

export const UserContext = createContext(null);

// server-component.js
import { UserContext } from './user-context';

export async function Layout({ children }) {
  const currentUser = await getCurrentUser();

  return (
    <UserContext value={currentUser}>
      {children}
    </UserContext>
  );
}

React.js ~The Latest Ref Pattern ~

Ogasawara Kakeru — Sun, 20 Sep 2026 04:02:24 +0000

This pattern holds callback passed to a customhook in the ref and update existing value everytime rendered to have the latest value.

function useDebounce(callback, delay) {
  const callbackRef = React.useRef(callback)

  React.useLayoutEffect(() => {
    callbackRef.current = callback
  })

  return React.useMemo(
    () => debounce((...args) => callbackRef.current(...args), delay),
    [delay],
  )
}

This pattern is named by Yago Pereria. The above example describes the pattern by using useDebounce. Calling callbackref.current in the debounced function, the old function closed by closure is not called, but the latest callback is always called.

Why is ref used?
Because you need to have a latest value without re-rendering. If you hold the value in state, the component renderes everytime update the value and invokes infinite loop.

Dealing with Dependency Array

This is the main focus of the second half of the article. Eventhough you have to obey the exhaustive-deps rule basically, you must not place current of ref in the Dependency Array. Since updating ref does not trigger a re-render, React cannot detect changes to current and recalculate effects or memoized values, which leads to behavior that is difficult to debug. Because ref is stable, the result doesn't change if includes ref in the dependencies array or not.

After React19 is introduced, useEffectEvent was designed precisely to incorporate this pattern into the official API.
If you have access to that environment, , there may be situations where a handwritten “latest ref” is no longer necessary.

Do callbacks really get updated that often?

The key point here is not so much that “the contents of the callback are rewritten,” but rather that a different function object is created with each render.

function SearchBox() {
  const [query, setQuery] = useState('')
  const [filter, setFilter] = useState('all')

  const search = useDebounce(() => {
    fetch(`/api?q=${query}&filter=${filter}`)
  }, 500)
}

Although this arrow function appears only once in the source code, a new instance is created each time the page is rendered, and each instance encapsulates the current query and filter.
Since the query changes with every input, it effectively becomes a “different function” with every keystroke.

If you still hold the function that is generated in the first render, the function that runs is the function that watches query = "" and keeps searching blank. This is a typical bug of closure.

If you keep the initial render function as is, the function that checks the initial value query = ‘’ will be executed 500 ms later, and it will continue to search for an empty string indefinitely. This is a classic “stale closure” bug.

Well, why not just put it in the dependency array? But if you do that, the debounce will break.

return useMemo(() => debounce(callback, delay), [callback, delay])

Since the callback changes with every render, the debounced instance itself is recreated each time, and any pending timers are discarded. As a result, the delay is constantly reset, rendering the debounce ineffective.

In other words, there are two requirements, and they don't align.

I want the instance of debounce tp be stable(I don't want to re-invent the wheel) and I want the function in the instance to be up-to-date.

The ref is a tool to separate the two. Replace only the contens while preserving the identity of the outer function.

It seems possible to wrap that in the useCallback. In this way, user has a responsibility to manage array dependencies perfectly, and if even one is missed, it revertsto the same closure.

If the hook's authors handle it it using ref, it will work correctly even if users write it inline.

If you use it in the useEffect, the useEffectEvent that is introduced in React 19 solves this issue.
However, the usage for holding it outside of the effect is out of responsibility and latest ref pattern still holds good.

React.js ~The Latest Ref Pattern~

Ogasawara Kakeru — Mon, 07 Sep 2026 08:39:36 +0000

The Latest Ref Pattern is a simple design pattern that holds latest value or callback function without re-rendering.

Here is a basic implementation bellow:

const latestValueRef = React.useRef(value);
React.useLayoutEffect(() => {
  latestValueRef.current = value;
});

Pros

Excluding from dependency array: When you want to refer a latest value or callback function in the useEffect or custom hook, you can fetch them safely without dependency array.
Prevent unnecessary rendering: The useRef doesn't trigger unnecessary rendering, therfore it optimizes performance.

React.js ~Tips for making UI that is reusable and testable~

Ogasawara Kakeru — Sat, 05 Sep 2026 07:00:15 +0000

Compound Component Pattern

If you find yourself passing props through multiple layers of components, consider using the Compound Component Pattern.

The Compound Component Pattern is a powerful design pattern that is widely used in React applications. It can improve reusability, readability, and scalability.

This pattern builds a UI by combining multiple related child components under a shared parent component.

A familiar example is the element and its elements. These elements are designed to work together rather than independently. The element manages the selected value, while the elements represent the available choices.

Similarly, in the Compound Component Pattern, state is typically managed by the parent component and shared with its child components.

This pattern also establishes an implicit relationship between the parent and child components while still allowing consumers to customize the component structure.

Without the Compound Component Pattern

First, let’s implement a counter component without using the Compound Component Pattern.

You might notice that the component starts to become a little complicated because it has to manage the counter state, conditionally apply styles based on that state, and define the behavior of each UI element.

Counter.tsx

const Counter = () => {
  const { count, handleDecrementClick, handleIncrementClick } = useCounter();
  return (
    <>
      <p className="count">
        Count: <span className={count <= 10 ? "red" : ""}>{count}</span>
      </p>
      <button className="minus-button" onClick={handleDecrementClick}>
        -
      </button>
      <button className="plus-button" onClick={handleIncrementClick}>
        +
      </button>
    </>
  );
};

Using the Compound Component Pattern

Now, let’s implement the same component using the Compound Component Pattern.

You might notice that the component becomes much more declarative and easier to read.

Counter.tsx

const CounterExample = () => {
  const handleChangeCounter = (count: number) => {
    console.log("count", count);
  };
  return (
    <Counter onChange={handleChangeCounter}>
      <Counter.Label>
        Count: <Counter.Count max={10} />
      </Counter.Label>
      <Counter.Increment>+</Counter.Increment>
      <Counter.Decrement>-</Counter.Decrement>
    </Counter>
  );
};

With the Compound Component Pattern, each child component has a clear responsibility.

The parent component manages the shared state, while components such as , , and provide specific pieces of functionality.

As a result, users of the component can understand its structure directly from the JSX and can arrange the child components more flexibly without having to manage the internal state themselves.

React.js ~Tips for making UI that is reusable and testable~

Ogasawara Kakeru — Fri, 28 Aug 2026 13:42:33 +0000

In the previous article, I wrote about a single responsibility of HTML and CSS.
In this article, I'm goint to write about State Reducer Pattern.

Important thing to consider before adding new features.

Let's consider State Reducer Pattern before adding new features such as if statemant, parameter or return value to existing function

This might be unknown pattern. This pattern extends Inversion of Control Pattern that is expanded by Martin Fowler who is known as an author of Refactoring Book. Inversion of Control pattern is also known as “control inversion” or the Dependency Injection pattern.

State Reducer Pattern is invented by Kent C.Dodds who is also known as a creator of React Testing Library.

If you add a argument, option and conditional statement, you add new ones over and over again every time you implement them.

It doesn't matter once. However, when multiple time added by other developers, this component gets more complex.

This is State Reducer Pattern to prevent this case.

Here is a specific example of a use case.
We need to add new functionality to a count button on a page.
The existing count button works as follows:
When the plus button is clicked, the count increases by 1, up to a maximum of 5.
When the minus button is clicked, the count decreases by 1, down to a minimum of 0.
The new functionality we want to add is as follows:
When the plus button is clicked, the count increases by 1, up to a maximum of 10.
When the minus button is clicked, the count decreases by 2, down to a minimum of 0.
In a typical scenario, you would add arguments or conditional branching to useCounter() to define the maximum number of clicks allowed and the amount by which the count decreases with each click.

const useCounter = () => {
 const [state, dispatch] = useReducer(reducer, initialState);
   function reducer(state, action) {
     switch (action.type) {
       case "increment":
         return {
           count: Math.min(state.count + 1, 5)
         };
       case "decrement":
         return {
           count: Math.max(0, state.count - 1)
         };
       // Add new use case   
       case "decrement-two": 
         return {
           count: Math.max(0, state.count - 2)
         };
       default:
         throw new Error();
     }
   }

   const handleIncrementClick = () => {
     dispatch({ type: "increment" });
   };

   const handleDecrementClick = () => {
     dispatch({ type: "decrement" });
   };

   // Add a function for the new case   
   const handleDecrementTwoClick = () => {
     dispatch({ type: "decrement-two" });
   };

   return {
     count,
     handleIncrementClick,
     handleDecrementClick,
     handleDecrementTwoClick, // Add a return value to use in UI component
   }
}

However, the State Reducer pattern does not add logic to useCounter(); instead, it defines a reducer (logic) for a new use case within the Usage component (the child component that uses useCounter()) and passes it to useCounter() as an argument.
This allows you to add new functionality without affecting existing features or useCounter() itself.


const Usage = (): JSX.Element => {
  const reducer = (state: typeof initialState, action: ACTIONTYPE) => {
    switch (action.type) {
      case "decrement":
        return {
          count: Math.max(0, state.count - 2) //　Process that subtracts 2 each time the minus button is clicked (default: process that subtracts 1 each time the minus button is clicked)
        };
      default:
        return useCounter.reducer(state, action);
    }
  };

  const { count, handleDecrementClick, handleIncrementClick } = useCounter({
    state: { initial: 0, max: 10 },
    reducer
  });

  return (....) // Save

export const useCounter = ({
  state,
  // Modify existinf reducer to internalReducer
  reducer = internalReducer 
}: useCounterProps): useCounterReturnType => {
  const [{ count }, dispatch] = useReducer(reducer, { count: state.initial });

  const handleIncrementClick = () => {
    dispatch({ type: "increment", payload: { max: state.max } });
  };

  const handleDecrementClick = () => {
    dispatch({ type: "decrement" });
  };

  return {
    count,
    handleIncrementClick,
    handleDecrementClick
  };
};

useCounter.reducer = internalReducer;

If you find yourself adding conditional branching—such as if or switch statements—to existing functions, consider reversing the control flow by moving the logic from the parent component to the child component, rather than having the parent component use the logic in the child component.

React.js ~Tips for making UI that is reusable and testable~

Ogasawara Kakeru — Sat, 22 Aug 2026 01:57:52 +0000

If you participate in a project or see the codebases of OSS project, you come across UI to tackle complex specifications.

Here are specific cases below.

The bundle size is getting too large.
High maintenance and upkeep costs
- You have to ask what the component does.
- It is difficult to understand what the component does if you ask.
Low reusability
- There are too many criteria to use the component, and it follows that you make a similar one.
Complex API
- There are so many props that you can’t count them all on the fingers of one hand.
- It's hard to determine whether we can implement the use case using existing features.

To deal with these issues, here are some solutions bellow.

No.1 Weather HTML and CSS have a single responsibility.

<Button
  prefix={helpIcon}
  surfix={heartIcon} 
  hover={filledHelpicon}
  text="hello" 
  color="green" 
  primary={true}
  toolip={<Tooltip/>}
  onClick={handleClick}
  ...
/>

This is close to the extension of OBJ programming.
This Button component has multiple responsibilites such as rendering Icon component and Tooltip component in addition to rendering Button component itself.

Therefore, you should care for combining rather than extesion.
You should not pass them as props, but children.

<Button 
  primary
  onClick={handleClick}
>
  <HelpIcon/>
  <InnerText color="green">hello</InnerText />
  <HeartIcon />
</Button>

Furthermore, while JavaScript successfully separates concerns and responsibilities, I often see UIs where the roles of HTML and CSS are not separated—appearance, structure, interactions, and spacing are all implemented using a single selector and deeply nested CSS.
To tackle complex specifications, we must implement HTML and CSS in accordance with the Single Responsibility Principle. Being mindful of the Single Responsibility Principle will also help reduce redundant and unnecessary CSS.

React.js ~useEffect memoization pattern for preventing unnecessary rendering~

Ogasawara Kakeru — Fri, 07 Aug 2026 20:47:21 +0000

This pattern is memoization with React.memo. This is known as optimization among React developer.

React.memo reuses a memoiszed component without rerendering if it is necessary in comparison between current Props and previous one.

In the demo below, even though the name state changes and the <App /> component re-renders, the props passed to the <SuperSlowComponent /> component do not change, so <SuperSlowComponent /> does not re-render.

import { memo, useState } from "react";

function SuperSlowComponent() {
  const now = performance.now();
  while (performance.now() - now < 200) {}
  return (
    <>
      <div>Super slow component</div>
    </>
  );
}

const MemoSupserSlowComponent = memo(SuperSlowComponent);

export default function App() {
  const [name, setName] = useState("");

  return (
    <div className="app">
      <label htmlFor="name">Name</label>
      <input
        id="name"
        type="text"
        value={name}
        onChange={(e) => setName(e.target.value)}
      />
      <MemoSupserSlowComponent />
    </div>
  );
}

React.js ~Liftup Pattern for Preventing unnecessary rendering~

Ogasawara Kakeru — Tue, 04 Aug 2026 19:57:53 +0000

Liftup Pattern
In contrast to the liftdown pattern,the pattern that lifts up a part of component that depends on the state can prevents unnecessary rendering.
An example below shows <SuperSlowComponent/> when hide is typed in the form.

import { useState } from "react";

function SuperSlowComponent() {
  const now = performance.now();
  while (performance.now() - now < 200) {}
  return <div>Super slow component</div>;
}

function Form({ name, setName }) {
  return (
    <>
      <label htmlFor="name">Name</label>
      <input
        id="name"
        type="text"
        value={name}
        onChange={(e) => setName(e.target.value)}
      />
    </>
  );
}

export default function App() {
  const [name, setName] = useState("");
  return (
    <div className="app">
      <Form name={name} setName={setName} />
      {name !== "hide" && <SuperSlowComponent />}
    </div>
  );
}

This method invokes rerendering the slow component everytime you type values in the field. For now, let's go back to managing useState in the <Form /> component instead of calling it from <App />.

By using liftup pattern, The difference from liftdown pattern is passing the slow component as a children. Since children is simply a prop, it is not affected by changes in state and therefore will not be re-rendered.

import { useState } from "react";

function SuperSlowComponent() {
  const now = performance.now();
  while (performance.now() - now < 200) {}
  return <div>Super slow component</div>;
}

function Form({ children }) {
  const [name, setName] = useState("");

  return (
    <>
      <label htmlFor="name">Name</label>
      <input
        id="name"
        type="text"
        value={name}
        onChange={(e) => setName(e.target.value)}
      />
      {name !== "hide" && children}
    </>
  );
}

export default function App() {
  return (
    <Form>
      <SuperSlowComponent />
    </Form>
  );
}

As a variation of the lift-up pattern, there is also a pattern where components are passed as Props instead of being passed as children.

import { useState } from "react";

function SuperSlowComponent() {
  const now = performance.now();
  while (performance.now() - now < 200) {}
  return <div>Super slow component</div>;
}

function Form({ left, right }) {
  const [name, setName] = useState("");
  return (
    <>
      {left}
      <label htmlFor="name">Name</label>
      <input
        id="name"
        type="text"
        value={name}
        onChange={(e) => setName(e.target.value)}
      />
      {right}
    </>
  );
}

export default function App() {
  return (
    <div className="app">
      <Form right={<SuperSlowComponent />} left={<h1>Hello</h1>} />
    </div>
  );
}

DEV Community: Ogasawara Kakeru

Next.js ~Prefetching~

Default action

In case of <Link prefetch={true}>

Example

Additional Information

Next.js ~revalidatePath vs revalidateTag ~ A Practical Guide to On-Demand Cache Invalidation

Why on-demand revalidation matters

The mental model: pages and tags

revalidatePath: refresh a specific page

Dynamic routes and the type argument

What it does not do

revalidateTag: refresh everything built from some data

The second argument in Next.js 16

Why the broad-plus-specific tag habit works

updateTag: when the author must see the change immediately

Choosing between them

Putting it together: a blog with a CMS webhook

1. Tag your data

2. Revalidate from a webhook

3. Use updateTag in your own admin form

Common gotchas

Conclusion

React.js ~Testing Accesibility of Fragment Refs~

Testing Accessibility with Fragment Refs

1. What I want to check

2. Test setup

3. Results

4. Pitfalls I found

5. Conclusion

Next.js ~Cache Systems~

React.js ~New feature in React 19.3~

React.js ~The Latest Ref Pattern ~

React.js ~The Latest Ref Pattern~

React.js ~Tips for making UI that is reusable and testable~

React.js ~Tips for making UI that is reusable and testable~

Important thing to consider before adding new features.

React.js ~Tips for making UI that is reusable and testable~

No.1 Weather HTML and CSS have a single responsibility.

React.js ~useEffect memoization pattern for preventing unnecessary rendering~

React.js ~Liftup Pattern for Preventing unnecessary rendering~

In case of `<Link prefetch={true}>`