kit icon indicating copy to clipboard operation
kit copied to clipboard

A way to Rewrite outgoing Navigations

Open LorisSigrist opened this issue 2 years ago • 2 comments

Describe the problem

There is currently no good way of rewriting the destination of an outgoing navigation.

There are many cases where this would be useful:

  • i18n routing (rewriting navigations to /about into /{lang}/about depending on the language)
  • If a page moved, but there are a lot of links to it, then rewriting every single link would be a lot of work. Registering a rewrite would be a lot quicker.
  • Route aliases (Eg. href="@admin/users" -> href="somewhere/admin/users")

Currently there is no good way of doing this. If JS is enabled, the best you can do is to intercept the navigation in beforeNavigate, canceling it and starting a new one to a new destination. This looses any information about invalidation, scroll position etc. If JS is disabled the only way to do it is to bring your own preprocessor.

This kind of rewrite is strictly different from a redirect, since it wouldn't involve an intermediate request. The correct destination would be chose immediately.

Describe the proposed solution

Create a shared hook that enables rewriting the destination of any outgoing navigations. It could be called something like handleNavigation or resolveDestination.

This hook would be applied to:

  • goto calls.
  • redirect calls, both on the client & the server
  • Any href, action or formaction attributes

(That last one is needed for this to work on pre- / server-rendered pages with JS disabled. It could be implemented with a preprocessor. I have a working implementation)

If the destination rewrite is done before the routeID of the destination get's resolved this shouldn't™️ interfere with the router. Given that the rewritten links would be baked in to the markup on prerendered pages, this would run before beforeNavigate.

Alternatives considered

Always manually rewriting every link / goto / redirect.

Importance

would make my life easier

Additional Information

At Inlang we've been trying to implement an i18n-routing solution for SvelteKit that meets the following criteria:

  • Developers don't need to move any files in routes/
  • Developers don't need to rewrite any existing links
  • It just works (Todd Howard voice)

This combined with #5703 would enable that. We would be very happy to contribute towards making this happen!

LorisSigrist avatar Dec 07 '23 16:12 LorisSigrist

Just to make it clearer how this would enable i18n routing

Screenshot 2023-12-08 at 14 19 09

LorisSigrist avatar Dec 08 '23 13:12 LorisSigrist

This would be helpful for us too, we have a bit of tab-specific state that we want to store and the only reliable way to do so that works both client-side and server-side is via the url, since session cookies are shared between tabs and sessionStorage is not sent the server. So ideally, whenever the app's location changes we could set a query parameter, that way this state would also persist during refreshes on a particular URL.

Specifically, we want to store the active user id (for apps that support multiple sessions at once).

pzuraq avatar Feb 10 '24 18:02 pzuraq