From f5e9142c6ecffdb3f4a17ca1980d43d7db99f369 Mon Sep 17 00:00:00 2001 From: "github-actions[bot]" <41898282+github-actions[bot]@users.noreply.github.com> Date: Mon, 3 Feb 2025 12:36:44 +0100 Subject: [PATCH] Sync `kit` docs (#1135) sync kit docs Co-authored-by: svelte-docs-bot[bot] <196124396+svelte-docs-bot[bot]@users.noreply.github.com> --- .../docs/kit/20-core-concepts/10-routing.md | 4 +- .../kit/20-core-concepts/30-form-actions.md | 2 +- .../30-migrating-to-sveltekit-2.md | 2 +- .../docs/kit/98-reference/50-configuration.md | 35 ++++++++++++++++ .../content/docs/kit/98-reference/54-types.md | 41 +++++++++++++------ 5 files changed, 68 insertions(+), 16 deletions(-) diff --git a/apps/svelte.dev/content/docs/kit/20-core-concepts/10-routing.md b/apps/svelte.dev/content/docs/kit/20-core-concepts/10-routing.md index 46159a179..d6fb735d9 100644 --- a/apps/svelte.dev/content/docs/kit/20-core-concepts/10-routing.md +++ b/apps/svelte.dev/content/docs/kit/20-core-concepts/10-routing.md @@ -38,6 +38,8 @@ A `+page.svelte` component defines a page of your app. By default, pages are ren Home ``` +> [!NOTE] SvelteKit uses `` elements to navigate between routes, rather than a framework-specific `` component. + Pages can receive data from `load` functions via the `data` prop. ```svelte @@ -56,8 +58,6 @@ Pages can receive data from `load` functions via the `data` prop. > > In Svelte 4, you'd use `export let data` instead. -> [!NOTE] SvelteKit uses `` elements to navigate between routes, rather than a framework-specific `` component. - ### +page.js Often, a page will need to load some data before it can be rendered. For this, we add a `+page.js` module that exports a `load` function: diff --git a/apps/svelte.dev/content/docs/kit/20-core-concepts/30-form-actions.md b/apps/svelte.dev/content/docs/kit/20-core-concepts/30-form-actions.md index fb0e59141..c0ae9dbf8 100644 --- a/apps/svelte.dev/content/docs/kit/20-core-concepts/30-form-actions.md +++ b/apps/svelte.dev/content/docs/kit/20-core-concepts/30-form-actions.md @@ -354,7 +354,7 @@ The easiest way to progressively enhance a form is to add the `use:enhance` acti
``` -> [!NOTE] `use:enhance` can only be used with forms that have `method="POST"`. It will not work with `method="GET"`, which is the default for forms without a specified method. Attempting to use `use:enhance` on forms without `method="POST"` will result in an error. +> [!NOTE] `use:enhance` can only be used with forms that have `method="POST"` and point to actions defined in a `+page.server.js` file. It will not work with `method="GET"`, which is the default for forms without a specified method. Attempting to use `use:enhance` on forms without `method="POST"` or posting to a `+server.js` endpoint will result in an error. > [!NOTE] Yes, it's a little confusing that the `enhance` action and `` are both called 'action'. These docs are action-packed. Sorry. diff --git a/apps/svelte.dev/content/docs/kit/60-appendix/30-migrating-to-sveltekit-2.md b/apps/svelte.dev/content/docs/kit/60-appendix/30-migrating-to-sveltekit-2.md index bc1e6e59a..6f018fbef 100644 --- a/apps/svelte.dev/content/docs/kit/60-appendix/30-migrating-to-sveltekit-2.md +++ b/apps/svelte.dev/content/docs/kit/60-appendix/30-migrating-to-sveltekit-2.md @@ -130,7 +130,7 @@ The `$env/dynamic/public` and `$env/dynamic/private` modules provide access to _ During prerendering in SvelteKit 1, they are one and the same. As such, prerendered pages that make use of 'dynamic' environment variables are really 'baking in' build time values, which is incorrect. Worse, `$env/dynamic/public` is populated in the browser with these stale values if the user happens to land on a prerendered page before navigating to dynamically-rendered pages. -Because of this, dynamic environment variables can no longer be read during prerendering in SvelteKit 2 — you should use the `static` modules instead. If the user lands on a prerendered page, SvelteKit will request up-to-date values for `$env/dynamic/public` from the server (by default from a module called `_env.js` — this can be configured with `config.kit.env.publicModule`) instead of reading them from the server-rendered HTML. +Because of this, dynamic environment variables can no longer be read during prerendering in SvelteKit 2 — you should use the `static` modules instead. If the user lands on a prerendered page, SvelteKit will request up-to-date values for `$env/dynamic/public` from the server (by default from a module called `/_app/env.js`) instead of reading them from the server-rendered HTML. ## `form` and `data` have been removed from `use:enhance` callbacks diff --git a/apps/svelte.dev/content/docs/kit/98-reference/50-configuration.md b/apps/svelte.dev/content/docs/kit/98-reference/50-configuration.md index f1302471a..d1d4c343a 100644 --- a/apps/svelte.dev/content/docs/kit/98-reference/50-configuration.md +++ b/apps/svelte.dev/content/docs/kit/98-reference/50-configuration.md @@ -1085,6 +1085,41 @@ What type of client-side router to use. - `'hash'` means the route is determined by `location.hash`. In this case, SSR and prerendering are disabled. This is only recommended if `pathname` is not an option, for example because you don't control the webserver where your app is deployed. It comes with some caveats: you can't use server-side rendering (or indeed any server logic), and you have to make sure that the links in your app all start with #/, or they won't work. Beyond that, everything works exactly like a normal SvelteKit app. + + +
+ +```ts +// @noErrors +resolution?: 'client' | 'server'; +``` + +
+ +
+ +- default `"client"` +- available since v2.17.0 + +
+ +How to determine which route to load when navigating to a new page. + +By default, SvelteKit will serve a route manifest to the browser. +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. +Because everything happens on the client, this decision can be made immediately. The drawback is that the manifest needs to be +loaded and parsed before the first navigation can happen, which may have an impact if your app contains many routes. + +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. +This has several advantages: +- The client does not need to load the routing manifest upfront, which can lead to faster initial page loads +- The list of routes is hidden from public view +- The server has an opportunity to intercept each navigation (for example through a middleware), enabling (for example) A/B testing opaque to SvelteKit + +The drawback is that for unvisited paths, resolution will take slightly longer (though this is mitigated by [preloading](/docs/kit/link-options#data-sveltekit-preload-data)). + +> [!NOTE] When using server-side route resolution and prerendering, the resolution is prerendered along with the route itself. +
diff --git a/apps/svelte.dev/content/docs/kit/98-reference/54-types.md b/apps/svelte.dev/content/docs/kit/98-reference/54-types.md index fe22ef78b..bd97d2ab2 100644 --- a/apps/svelte.dev/content/docs/kit/98-reference/54-types.md +++ b/apps/svelte.dev/content/docs/kit/98-reference/54-types.md @@ -128,15 +128,34 @@ The generated `.svelte-kit/tsconfig.json` file contains a mixture of options. So /// file: .svelte-kit/tsconfig.json { "compilerOptions": { - "baseUrl": "..", "paths": { - "$lib": "src/lib", - "$lib/*": "src/lib/*" + "$lib": ["../src/lib"], + "$lib/*": ["../src/lib/*"] }, "rootDirs": ["..", "./types"] }, - "include": ["../src/**/*.js", "../src/**/*.ts", "../src/**/*.svelte"], - "exclude": ["../node_modules/**", "./**"] + "include": [ + "ambient.d.ts", + "non-ambient.d.ts", + "./types/**/$types.d.ts", + "../vite.config.js", + "../vite.config.ts", + "../src/**/*.js", + "../src/**/*.ts", + "../src/**/*.svelte", + "../tests/**/*.js", + "../tests/**/*.ts", + "../tests/**/*.svelte" + ], + "exclude": [ + "../node_modules/**", + "../src/service-worker.js", + "../src/service-worker/**/*.js", + "../src/service-worker.ts", + "../src/service-worker/**/*.ts", + "../src/service-worker.d.ts", + "../src/service-worker/**/*.d.ts" + ] } ``` @@ -148,24 +167,22 @@ Others are required for SvelteKit to work properly, and should also be left unto "compilerOptions": { // this ensures that types are explicitly // imported with `import type`, which is - // necessary as svelte-preprocess cannot + // necessary as Svelte/Vite cannot // otherwise compile components correctly - "importsNotUsedAsValues": "error", + "verbatimModuleSyntax": true, // Vite compiles one TypeScript module // at a time, rather than compiling // the entire module graph "isolatedModules": true, - // TypeScript cannot 'see' when you - // use an imported value in your - // markup, so we need this - "preserveValueImports": true, + // Tell TS it's used only for type-checking + "noEmit": true, // This ensures both `vite build` // and `svelte-package` work correctly "lib": ["esnext", "DOM", "DOM.Iterable"], - "moduleResolution": "node", + "moduleResolution": "bundler", "module": "esnext", "target": "esnext" }