Allow hard redirect() on the same domain

[machour]

What is the new or updated feature that you are suggesting?

Continued from the conversation with @brophdawg11 in #9590 (comment)

I'm currently migrating a PHP app to Remix, and doing it incrementally thanks to nginx:

• mydomain.com/a is handled by PHP
• mydomain.com/b is handled by Remix

If I do a redirect() from /b to /a, Remix tries to handle it like it's one of his routes, and it fails.
We need to be able to do a same domain "hard" redirect.

One of the solutions could be to consider absolute redirects as hard redirects, and keeping relative ones as SPA redirections.

Why should this feature be included?

This would make it easier for folks to gradually migrate an online website, and would provide a happy path doing so.

My current workaround is to redirect from /b to a subdomain which in turns redirects again to /a, which is far from ideal.

[brophdawg11]

I'm going to convert this to a discussion so it can go through our new Open Development process. Please upvote the new Proposal if you'd like to see this considered!

[brophdawg11]

Related issues:

• Cannot redirect to different app on same domain from loader function remix#3765
• Redirect triggers page reload in deployed version when redirecting with redirecting to a full URL remix#4656

[brophdawg11]

Another related issue:

• Redirects caused outside of Remix are not handled correctly remix#4183

[brophdawg11]

It would be a breaking change to start treating same-origin absolute redirect URLs as hard redirects, so a few APIs have been tossed around in discussion in related issues:

1. Custom Header

redirect("https://currentorigin.com/hard-reload-path", { 
  headers: {
    "X-Remix-Hard-Redirect": "true"
  }
});

// We should know the origin so we should be able to make this work as well if desired
redirect("/hard-reload-path", { 
  headers: {
    "X-Remix-Hard-Redirect": "true"
  }
});

The downside here is that the user would need to know the header and I don't think it's something types can help out with because it's part of ResponseInit.

2. Additional redirect param

redirect("https://currentorigin.com/hard-reload-path", null, { hardRedirect: true });

This is awkward because now we've got an optional responseInit and optional opts params.

[brophdawg11]

Another thing to consider is that ideally, in Remix, hard redirects don't go back over the wire using the 204 Response approach used for SPA redirects, and just return the proper 3xx redirect. In that case the custom header makes less sense?

[robbtraister]

@brophdawg11 I got a chance to revisit this problem this morning. The underlying root cause of why the workaround suggested here will not work is that the action must return a redirect() (or Response(302)) in order to properly support the noscript case. And once you return a redirect(), there is no way to pass a data payload (at least, as far as I can tell). The HTTP spec seems to allow it, but remix ignores it.

This means that the only viable solution is an internal convention with something like an X-Remix-Hard-Redirect header.

Unfortunately, there isn't really a way to deal with the 204 problem because of the fact that the request is made as a fetch (or XHR, I'm not sure), rather than a true browser navigation. In that case, a redirect does not apply to the window location, and there's no way to know ahead of time if a redirect is expected in order to make the original request differently.

I put together an example repo here that works against the current remix release when using <form />, <Form reloadDocument />, or by disabling javascript. But using it with the hydrated version of <Form /> fails.

I then added patches to enable the X-Remix-Hard-Redirect header as described, allowing it to work in all cases.

[brophdawg11]

In that case, a redirect does not apply to the window location

👍 good catch, I forgot about this nuance

[Mange]

Another way to not having to add extra arguments to redirect is to present a new function. hardRedirect / documentRedirect / fullRedirect.

It could take similar options to redirect, but always merge in the proper header in addition to whatever else is passed along.

Might not make this whole ordeal easier to naturally discover, but at least it gives a way to opt-out from the default behavior without complicating redirect for the normal cases.

[justinwaite]

It would be a breaking change to start treating same-origin absolute redirect URLs as hard redirects, so a few APIs have been tossed around in discussion in related issues:

I think it could be considered a "bug" and not a breaking change. If my react-router app has a basename, I would expect that a fully-qualified domain redirect would check the domain + the basename, and not just domain. So instead of all absolute redirect URLs being hard redirects, only those that are either:

• not the same domain
• same domain but different basename

[brophdawg11]

yeah it looks like we have one here: remix-run/remix#2891. I agree, I think adding a basename would solve this OP issue as well

[machour]

OP here 🤚🏼

I don't think having a base name would fix it my use case.

My description was a bit simplified for this proposal, but I'm in the process of migrating a huge app from PHP to Remix, and I've decided to migrate it portion by portion.

So I don't have just /a and /b, I have a bunch more of those, and will transition them gradually from PHP to Remix, while still needed to redirect from a Remix path to PHP path.

[brophdawg11]

Ah so you have many remix base paths and many PHP base paths. Yeah that's a different beast 👍

[gerbyzation]

In a similar situation with a migration where checking the basepath wouldn't be sufficient as the apps don't have an "exclusive" subpath, but there is interleaving of apps based on what has been migrated or not.

[smerchek]

In a similar situation with a migration where checking the basepath wouldn't be sufficient as the apps don't have an "exclusive" subpath, but there is interleaving of apps based on what has been migrated or not.

We've been in this situation as well, since we started migrating. Our workaround is to use vanilla tags for links to legacy pages.

[rossipedia]

<drake-meme-top>: X-Remix-Hard-Redirect
<drake-meme-bottom>: X-Remix-Reload-Document

[gerbyzation]

We've been running this in production for a bit now and has been working well. Took the ideas from here and @rossipedia's naming suggestion. You can checkout the diff here:

• @remix-run/router: main...gerbyzation:react-router:feature-redirect-reload-document-header
• @remix-run/react: remix-run/remix@main...gerbyzation:remix:feature-redirect-reload-document-header

Usage looks like

export function redirectToLogin(redirectTo: string, locale: string): void {
   throw redirect(toLogin(redirectTo, locale), {
   	headers: {
   		"X-Remix-Reload-Document": "true",
   	},
   });
}

Happy to open a PR for this if there is interest to have this as a contribution!

[jrestall]

Please do give a PR a go, we are having to do similar patching in our codebase for the detailed reasons here and I strongly believe the best fix for this is an internal change to remix.

[jrestall]

I gave the given workaround a shot but have concluded this needs to be fixed internally by remix for the following reasons:

• Doesn't support clients with JS disabled or where JS has failed to load since the workaround returns a 200 with data rather than 301.
• Poor UX since loaders may revalidate when the action returns with the redirect, this delays the redirect and creates unnecessary server requests. Adding shouldRevalidate code to all routes affected is complex and error prone.
• Poor UX since the navigation state will switch to idle before the JSON hardReloadUrl response is read in the useEffect and the actual page redirection happens. This results in a re-render and brief non-loading state before a redirect is performed which may be confusing to users.
• Poor DX. It's complex to add shouldRevalidate to affected routes along with the workaround hook code to routes, compared with just returning a redirect({hardRedirect: true}) or similar from an action.

For an example of a use case that needs this behavior, we are building an IDP in Remix that on successful login will redirect the user to another site that may be on the same domain. Currently we have found patching remix to be the best approach, but this is difficult to keep updated.

[robbtraister]

I took a shot at adding support for the X-Remix-Reload-Document header here. I would appreciate any feedback.

[brophdawg11]

This will be handled by remix-run/remix#7040 and available in Remix v2

[brophdawg11]

And remix-run/remix#6842