Multiple issues after migrating to Cache Components

[abhishekmardiya]

I have an application running on the latest Next.js (v16), which works perfectly under normal conditions. However, after migrating to Cache Components, I started encountering multiple issues—even though I’ve followed all the required cache component rules.

One specific issue I’m reporting here is that a form fails to re-render correctly when navigating between routes via <Link>.

---

🔗 Reproduction Repository

https://github.com/abhishekmardiya/cache-components-issues

---

🔁 Reproduction Steps

1. Navigate to the form page from the homepage using a link.
2. Remove the value from the input field.
3. Click “Go to Test 2” (navigate to /test-2).
4. Remove the input value again.
5. Click “Go to Test 1” (navigate back to /test-1).

At this point, you’ll notice that the default value is no longer restored in the form input as you move back and forth between these two routes.

---

✅ Expected Behavior

The form should re-render and display the default input value every time the route changes.

---

❌ Actual Behavior

The input retains the previously cleared state, and the default value is not restored when navigating back.

---

📝 Additional Notes

• This behavior does not occur when Cache Components are disabled.
• The issue only appears after migrating to Cache Components.

According to this documentation:
https://nextjs.org/docs/app/getting-started/cache-components#navigation-uses-activity

When the cacheComponents flag is enabled, Next.js uses React’s <Activity> component to preserve component state during client-side navigation.

Is there a way to override this behavior? In our case, this causes unintended results because the component state is preserved and the page does not re-render as expected during navigation.

Being able to opt out of this behavior (or force a re-render) would help avoid these issues.

Environment Information

Platform: darwin
Arch: arm64
Version: Darwin Kernel Version 25.2.0: Tue Nov 18 21:09:34 PST 2025; root:xnu-12377.61.12~1/RELEASE_ARM64_T8112
Available memory (MB): 16384
Available CPU cores: 8
Binaries:
Node: 24.13.0
npm: 11.6.2
Yarn: N/A
pnpm: N/A
Relevant Packages:
next: 16.1.6 // Latest available version is detected (16.1.6).
eslint-config-next: N/A
react: 19.2.4
react-dom: 19.2.4
typescript: 5.9.3
Next.js Config:
output: N/A

Could someone please explain why this happens with Cache Components enabled? Understanding this behavior would help me identify the correct fix.
@icyJoseph

With cache components

with-cc.mov

Without cache components

without-cc.mov

[icyJoseph]

This is because with Cache Components activated, Next.js wraps routes in React's Activity Boundaries.

• https://react.dev/reference/react/Activity
• https://nextjs.org/docs/app/getting-started/cache-components#navigation-uses-activity

This keeps a number of routes (3) around, in the DOM, in React's new hidden mode (so-to-speak). More info in the Next.js docs.

This issue is tracking feedback, workarounds, and more info, including likely upcoming changes:

• [cacheComponents] Activity component route preservation causes significant breakage in application logic, UI behavior and E2E tests #86577 (comment)

Furthermore we have an upcoming Activity guide: #89126

I'd say first understand what Activity is doing, from a pure React point of view, and then you can identify some way forward, or wait a bit until the gradual migration path lands. An official way forward is gaining traction, but as long as it is not published, it is best to work with what's available at the moment.

[abhishekmardiya]

Thank you for your help.

[abhishekmardiya]

@icyJoseph

Hi, I’m also experiencing this issue. Is it related to React’s <Activity> component as well?

Reproduction Repository : https://github.com/abhishekmardiya/cache-components-reproduction

Screen.Recording.2026-01-28.at.9.19.50.PM.mov

This behavior does not occur when Cache Components is disabled.

Problems like this make it feel like I may need to opt out of Cache Components altogether, since this behavior introduces unintended side effects.

