Docs: How to use react cache with server actions if "use server" files only allow async exports?

[yannxaver]

What is the improvement or update you wish to see?

From 14.1.2 "use server" files only allow async exports. How can we utilize react cache now?

Is there any context that might help us understand?

#62821

Does the docs page already exist? Please link to it.

No response

[sannajammeh]

ref: #62821 (comment)

[shuding]

What’s the use case of caching a mutation function (Server Action)?

I think React.cache is designed to NOT cache anything when executed in a Server Action because there might be mutations:

"use server"

const getUser = cache(_getUser)

export async function deleteUser(name) {
  const user = await getUser(name)

  await db.delete(user.id)

  await getUser(name) // this won’t return any cache (and shouldn’t)
}

[yannxaver]

Okay, I see. Seems like the problem is more about project structure / code organization. So far I haven't used "use server" files exclusively for mutations.

I have one "use server" file per entity and this file includes "get" and "post" requests. I use React cache for the "get" requests. Seems like this structure won't work anymore and I need to create separate files for get and post requests.

/edit: To elaborate a bit on that: I have interpreted 'use server' as a message to the bundler that the code in this file should only run on the server. Now after reading your message, I assume that I should have two files - one with 'use server' for mutations and the other one with import server-only for fetches. Personally, I would prefer to have both types of functions in the same file.

Is the implication here that 'use server' files should not include get requests at all? There are two instances in my codebase in which I call a server action (which is no mutation but just returns data) from a client component. That would not be possible anymore if the function was not in a 'use server' file.

[chungweileong94]

I do agree that you not suppose to use React cache with server action, as it literally does nothing. However, library that produces server action (async function) will cause the same error as well, as the code will get transpiled into Promise instead of action.constructor.name === "AsyncFunction"

[laurens-mesure]

I understand that caching mutations does nothing, but why limit this? It breaks colocation of getters and setters in a single file.

[mordechaim]

This is an absolute breaking change. I use React.cache to colocated getters (accessed in server components) and mutations.

[mordechaim]

Workaround, drop-in replacement for React.cache:

import { cache as reactCache } from 'react'

export const cache = fn => {
    const cachedFn = reactCache(fn)
    return async (...params) => {
        return await cachedFn(...params)
    }
}

[chungweileong94]

Workaround for React.cache:

import { cache as reactCache } from 'react'

export const cache = fn => {
    const cachedFn = reactCache(fn)
    return async (...params) => {
        return await cachedFn(...params)
    }
}

I'm not sure about the details, but chances are we are not supposed to call cache(...) within a function, I might be wrong. But maybe we should do it like this instead, more code but safer?

import { cache } from 'react'

const _fn = cache(async () => {
    return "...";
})

export const fn = async (...params) => {
    return _fn(...params)
}

[mordechaim]

Your code is useful when you colocate the cached function inside the server actions file. My version is a utility you could use as a dropin replacement to React.cache

but chances are we are not supposed to call cache(...) within a function

Tested, works perfectly. The only requirement is that the cached function shouldn't change identity so that's why I create cachedFn outside the returned async function.

[chungweileong94]

Looks like the stricter "use server" check has been reverted in the latest canary version #63200.

In the meantime, you can use this wrapper to workaround any async function produced by the library

function asyncFunction<T extends (...params: any[]) => Promise<any>>(fn: T) {
  return async (...params: Parameters<T>) => fn(...params);
}

[shuding]

The "AsyncFunction" requirement has been reverted (so I think this issue can be closed now, thanks everyone!).

It's totally fine to co-locate data access utilities, however this requirement still applies and we need to be careful. All functions exported from a "use server" file will become async once imported, even if they're defined as sync functions.

[github-actions]

This closed issue has been automatically locked because it had no new activity for 2 weeks. If you are running into a similar issue, please create a new issue with the steps to reproduce. Thank you.