draftMode disables cache so hard, that memoization is also skipped

[laurenskling]

I wrap my fetch calls in a "use cache" and can call them from anywhere in my code (for example to check feature flags for other fetch calls), and the memoization only calls this data once.

Now when I run in draftMode, not only all caches are skipped (good), also memoization is skipped. So my feature flags endpoint gets 100 calls every page load.

Wouldn't it make more sense that the data is freshly requested, but the calls are still memoized?

[felmonon]

I think the behavior you are seeing is consistent with how Next splits caching layers.

draftMode() opts the route into request-time rendering so cached results are bypassed. But persistent cache and request memoization are different things:

• use cache / Data Cache: persistent and intentionally bypassed in draft mode
• fetch request memoization: per-render-pass dedupe for identical GET requests
• React cache(): per-request memoization for arbitrary async functions

So if your feature flags endpoint is being hit 100 times in draft mode, it usually means one of these:

• the helper is not using fetch directly
• the requests are not actually identical (headers/cookies/search params/options differ)
• the calls happen across separate render passes

If your goal is "fresh every request, but deduped within that request", I would not rely on use cache in draft mode. I would either:

import { cache } from 'react'

const getFlags = cache(async () => {
  const res = await fetch('https://flags.example.com/api/flags', {
    cache: 'no-store',
  })
  if (!res.ok) throw new Error('Failed to load flags')
  return res.json()
})

or fetch once at the page/layout boundary and pass the result down.

That gives you:

• no persistent caching
• one network call per request/render pass
• no preview staleness

Relevant docs:

• https://nextjs.org/docs/app/deep-dive/caching
• https://nextjs.org/docs/app/api-reference/directives/use-cache

So short version: yes, draft mode disables the persistent cache on purpose. If you still want per-request dedupe, use fetch memoization or React cache(), not use cache.

[laurenskling]

I am using fetch memoization and tried cache(), it didn't help. Maybe it's because I use draftMode inside my fetch wrapper function, which is inside of the "use cache". Will do some more research if that is making it not dedupe.

So with cacheComponents enabled we still use cache()? I thought "use cache" was going to be the one tool to rule them all?

My use case is: hard caching on everything (and using revalidateTag), but in draftMode, I need the cache skipping because I want to editor to see the draft content from Strapi (which is a param in the fetch call ?status=${isEnabled ? 'draft' : 'published'}). This content needs to be fresh, because it differs from the cached calls, but I still need it only once per render cycle, so deduped.

[felmonon]

If this shortened example is the real shape, then I agree it looks surprising.

My understanding from the current docs is:

• identical GET fetch calls with the same URL/options should still be memoized within a render pass
• bypassing persistent cache is a separate concern from request memoization
• request/runtime data should be read outside cached scopes and passed in as an argument

So at this point I’d narrow it to two possibilities:

1. these calls are actually happening across separate render passes, or
2. this is a real bug/regression in how draftMode() interacts with request memoization / cache()

I’d try one last check: move all draftMode() access completely outside the cached function, pass isDraft in explicitly, and verify the fetch URL/options are byte-for-byte identical.

If it still reproduces in that shape, I think a minimal repro would be worth filing, because at that point it does sound like unexpected behavior rather than just use cache being bypassed.

[laurenskling]

Shortened example:

import { cache } from 'react';

export default cache(async function getContentTypes() {
  const apiUrl = 'https://strapi.example.com/api';
  const apiToken = 'example';

  const res = await fetch(`${apiUrl}/content-type-builder/content-types`, {
    cache: 'force-cache',
    headers: {
      Authorization: `bearer ${apiToken}`,
    },
  });

  const result = await res.json();
  return result.data;
});

If I run in draftMode, this just doesn't get deduped.

[sefin23]

The issue is that cache: 'force-cache' inside your react cache() wrapper is likely what's breaking deduplication in draft mode.

When draftMode is active, Next.js opts the entire route into dynamic rendering and bypasses the persistent Data Cache. The problem with cache: 'force-cache' here is that Next.js may treat each call as needing its own cache-check lifecycle, which can break the per-request deduplication that React's cache() provides.

The fix: switch to cache: 'no-store' inside your react cache() wrapper

import { cache } from 'react';

export default cache(async function getContentTypes() {
  const apiUrl = 'https://strapi.example.com/api';
  const apiToken = 'example';

  const res = await fetch(`${apiUrl}/content-type-builder/content-types`, {
    cache: 'no-store', // <-- change this
    headers: {
      Authorization: `bearer ${apiToken}`,
    },
  });

  const result = await res.json();
  return result.data;
});

