RFC: Add renderToResponse helper

[justinvdm]

Problem

renderToStream is fundamentally designed for generating an HTML stream. It is not designed to handle the full lifecycle of a RedwoodSDK app route (which requires negotiating between HTML and RSC responses).

Trying to force renderToStream to handle RSC requests breaks its contract and confuses the user consumption model (stream vs response headers).

Instead of patching renderToStream, we need a new API (e.g., renderToResponse) that encapsulates the entire response generation logic (negotiating Content-Type and body format).

Proposed Solution

Introduce a new high-level helper: renderToResponse.

export function renderToResponse(
  element: ReactElement,
  options: RenderOptions
): Promise<Response>

This helper will:

1. Accept the component tree and standard options (Document, requestInfo, etc.).
2. Inspect requestInfo to determine if the request is an RSC request (Action or Client Transition).
3. If RSC Request:
   • Generate the raw RSC stream (including Action results).
   • Return a Response with Content-Type: text/x-component.
4. If HTML Request:
   • Generate the HTML stream (with injected RSC payload).
   • Return a Response with Content-Type: text/html.

This gives us

• Safe Default: Users get the correct behavior for both initial loads and interactivity without manual configuration.
• DRY: This logic is currently embedded in internal logic for defineApp. Extracting it to a public helper allows "manual" routes to have feature parity with standard render() routes.
• Clear API Boundary: renderToStream remains a low-level primitive for "give me HTML", while renderToResponse becomes the standard for "render this page" when users need to do so programmatically/imperatively instead of the default declarative route() API.

Example Usage

// worker.tsx
route("/my-custom-route", async (requestInfo) => {
  // Before: Crashes on interaction
  // return new Response(await renderToStream(<MyPage />, { Document }), { ... });

  // After: Works with Actions/Transitions
  return renderToResponse(<MyPage />, { Document, requestInfo });
});

[gching]

Makes sense and loving it! I've been thinking of this too, since I've been manually copying over defineApp logic to make the renderToStream work after the response is sent, especially with Actions + Transitions. Will definitely be more DRY

EDIT: Thinking about this more, this is going to be useful outside of the context of defineApp, we can potentially see a world where with the renderToResponse primitive, we can start plugging in rwsdk into hono or any other frameworks