Is there a proper or simple workaround to achieve the functionality I need in this code?
This behavior feels a bit unexpected. The workaround mentioned in this thread (#86577 (comment)) also seems somewhat complex for what appears to be a common use case.
Is there a simpler or more straightforward way to achieve the same functionality, or should I wait for a proper solution?

[icyJoseph]

Thanks. I spent some time digging into this and there's actually quite a bit going on here. This is a good teaching moment ~~ for everyone

You Might Not Need useEffect

The pattern in the original code is:

const [selected, setSelected] = useState(initialValue);

useEffect(() => {
  if (pathName !== selected) {
    push(selected);
  }
}, [pathName, selected, pathSegments, push]);

// onChange:
onChange={() => setSelected(el.value)}

This is onChange → setState → effect watches state → push. But this should really just be:

onChange={() => push(el.value)}

You might still want to track selected state for other purposes - but not to trigger the route change. The general principle: effects are for synchronization with external systems, not for enacting state changes. Router push is a state change (it's integrated into React's state via the router), not a sync operation.

This falls under the "You Might Not Need an Effect" guidance from the React docs.

Some surprises along the way

The interesting part is that this code appears to work without cacheComponents. It was actually held together by several coincidences:

1. React Compiler memoizing unstable deps - pathSegments is recreated every render, which should cause the effect to fire constantly. The compiler memoizes it away. If you turn off the compiler, your effect immediately goes into run-away.

2. Relative push semantics - push("slug-1") is a relative navigation. From /variant-one/slug-1, it navigates to... /variant-one/slug-1. Same place.

3. Router deduplication - The router bails out when you push to the same location. So the infinite "push to where I already am" becomes a no-op.

4. The comparison was always wrong - pathName !== selected compares /variant-one/slug-1 to slug-1. Always true. But because of #2 and #3, it didn't matter. Though I spend a bit of time starting my debugging session from herer.

Activity Exposed the Bugs

cacheComponents/Activity didn't cause these bugs - it makes them visible.

With Activity, you have two cached component instances in the DOM simultaneously. Each has its own React state, but usePathname() updates in both (it's an external subscription). When one is revealed:

• It has stale selected state from before it was hidden
• pathName is fresh from the router
• Mismatch triggers push
• Push reveals the other instance with its own stale state
• That one pushes back
• Ping-pong loop

There's also a form control issue: both instances have <input name="commercial-property-type">. Per HTML spec, radio buttons with the same name that aren't bound by a <form> are all part of the same group across the document. Two instances = four radios in one group, with conflicting checked states. One would need a unique name per instance-of-two-radio-buttons (for example, but not limited to, useId() or wrapping in separate <form> elements).

a11y shows the way forward

While debugging this, I noticed the tab/arrow-key navigation causes focus loss - you navigate away and the focused element is gone. This happens with or without Activity.

Screen.Recording.2026-01-30.at.14.04.23.mov

I tab into the radio group, and with arrow keys navigate to the next item. Focus is lost, because we swap the DOM from under the user. Try proper radio button focus here, https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/input/radio#try_it

This suggests the component might belong in a shared layout rather than being duplicated per route. If it controls cross-route navigation, having one instance in the layout means:

• No caching/state issues
• No form control conflicts
• No focus loss on navigation

Fixing it all up

Step 1: Use Event Handlers, Not Effects

First things first - fix the pattern. No state for navigation, derive from URL, push in the handler:

const { push } = useRouter();
const pathName = usePathname();
const id = useId();

const pathSegments = pathName.split("/").filter((segment) => segment);
const currentSlug = pathSegments[pathSegments.length - 1];

return (
  <form>
    {ROUTES.map((el) => (
      <label key={el.value} htmlFor={`${id}-${el.value}`}>
        <input
          type="radio"
          name="commercial-property-type"
          id={`${id}-${el.value}`}
          checked={currentSlug === el.value}
          onChange={() => push(el.value)}
        />
        {el.name}
      </label>
    ))}
  </form>
);

Note: name doesn't need a prefix if wrapped in a <form> (scoped to form), but id/htmlFor still need useId() (document-global).

This fixes the infinite loop. But we're not done yet.

Step 2: A11y - You Can't Lose Focus Like That

With the fix above, tab/arrow-key navigation still causes focus loss - you navigate away and the focused element is gone. That's not great for accessibility.

If a component controls cross-route navigation, it shouldn't be duplicated per route. Shared layout to the rescue.

Layout:

// app/test-1/layout.tsx
import { Suspense } from "react";
import { SharedRadioGroup } from "@/components/SharedRadioGroup";

export default function Test1Layout({
  children,
}: {
  children: React.ReactNode;
}) {
  return (
    <main>
      <Suspense fallback={<div>Loading...</div>}>
        <SharedRadioGroup />
      </Suspense>
      {children}
    </main>
  );
}

Component:

// components/SharedRadioGroup.tsx
"use client";

import { usePathname, useRouter } from "next/navigation";

export const SharedRadioGroup = () => {
  const { push } = useRouter();
  const pathName = usePathname();

  const pathSegments = pathName.split("/").filter((segment) => segment);
  const currentSlug = pathSegments[pathSegments.length - 1];

  return (
    <form>
      {ROUTES.map((el) => (
        <label key={el.value} htmlFor={el.value}>
          <input
            type="radio"
            name="commercial-property-type"
            id={el.value}
            value={el.value}
            checked={currentSlug === el.value}
            onChange={() => push(el.value)}
          />
          {el.name}
        </label>
      ))}
    </form>
  );
};

With a shared layout:

• One instance - no caching conflicts, no stale state
• No unique instance names (useId()) needed - single instance means the radio group has always 2 elements
• Focus preserved - radio group stays mounted across route changes
• Proper a11y - tab/arrow navigation works as expected

Screen.Recording.2026-01-30.at.14.13.19.mov

TL;DR

1. Favor event handlers over effects for user-initiated actions
2. The original code had bugs masked by React Compiler + router deduplication
3. Activity exposed stale state issues with cached instances
4. Form controls need unique name/id when multiple instances exist in DOM
5. If the component controls cross-route navigation, it belongs in a shared layout

And yes, I am sure there's some reason why the useEffect was needed, or whatever, business level code and teaching material, may have a gap sometimes.

[abhishekmardiya]

Thank you so much for the in-depth explanation — really appreciate it 🙏
I’ve been coding in React for almost 3+ years, and still I feel like I barely know anything sometimes

After reading your explanation, I honestly felt like React just looked at me and said:

“You know nothing, Jon Snow.”😅

And also — thanks a ton for everything you're doing for the Next.js community. Your instant responses genuinely help all of us a lot.