The reasoning: react cache() deduplicates at the React render pass level — it works independently of the fetch cache. But if force-cache is triggering a separate cache-resolution path in draft mode, it may be creating new async contexts that break the dedup boundary. With no-store, Next.js skips the Data Cache entirely and lets React's cache() handle deduplication cleanly — meaning one real network call per render pass, regardless of draft mode.

For your Strapi draft/published use case specifically, you can also pass isDraft as an argument so react cache() can key correctly:

import { cache } from 'react';
import { draftMode } from 'next/headers';

export const getContentTypes = cache(async function (isDraft: boolean) {
  const res = await fetch(
    `https://strapi.example.com/api/content-type-builder/content-types?status=${isDraft ? 'draft' : 'published'}`,
    {
      cache: 'no-store',
      headers: { Authorization: `bearer example` },
    }
  );
  return (await res.json()).data;
});

// In your page/layout:
const { isEnabled } = await draftMode();
const data = await getContentTypes(isEnabled); // deduped per render pass

This gives you fresh data every request in draft mode, with full deduplication within the render pass.

[laurenskling]

So I've experimenting with this. And it's probably because I use getContentTypes within other functions doing fetch calls to my server.

So something like:

const getPage = cache(async function () {
  const [thisorthatplugin] = await getContentTypes();
  const res = fetch(`http://my.strapi${thisorthatplugin ? '?somethinginthequery=true} : ''`)
});

No matter how i wrap stuff into cache() functions, doing this from a single function makes it go fetch my getContentTypes over and over. Getting it first in my component and than adding it to the getPage function seems to make it cache better. But I don't want to do that. I want the getPage function to do it's own work.

[icyJoseph]

@laurenskling - sorry I was out last week, and spammers took over...

• https://nextjs.org/docs/app/api-reference/directives/use-cache#reactcache-isolation

Could this be the issue? The spam makes it a bit annoying to parse what's been said here, but I do believe your getContentTypes function access headers/cookies?

[laurenskling]

in the docs: This means you cannot use React.cache to pass data into a use cache scope, so I cannot use the result of getContentTypes inside of the getPage use cache. Makes sense. But I don't know how to make it happen. Because I can never tell getContentTypes to use cache to dedupe?

[icyJoseph]

React.cache is per page request/build-pass only. It won't dedupe across these.

I see, I was a bit blind to context when writing that section. What happens is that some people store data in a object using React.cache.

Normally, because calling React.cache with the same inputs, during the same request, returns the same results, you can read the same underlying object. As the snippet shows:

You store some data...

const store = cache(() => ({ current: null as string | null }))
 
function Parent() {
  const shared = store()
  shared.current = 'value from parent'
  return <Child />
}

And attempt to read it within the cached scope.

async function Child() {
  'use cache'
  const shared = store()
  // shared.current is null, not 'value from parent'
  // use cache has its own isolated React.cache scope
  return <div>{shared.current}</div>
}

However, inside cache scopes, there's isolation, getContentTypes is wrapped by a fresh React.cache store, so the function runs fresh.

And the same happens to the underlying fetch to your endpoint. React.cache is used by Next.js to dedupe fetch requests, even with fairly complex objects. But, since this is all happening within a cached scope, there's isolation.

I think amongst the discussion so far, I've lost track of what you'd like to achieve, and what conditions do you have? Is it that you want to prevent hitting the strapi endpoint so heavily? Could you invert, and getContentTypes (with cache and all), from outside cached directives, and make the content types, function inputs to wherever you need... Could we see some pseudocode of the call stack, who calls what, etc...

[laurenskling]

Yes, my main goal here is to prevent hitting that endpoint over 100 times for a single render, whilst that endoint never changing between Strapi deploys. If it's possible to make it even more staticly available within my code, that would be even better, but I don't know where. I don't want to use context, so I was going for fetch dedupe to "store" it.

What I want to achieve:
I render a route, it makes a lot of calls to my Strapi. A call for the menu, a call for every page in the menu, a call for every piece of content in this route. When fetching a page, I need to check some feature flags, does this Strapi instance support X or Y. So I fetch /content-types to check the Strapi schema. Does this Strapi have plugin X? Okay, populate content Y in the query string of /api/page/1?populate[pluginx][fields]=*, /api/page/2?populate[pluginx][fields]=*, etc. All of this is working fine, but this floods my server with calls to /content-types, delaying everything and polluting my logs.

In normal mode, all calls are deduped by 'use cache' (not using React.cache now). In draftMode, all 'use cache' is skipped, thus also skipping all deduping. Making pages that appear multiple times on the route (mulitple menus, links, etc), getting fetching multiple times, and those multiple calls fetching /content-types multiple times.

I want in draftMode the same api calls also be deduped.

I tried to minimize my setup as an example:

async function getContentTypes() {
  'use cache';

  const res = await fetch(`${apiUrl}/content-type-builder/content-types`, {
    cache: 'no-store',
    headers: {
      Authorization: `bearer ${apiToken}`,
    },
  });

  const result = await res.json();
  return result.data;
}

const hasPlugin = async (pluginName) => {
  const cts = await getContentTypes();
  return cts.some(({ plugin }) => plugin.includes(pluginName));
};

async function getPage(documentId) {
  'use cache';
  if (!documentId) {
    return null;
  }

  const query = {
    populate: {
      image: {
        fields: ['id'],
      },
      ...(await hasPlugin('vehicles') ? {
        searchResultsPage: {
          fields: ['id'],
        },
      } : {}),
      ...(await hasPlugin('pagebuilder') ? {
        beforeContentSections: {
          fields: ['id'],
        },
        afterContentSections: {
          fields: ['id'],
        },
      } : {}),
    },
  };

  const tag = `plugin::pages.page/${documentId}`;

  const q = qs.stringify({
    status: 'draft',
    ...query,
  }, {
    encodeValuesOnly: true, // prettify URL
  });
  const res = await fetch(`${apiUrl}/pages/pages/${documentId}?${q}`, {
    cache: 'no-store',
    next: {
      tags: [tag],
    },
    headers: {
      Authorization: `bearer ${apiToken}`,
    },
  });

  const page = await res.json();
  return page.data;
}

const MenuItem = async (pageDocumentId) => {
  const page = await getPage(pageDocumentId);
  return (
    <Link href={page.href}>
      {page.title}
    </Link>
  );
}

(we go no-store to not use React.cache but 'use cache'? I'm still confused about what method to use where. Should I ever need to use fetch cache/React.cache() when i can use 'use cache'?

[icyJoseph]

right, but, so if draftMode doesn't save to cache, and bypasses fetch cache layer, then because we are under a cache directive scope, each React.cache is unique, so the fetch is not deduped.

I guess since we don't store the cache result, we can't really dedupe the cache call either... But then what I've been trying to say is:

const MenuItem = async (pageDocumentId) => {
 const cts = await getContentTypes();
 const page = await getPage(pageDocumentId, cts);
  return (
    <Link href={page.href}>
      {page.title}
    </Link>
  );
}

And then

const hasPlugin = (cts, pluginName) => {
  return cts.some(({ plugin }) => plugin.includes(pluginName));
};

async function getPage(documentId, cts) {
  'use cache';
  if (!documentId) {
    return null;
  }

  const query = {
    populate: {
      image: {
        fields: ['id'],
      },
      ...(hasPlugin(cts, 'vehicles') ? {
        searchResultsPage: {
          fields: ['id'],
        },
      } : {}),
      ...(hasPlugin(cts, 'pagebuilder') ? {
        beforeContentSections: {
          fields: ['id'],
        },
        afterContentSections: {
          fields: ['id'],
        },
      } : {}),
    },
  };

// rest of the function

This would put the content types fetch outside the cached scope, and let React.cache dedupe, at least during this render pass. I can imagine the production setup has a lot more repetition, or it is larger than this simplification.

[laurenskling]

I see how that makes sense. But this would require a lot of stitching in the code just to work around it for draftMode. And wanting data for a contentpage 4 times on the route would still make getPage called 4 times. So it only works around the extreme many calls, but it still makes multiple calls to the same data on a render. I still would prefer if it could actually dedupe. Maybe set the cache time to 1ms, or discard all caches after render. But like this it really seems unoptimal.

[selcukcukur]

@laurenskling You’ve hit on a subtle but important distinction: cache invalidation vs. memoization.

Right now, in draftMode, both are disabled — so every call is treated as “fresh,” and your feature flags endpoint gets hammered. That’s consistent with the idea of “no caching in draft,” but it conflates two different concerns:

• Caching: persisting data across requests or deployments.
• Memoization: deduplicating identical calls within the same request lifecycle.

In practice, it often makes sense to skip caching in draft mode (so you always see fresh data), but still keep memoization active (so you don’t re‑fetch the same resource dozens of times during one render).

Why memoization should remain

• Draft mode is about previewing fresh content, not about disabling deduplication.
• Without memoization, any shared dependency (like feature flags) gets called repeatedly, which is wasteful and noisy.
• Keeping memoization ensures you still get fresh data once per request, but not N times per component.

Possible approaches

• Split the logic: implement a useCache that internally distinguishes between “persistent cache” and “per‑request memoization.” In draft mode, disable the persistent cache but leave memoization intact.
• Scoped memoization: tie memoization to the request context (e.g., Next.js cache() or React’s useMemo equivalents). That way, each request gets fresh data, but repeated calls within that request are deduped.
• Feature flag endpoint optimization: if you know it’s always needed, fetch it once at the top level and pass it down, rather than letting every component trigger it.