Client side redirects

[pmelab]

The problem

When working with large volumes of content, redirects are used to retain internal and external integrity when paths change. For example 20k news articles potentially contain links to /about which is changed to /about-us. Even if the content management system could automatically update all references, it would mean that a lot of pages would have to be rebuilt and caches would be cleared. Redirects are a simple and efficient way to handle this.

When the HTTP server redirects a path from /about to /about-us, a Waku <Link> component pointing to /about will not follow the redirect, but display the 404 error page instead. Directly accessing /about will work as expected.

This topic has also been discussed in PR #895. Some different approaches from there, along with their caveats.

1. Make Waku router probe for a redirect before rendering a 404 page and load the redirect target RSC instead.

• Additional requests
• More complexity in the router

2. Load all possible redirects into the router.

• Potentially large amount of data
• More complexity in the router
• Requires a createRedirect API that can be used in entries.tsx

3. Create RSC payloads for redirected paths at build time.

• Increased amount of files (e.g. Cloudflare pages have a hard limit)
• Requires a createRedirect API that can be used in entries.tsx

4. Redirect /RSC/about.txt to /RSC/about-us.txt on the host system

• Leaks internal path of RSC to outside system
• Doubles the amount of necessary redirects (e.g. max 2000 on Cloudflare pages)

PR with breaking test case

#928

[dai-shi]

Not totally related, but can be related: #927

[pmelab]

Two sides of the same coin. If server side redirects are there, the Link (and imperative "navigate") should probably support them.

[dai-shi]

One of my concerns is Waku's responsibility for redirects. Particularly, one big use case of Waku is static sites.

Option 1: Waku or waku/router supports redirects natively
Option 2: Make waku/router RSC path be a spec (not an internal implementation detail)

[dai-shi]

With option 1, I meant something like createRedirect.

[pmelab]

Then we would also have to provide an option to "export" those redirects (e.g. a server config). To have one source of truth.

[dai-shi]

So, does that mean host will do the redirects? That's different from what I mean by "natively".

[pmelab]

Maybe we should define what "natively" means 😄
I always assume a static site as a baseline, so there is no node process to redirect. Therefore it has to be the host.

Gatsby's "createRedirect" is also able to output redirect configuration files for various hosting environments. But I'm not sure if that should really be a part of the framework. "Batteries included" is a costly catchphrase.

[dai-shi]

alright, that's probably lack of my knowledge.
I don't think we should go that direction for now. So, my option 1 is dropped.

[dai-shi]

How do other framework deal with redirects with client navigation?

[pmelab]

My plan is the following: ...

The plan sounds great, but it's unclear to me if its in- or out of scope 🫤

(I'll make a change from what it is now.)

Is that change pre- or post v1?

[pmelab]

Make RSC path a spec for both minimal api and waku/router. (I'll make a change from what it is now.)

I added the current state of this to the tests of #928. I also started some documentation there that can be adjusted accordingly. Just to have it written down somewhere.

[dai-shi]

it's unclear to me if its in- or out of scope

I felt the same. More precisely, it's in the scope for the concept, but out of the scope for our code.

Is that change pre- or post v1?

I'll work on it after releasing v0.21.3. I hope to finalize it, but we may revisit it based on feedback, hopefully before v1.

[rmarscher]

• Make RSC path a spec for both minimal api and waku/router. (I'll make a change from what it is now.)

I don't have an issue with /RSC/*, but it also might be possible to place .txt and .html side-by-side in the static output and then check the accept header in the server. https://github.com/facebook/react/blob/main/fixtures/flight-esm/server/global.js#L63

[dai-shi]

It doesn't feel very comfortable to rely only on the accept header. tbh, I'm not super happy with /RSC/* and putting side-by-side sounds interesting, but still having /RSC/ would be easier to understand and implement and should be less error-prune.