reactjs / reactjs/react.dev

[Suggestion]: Clarification on react.cache Usage in Server Requests

Open
#6,671 0 comments 22 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

type: documentation
Dominant language
JavaScript
Stars
11.8k
Forks
7.9k
Avg merge
1d 11h
Merged PRs (30d)
11

Description

Summary

The use of the term "each server request" in the react.cache API documentation is ambiguous, potentially leading to confusion between React Server Components (RSC) and Server-Side Rendering (SSR). This ambiguity may result in a lower understanding of how react.cache operates and when cache expiration occurs.

Page

https://react.dev/reference/react/cache#caveats

Details

Hi, React Team,

image

While reading through the documentation, I came across the phrase "each server request" and found myself pausing to consider its implications. The term seems to encompass a broad range of server interactions, yet I believe it might be more beneficial to specify "each RSC server request" to distinguish it clearly from general SSR scenarios.

Many of us in the React community, especially those less familiar with server-side mechanisms like RSC, might inadvertently equate "server requests" with the typical requests sent to an SSR server. This could lead to some confusion about when and how cache expiration happens, particularly since react.cache is designed to work within the RSC server context, where each request is akin to a single rendering instance.

It's clear that react.cache plays a crucial role within the RSC environment, akin to how Next.js operates with its external server handling traditional SSR requests and an internal server dedicated to RSC rendering. This dual-server setup made me realize that react.cache is essentially functioning within this confined RSC server space. Given this setup, the concept of cache expiration becomes less conventional, akin to a closure in JavaScript where variables are bound to the function scope and are discarded once the execution context ends.

This analogy to closures might resonate well with developers, highlighting how react.cache retains data within the scope of a single RSC request and discards it afterward, similar to how a closure behaves. This perspective could add a layer of understanding to the documentation, making the concept more relatable and easier to grasp, especially for those familiar with the nuances of JavaScript closures.

I understand the importance of keeping the documentation agnostic to specific implementations like Next.js. However, as React continues to evolve and possibly embrace framework-based tools more closely, clarifying these nuances could prove invaluable, not just for Next.js developers but for all of us looking to harness the full potential of RSC and similar technologies.

It's with this in mind that I suggest a slight revision or an additional note in the documentation to help demystify the workings of react.cache within the RSC context. Such an update could greatly aid in alleviating any confusion and ensure a smoother development experience for the community.

Thank you for considering my input. I deeply appreciate the hard work and dedication that goes into maintaining the React documentation, and I'm eager to contribute in any way I can.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Open the react.cache documentation at the linked react.dev page and review the Caveats section, especially the phrase “each server request.” Confirm how the documentation distinguishes RSC from SSR and how cache expiration is described, then clarify the wording or add a brief note without tying it to a specific framework.

Written by the indexing model from the issue text.

Assessment

Tech stack
javascript, react
Domain
documentation
Issue type
Documentation
Difficulty
2/5
Estimated time
1-3 hours
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.