Disabling the client-side router? ("MPA mode") #1329

mayank99 · 2025-03-28T17:16:44Z

mayank99
Mar 28, 2025

Is there a way to completely disable all client-side routing features?

The file-based router makes sense for generating the actual .html pages (during SSR/SSG), but I find the <Link> component and the RSC client cache largely undesirable. I want to do a "hard" navigation each time.

I realize I can just use <a> instead of <Link> but that wouldn't disable the RSC cache, would it? I'm also not sure if there are any other routing features that Waku enables by default.

rmarscher · 2025-03-28T21:20:51Z

rmarscher
Mar 28, 2025
Collaborator

I'm pretty sure that using <a> instead of <Link> will do what you want. The RSC cache is held in the browser and not persisted between requests. I don't think there are other router features enabled by default.

1 reply

mayank99 Mar 29, 2025
Author

Thanks. I would love to understand how exactly the RSC cache works (The docs seemed a bit light).

Edit: It seems like it may just be stored as JS objects in memory.

tylersayshi · 2025-03-28T22:38:01Z

tylersayshi
Mar 28, 2025
Collaborator

If I read this correctly, you're essentially looking to use waku in a MPA mode. This would make it so that no client router is shipped at all.

This is very possible, but we do not yet have an example for this that I know of yet. You'd need to replace the default routing with entries.tsx

We can look to make an example soon for this, but please feel free to try it out yourself if you're up for it. And if this is what you were looking for as well haha.

9 replies

mayank99 Mar 30, 2025
Author

Thanks, I am fully aware of the tradeoffs with "MPAs" (and I do already use Astro for most of my websites). So often, the discussion is too focused around the amount of data fetched and therefore misses some other points, most importantly the fact that: by preventing default navigations, you are throwing away all the accessibility, optimizations, edge cases, and other features that are baked into browser's navigations; re-implementing all of this correctly is no small undertaking.

RSCs have two main selling points:

You do not need to send extra client-side JS to describe your UI. It's a serialized form of the final HTML of a component tree, and it allows interleaving client components. You can use RSC to build pages that have "nested islands" of interactivity.
```
<body>
  <p>Server</p>
  <ClientComp1>
    <p>Server</p>
    <ClientComp2>
      <AsyncComp />
    </ClientComp2>
  </ClientComp1>
</body>
```
It unlocks async data fetching on the server (without waterfalls), and it allows selectively deferring some of those promises to be "resumed" on the client.
```
<CriticalUI data={await fetch(…)} /> // resolved (awaited) on server
<LazyUI data={fetch(…)} /> // resolved on client with React.use
```

This kind of advanced functionality is a bit unique to RSC and cannot be easily achieved with Astro. That's why I'm so interested in Waku.

I will continue to experiment and see if I can put something together using low-level APIs. From what I can tell, currently Waku's server and client routers are somewhat coupled.

tylersayshi Mar 30, 2025
Collaborator

I will continue to experiment and see if I can put something together using low-level APIs. From what I can tell, currently Waku's server and client routers are somewhat coupled.

They're coupled for the 01_template example, but this is exactly the point of the low-level APIs... they allow the flexibility to build alternative routers.

you can look through the rest of the examples for ways to use createPages or defineEntries to make the router solution you're after.

dai-shi Mar 30, 2025
Maintainer

RSCs have two main selling points:

There are two things code named Flight and Fizz. Flight is for RSC payloads and Fizz is for HTML.
When I say RSC, I refer Flight. But, I get your points.

You are not going to use server functions, right? In that case, you wouldn't need <Router> at all.

mayank99 Mar 31, 2025
Author

You are not going to use server functions, right? In that case, you wouldn't need <Router> at all.

I might need server functions at a later point when adding interactivity (e.g. forms), but not when building the initial pages.

What I found is that createPages seems to require <Router> (or something of similar shape). If I only use <Root> and <Slot>, then it errors out. So if I want to remove client-side routing features, I need to use defineEntries which is less convenient than createPages.

(I haven't yet tried to use defineRouter without <Router> because it is marked unstable)

dai-shi Mar 31, 2025
Maintainer

defineRouter and <Router> are paired. createPages is a wrapper around defineRouter.

If you use minimal api such as <Root> and <Slot>, you need defineEntries.

defineRouter and <Router> are the implementation to enable client routing.

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Disabling the client-side router? ("MPA mode") #1329

{{title}}

Replies: 2 comments 10 replies

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

{{editor}}'s edit

{{editor}}'s edit

{{title}}

Select a reply

Disabling the client-side router? ("MPA mode") #1329

mayank99 Mar 28, 2025

Replies: 2 comments · 10 replies

rmarscher Mar 28, 2025 Collaborator

mayank99 Mar 29, 2025 Author

tylersayshi Mar 28, 2025 Collaborator

mayank99 Mar 30, 2025 Author

tylersayshi Mar 30, 2025 Collaborator

dai-shi Mar 30, 2025 Maintainer

mayank99 Mar 31, 2025 Author

dai-shi Mar 31, 2025 Maintainer

mayank99
Mar 28, 2025

Replies: 2 comments 10 replies

rmarscher
Mar 28, 2025
Collaborator

mayank99 Mar 29, 2025
Author

tylersayshi
Mar 28, 2025
Collaborator

mayank99 Mar 30, 2025
Author

tylersayshi Mar 30, 2025
Collaborator

dai-shi Mar 30, 2025
Maintainer

mayank99 Mar 31, 2025
Author

dai-shi Mar 31, 2025
Maintainer