Skip to content

A way to Rewrite outgoing Navigations #11223

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
LorisSigrist opened this issue Dec 7, 2023 · 2 comments
Open

A way to Rewrite outgoing Navigations #11223

LorisSigrist opened this issue Dec 7, 2023 · 2 comments
Labels
feature / enhancement New feature or request

Comments

@LorisSigrist
Copy link
Contributor

LorisSigrist commented Dec 7, 2023

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
Copy link
Contributor Author

LorisSigrist commented Dec 8, 2023

Just to make it clearer how this would enable i18n routing

Screenshot 2023-12-08 at 14 19 09

@pzuraq
Copy link
Contributor

pzuraq commented Feb 10, 2024

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature / enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants