Allows redirect responses to be returned from applications other than React Router

[chimame]

First of all, I would like to express my gratitude to the members who maintain the system.
I am grateful every day for providing the wonderful framework called React Router.

Details

My suggestion is as the title says. Currently, it is very difficult to create a redirect response from an application other than React Router. This is because, when Single fetch is introduced, responses are generated by encoding with turbo stream. If a redirect response is returned without encoding with turbo stream, an error will occur on the client side, that is, the browser side, where it cannot be decoded.

react-router/packages/react-router/lib/server-runtime/server.ts

Lines 162 to 190 in 6c27453

	if (isRedirectResponse(response)) {
	let result: SingleFetchResult | SingleFetchResults =
	getSingleFetchRedirect(
	response.status,
	response.headers,
	_build.basename
	);
	if (request.method === "GET") {
	result = {
	[SingleFetchRedirectSymbol]: result,
	};
	}
	let headers = new Headers(response.headers);
	headers.set("Content-Type", "text/x-script");
	return new Response(
	encodeViaTurboStream(
	result,
	request.signal,
	_build.entry.module.streamTimeout,
	serverMode
	),
	{
	status: SINGLE_FETCH_REDIRECT_STATUS,
	headers,
	}
	);
	}

For example, if you use Hono on the server side of React Router, you can easily create middleware using hono-react-router-adapter.

https://github.com/yusukebe/hono-react-router-adapter

// server/index.ts
import { Hono } from 'hono'
import { redirectDocument } from 'react-router'

const app = new Hono()

app.use("/singed/*", async (c, next) => {
  if (!isSigned()) {
    return redirectDocument('/signin')
  }
  await next()
})

export default app

However, as explained earlier, if you return a normal redirect response for a JSON request (a request with .data in the URL) outside of React Router, that is, with hono, an error will occur in turbo stream decoding on the React Router client side.

It is very difficult to return a redirect response with a server adapter other than Hono or React Router.

Improvement proposal

I have two improvement proposals. I haven't thought about it that deeply, so it may be difficult.

1. Create an API that allows redirects to be returned from applications other than React Router.
2. If the client cannot encode using turbo stream, use a fallback to treat it as normal response data.

Please consider this.

[jrestall]

[edit] There's also a workaround by @rphlmr for Hono. https://github.com/rphlmr/react-router-hono-server/blob/506487503c520d79baaf4f92a176dc869ba5472e/src/http.ts#L6

Here's the temporary workaround I used, but react-router should really support this as it requires using and emulating a lot of internals. Checking auth in express/hono middleware and redirecting if not authenticated is a common use case I'd think also.

import { encode } from "turbo-stream";
import { UNSAFE_SingleFetchRedirectSymbol } from "react-router";
import { writeReadableStreamToWritable } from "@react-router/node";

const SINGLE_FETCH_REDIRECT_STATUS = 202;

function redirectSingleFetch(url: string, res: Response) {
    const readableStream = encode(
      {
        [UNSAFE_SingleFetchRedirectSymbol]: {
          redirect: url,
          status: 302,
          // Modify these for your use-case
          revalidate: false,
          reload: true,
          replace: false,
        },
      },
      {
        plugins: [
          (value) => {
            if (
              value &&
              typeof value === "object" &&
              UNSAFE_SingleFetchRedirectSymbol in value
            ) {
              return [
                "SingleFetchRedirect",
                value[UNSAFE_SingleFetchRedirectSymbol],
              ];
            }
          },
        ],
      }
    );

    res.status(SINGLE_FETCH_REDIRECT_STATUS);

    return writeReadableStreamToWritable(readableStream, res);
  }

[rossipedia]

This is currently a blocker for Docker to adopt v3_singleFetch in order to move towards React Router 7.

We need to be able to have hosting server middleware (express in our case) create redirect responses that are compatible with the Remix client. Relying on turbo-stream internals has been called out by both @brophdawg11 and @jacob-ebey as unsupported and unreliable:

brophdawg11 — 1/14/25 at 8:53 AM
We have specifically chosen not to expose the underlying serialization format because turbo-stream is a short term solution that will eventually be replaced by the RSC wire format once RSC is supported

• https://discord.com/channels/770287896669978684/1328753632543375443/1328753987226435648

rossipedia — 1/9/25, 11:01 AM
[...] In that instance is it recommended to manually encode() that kind of thing directly with turbo-stream? is that "safe"? or would that be essentially relying on implementation details and effectively shooting ourselves in the foot?
jacob9706 — 1/9/25, 11:04 AM
Yeah, that feels very footguny to me. What is the test trying to assert?

• https://discord.com/channels/770287896669978684/940264701785423992/1326974138056708107

To unblock us for now, I'm probably going to patch @remix-run/server-runtime to export the helper shown in the previous comment, since I don't expect Remix to get any future updates.

But for RR7 it would be incredibly helpful to have some sort of "interop" helpers that can be used to create compatible Responses from outside of the React Router handler, especially as we don't currently have middleware support and have to rely on our server's middleware abstractions for many things.

[rossipedia]

The problem with that is that from a Web Platform POV, redirected Requests are 100% opaque. Which is why any 3XX responses in Remix/RR are converted into 202 responses with the turbo-stream body format. Pre-SingleFetch I believe it was 204 with the appropriate information like status and Location: data encoded as X-Remix-* headers instead, which was at least easy to work with.

But now those bits of information are encoded in the Response body, which is encoded using an internal implementation detail (currently turbo-stream, eventually RSC wire format).

[brophdawg11]

Yeah, as @rossipedia said - a fetch request cannot use a normal 3xx redirect to initiate a document-level redirect since the client has no access to the redirect response info (spec, related github issue). It looks like there's some potential for an opt-in header in the future (issue).

This is why we had to resort to 204 responses/custom headers originally and why we're using 202 responses with a turbo-stream body currently. Moving from headers to body does have this unanticipated downside though...

@rossipedia and @chimame - once Remix supports middleware, does that alleviate the issue or just lessen it? I.e., is your hono/express logic there because:

1. Remix/RR gives you no way to perform middleware-esque logic before handlers? If so, once middleware lands, could you move it to RR middleware and it's no longer an issue?
2. Or is it there for another application-specific reason and even when we land middleware it will need to remain there?

I do think in general though it feels wrong to not allow you to redirect externally when we try so hard to work with web standards. I would be in favor of either bringing back support for the headers and making them "public" API or exposing whatever utility we need to allows a proper turbo-stream redirect to be generated from outside of a loader/action.

[rphlmr]

👋 If I may say a word (React Router, Hono Server maintainer), option 2 is preferable unless RR wants to progressively reduce support for third-party servers 😬

Of course, it's perfectly understandable if it is a blocker to make future features easier to release 🫡

For now, I provide a helper:

/**
 * Redirect to a new location.
 *
 * It follows the Single Fetch Redirect protocol, if the request path ends with `.data`.
 */
export function redirect(c: Context, location: string) {
  if (c.req.path.includes(".data")) {
    return reactRouterRedirect(location);
  }

  return c.redirect(location);
}

[alexanderson1993]

That helper is cursed. Talk about leaking implementation details that could break with a minor version bump. https://xkcd.com/1172/

[chimame]

If Remix/RR and express/hono have a one-to-one relationship, I might have answered Yes to the first option if middleware was implemented in Remix/RR. However, it's also possible that Remix/RR is just a part of an application contained within express/hono. In that case, I think the second option, that is, having a public API, is preferable.

As others have written, I understand the opinion that it cannot be created if it would be difficult for Remix/RR to maintain.