Proposal: useState-like hook for RSC to facilitate client<->server dataflow

[jonathanhefner]

Goals

Use server components for fetching data independent of the document URL.

Non-Goals

No response

Background

Server components are an awesome abstraction for fetching data corresponding to a document URL (path + query params). However, there are times when client-side interactivity requires fetching data independent of the document URL. Some examples:

• Populating suggestions in an autocomplete / typeahead widget.
• Populating dynamic options for a select box based on another input. For example, populating a list of cities or states based on a selected country.
• Clicking through a calendar widget to select an existing appointment from arbitrarily far in the past or future.
• "Navigating" within a modal wherein the modal's state is ephemeral. For example, a file picker like MacOS's Finder.
• Filtering, sorting, and paginating a data table widget.

It would be nice if we could leverage server components for data fetching in these cases, instead of doing a client-side fetch + API dance.

Proposal

A useState-like hook for server components where the setState function could be passed to client components and be "serialized" similar to a server action function.

As an example:

// server component
export default async function Page() {
  const [searchTerm, setSearchTerm] = useClientState("") // <=== proposed hook

  const searchResults = await fetchResultsFor(searchTerm)

  return <DataTable {...{ searchTerm, searchResults, setSearchTerm }} />
}

Then, the DataTable client component could call setSearchTerm whenever an input changes. The call would send a GET request with a special query param that encodes the new client state (the search term). The server component would rerender with a new searchTerm value that useClientState extracts from the special query param. The new component tree would be sent to the client and reconciled while preserving client state. There could also be a built-in debouncing mechanism.

Notes

An alternative could be a client router function that performs a navigation without changing the browser URL. Possibly limit the navigation to only changing query params for the current page. The server component would then extract the client state from the query params instead of using a hook.

However, that alternative feels less React-y and would be specific to Next. I would like the proposed feature to eventually be included in React proper. I am proposing it here because it seems like it would be easier to prototype in Next.

[jonathanhefner]

I forgot to mention that I started this train of thought because importing server components into client components is unsupported. Indeed, there are open questions about how something like that would work. For example, how would we handle a client component trying to pass children to a server component?

But the more I think about it, the more I think it would be better (from a DX perspective) to figure out answers to those questions and support that usage.

I found #70289, which is essentially asking for that, so I am going to close this thread and continue the discussion there.

I wanted to record some thoughts I had about how multiple useClientState calls could be supported though: Essentially, behind the scenes, React could coalesce multiple useClientState calls to point to a single state object. The state object would be serialized alongside any of the setter functions such that all setter functions point to a part of the same state object. Whenever a client component calls a setter, the setter would update its part of the state object, and the entire state object would be sent to the server. Multiple setter calls would be batched the same way multiple setter calls are batched for useState.