You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This PR adds server side route resolution to SvelteKit. This means that instead of loading the whole routing manifest in the client, and doing the route resolution there, the server runtime is invoked for each route request.
How this works:
- user clicks on `<a href="/foo/bar">..</a>`
- server call to `_app/route[route].js`, so in this case `_app/routes/foo/bar.js`
- SvelteKit server runtime does route resolution (does this match a route, taking reroutes into account etc) on the server and returns a response that is a JavaScript file containing the route information in a format that can be parsed on the client
What this enables:
- Projects with massive routes can use this to not send so many kilobytes up front to the client, because the client routing manifest would no longer be sent
- You can hide what routes you have
- Because the server is hit for every route resolution, you can put things like edge middleware in front and be confident it is always called, and for example do rewrites (for example for A/B testing) in there
---------
Co-authored-by: Rich Harris <rich.harris@vercel.com>
* @param {import('types').ServerMetadata['nodes']} [metadata] If this is omitted, we have to assume that all routes with a `+layout/page.server.js` file have a server load function
Copy file name to clipboardExpand all lines: packages/kit/src/exports/public.d.ts
+22
Original file line number
Diff line number
Diff line change
@@ -659,6 +659,28 @@ export interface KitConfig {
659
659
* @since 2.14.0
660
660
*/
661
661
type?: 'pathname'|'hash';
662
+
/**
663
+
* How to determine which route to load when navigating to a new page.
664
+
*
665
+
* By default, SvelteKit will serve a route manifest to the browser.
666
+
* When navigating, this manifest is used (along with the `reroute` hook, if it exists) to determine which components to load and which `load` functions to run.
667
+
* Because everything happens on the client, this decision can be made immediately. The drawback is that the manifest needs to be
668
+
* loaded and parsed before the first navigation can happen, which may have an impact if your app contains many routes.
669
+
*
670
+
* Alternatively, SvelteKit can determine the route on the server. This means that for every navigation to a path that has not yet been visited, the server will be asked to determine the route.
671
+
* This has several advantages:
672
+
* - The client does not need to load the routing manifest upfront, which can lead to faster initial page loads
673
+
* - The list of routes is hidden from public view
674
+
* - The server has an opportunity to intercept each navigation (for example through a middleware), enabling (for example) A/B testing opaque to SvelteKit
675
+
676
+
* The drawback is that for unvisited paths, resolution will take slightly longer (though this is mitigated by [preloading](https://svelte.dev/docs/kit/link-options#data-sveltekit-preload-data)).
677
+
*
678
+
* > [!NOTE] When using server-side route resolution and prerendering, the resolution is prerendered along with the route itself.
0 commit comments