Allow cookies() or headers() in "use cache"

[infodusha]

Goals

Make 'use cache' to be adopted with less struggle

Background

There is docs page with an explanation why that happens:

This is not supported because it would make the cache invalidated by every request which is probably not what you intended.

That is not what I want indeed, however neither I expect it to throw.

The current alternative that docs also suggest is to copy needed cookies and pass it as variables. However, it's not always that easy since down the line you also have to read this values form variable.
Example of current struggle:

const authStorage = new AsyncLocalStorage();

async function getAuth() {
    const cookieStore = await cookies();
    return cookieStore.get('auth');
}

async function callApi(url) {
    const auth = authStorage.getStore() || await getAuth();
    await fetch(url, {
        headers: new Headers({
            'Authorization':  auth,
        }), 
    })
}

async function getCachedUsers() {
    'use cache';
    await callApi('/users');
}

export async function getUsers() {
    const auth = await getAuth();
    await authStorage.run(auth, getCachedUsers);
}

Proposal

An expected result would be to cache headers() and cookies() inside 'use cache' as well, just use the first value for the cache and do not revalidate it (as if it were the first variable upon call)

If that could be a confusing for someone, it could be configured via the flag.

[icyJoseph]

Hi,

I think the plan, as of today, for this use case is an API called 'use cache: private', you can find references to it in the code base - it is still under development - I personally haven't used it yet.

It is more an escape hatch for when you eventually can't do as you describe with regular 'use cache' - the idea is to try and use 'use cache' as much as possible, and only very rarely, if at all, apply the private cache.

There's no plan to allow use cache to access cookies/headers ~

[infodusha]

It's cool there is a solution! May give it a try once ready.

However, I still find it confusing why private cache is an escape hatch rather that a default experience.

[icyJoseph]

Right, they’re solving two different problems. The default “use cache” wants to be deterministic and maximize shareability. You can precompute with a small set of inputs and get maximum cache hits. Like you could derive locale to use, or dark/light mode from the cookie, and keep the variations small.

“use cache: private” is for per-user variability. It is a dynamic API explicitly, so you can wrap it in Suspense and still reuse work via a private cache. I notice now reading some code that headers are not allowed, only cookies though.

I think if private cached data is still fresh enough, the client router can include it in a runtime prefetch so the next navigation is instant too.

They also make it clear and explicit, so you know a private cache directive, is opting into dynamic behavior, whereas use cache, can be pre-rendered, just by reading the code. If things are implemented incorrectly, an error is raised.

I still need to refine how I communicate my mental model around these, but I think that's roughly the case.

[infodusha]

Well, the part about "opting into dynamic behavior" quite explains it. Thanks for your answer.

Also tried 'use cache: private' and for now got an error.

I notice now reading some code that headers are not allowed, only cookies though.

Same. Do you know if there are plans to allow headers in private cache as well?