SvelteKit provides image optimization
SvelteKit includes image optimization capabilities.
Svelte · SvelteKit · all subjects
features
212 notes in this subject, read out of this brain and free to use. This is page 1 of 4.
SvelteKit provides offline support
SvelteKit includes offline support through service workers.
SvelteKit provides page preloading
SvelteKit includes preloading functionality to load pages before user navigation.
config option for adapter-specific configuration
The config option is an object with key-value pairs at the top level. Beyond that, the concrete shape is dependent on the adapter you're using. Every adapter should provide a Config interface to import for type safety.
adapter-static for fully static sites
If your entire app is suitable for prerendering, you can use adapter-static, which will output files suitable for use with any static webserver.
Page options static evaluation requirement
If all your page options are boolean or string literal values, SvelteKit will evaluate them statically. If not, it will import your +page.js or +layout.js file on the server (both at build time, and at runtime if your app isn't fully static) so it can evaluate the options. In the second case, browser-only code must not run when the module is loaded—import browser-only code in your +page.svelte or +layout.svelte file instead.
config objects are merged at top level only
config objects are merged at the top level (but not deeper levels). This means you don't need to repeat all the values in a +page.js if you want to only override some of the values in the upper +layout.js. Nested objects are replaced entirely, not merged.
handleError hook for processing unexpected errors
Unexpected errors go through the handleError hook, where you can add custom error handling such as sending errors to a reporting service or transforming the error object before it becomes page.error.
Root layout error handling uses fallback page
If an error occurs inside the root +layout.js or +layout.server.js, SvelteKit uses the fallback error page instead of an +error.svelte component, because the root layout would ordinarily contain the +error.svelte component.
Customizing error object shape with TypeScript
To add custom properties to error objects when using TypeScript, declare an App.Error interface in src/app.d.ts (or anywhere TypeScript can see it). The interface must be declared in the global App namespace and always includes a message: string property. Additional properties like code and id can be added.
Rendering errors do not update page.error property
Since rendering errors occur after the page has started rendering and multiple boundaries could catch distinct errors in parallel, the page object and its error property will not be updated. Instead, the error is passed directly to the +error.svelte component as a prop.
Error rendering in load functions reaches nearest +error.svelte
If an error occurs inside a load function while rendering a page, SvelteKit renders the +error.svelte component nearest to where the error occurred. If the error is in a load function in +layout(.server).js, the closest error boundary is an +error.svelte file above that layout, not next to it.
Error responses based on Accept headers
When an error occurs inside handle or inside a +server.js request handler, SvelteKit responds with either a fallback error page or a JSON representation of the error object, depending on the request's Accept headers.
Unexpected errors are not exposed to users
Unexpected errors (any exception other than those created with the error() helper) are not exposed to users. They are printed to the console or server logs in production, while users receive a generic error object with only { message: 'Internal Error' }.
Rendering errors with error boundary snippet
When handleRenderingErrors is enabled, you can define error boundaries using svelte:boundary with a failed snippet that receives the error object: {#snippet failed(error: App.Error)} ... {/snippet}.
handleRenderingErrors experimental option
In svelte.config.js, you can enable the experimental handleRenderingErrors option under kit.experimental to allow errors during server-side rendering to be caught by error boundaries and rendered with the nearest +error.svelte component, rather than returning a 500 error page.
error() helper imports from @sveltejs/kit
The error() helper used to throw expected errors is imported from @sveltejs/kit.
Expected error in load function example
In a load function, you can throw an expected error using error(404, { message: 'Not found' }) to indicate when a resource is not found. SvelteKit catches this exception, sets the response status code to 404, and renders the +error.svelte component.
Custom fallback error page with src/error.html
You can customize the fallback error page shown when errors occur in handle or +server.js request handlers by creating a src/error.html file. SvelteKit replaces the placeholders %sveltekit.status% and %sveltekit.error.message% with their corresponding values.
error() function signature for expected errors
The error() function takes two arguments: a status code (number) and an error object. The error object should have at least a message property. Example: error(404, { message: 'Not found' }). For convenience, you can also pass just a string as the second argument: error(404, 'Not found').
Query refresh method
Any query can be re-fetched via its refresh() method, which retrieves the latest value from the server. Queries are cached while on the page (getPosts() === getPosts()), so you don't need a reference to update the query.
Query deduplication and caching
When a query function is called, SvelteKit serializes the argument and uses it as a cache key. On the server, this creates a request-scoped cache so multiple invocations of the same query only happen once. On the client, multiple identical invocations of a query point to the same instance. The cache is shared as long as the query is in active use (rendered, awaited, or referenced), and the cached value is released once nothing uses it.
Query argument and return value serialization
Both the argument and return value of query functions are serialized with devalue, which handles types like Date and Map (and custom types defined in transport hooks) in addition to JSON. For query and prerender arguments (but not return values), objects, maps, and sets are sorted so that instances with the same members result in the same cache key.
query function with arguments and validation
Query functions can accept an argument such as a slug or ID. When a query exposes an HTTP endpoint with arguments, those arguments must be validated using a Standard Schema validation library such as Zod or Valibot. Pass the schema as the first argument to query(), followed by the async function.
form field all issues with fields.allIssues()
To get a list of all issues rather than those belonging to a single field, use the fields.allIssues() method. This will return undefined if the form is valid or has not yet been validated.
query function for reading server data
The query function allows you to read dynamic data from the server. The query returned works as a Promise that resolves to the returned data. On the client, query functions have loading, error, and current properties as alternatives to using await. Queries cannot be used when the entire page is prerendered (export const prerender = true).
form sensitive data handling with underscore prefix
Prevent sensitive data (such as passwords and credit card numbers) from being sent back to the user by using a field name with a leading underscore. When form data is invalid and the page reloads, fields with underscore-prefixed names will not be populated with their submitted values.
form redirect handling
Instead of returning data, the form callback can use the redirect(...) function to send the user to a new page. This sends a redirect response to the client.
form enhance method for customization
You can customize what happens when the form is submitted using the enhance method. It receives a copy of the form instance with the same properties and methods except enhance. Call form.submit() to perform the submission directly without re-running the enhance callback. Inside the callback, form.element is always defined.
query.batch for solving n+1 problem
query.batch works like query except it batches requests that happen within the same macrotask. On the server, the callback receives an array of the arguments the function was called with and must return a function of the form (input: Input, index: number) => Output. SvelteKit calls this with each input argument to resolve the individual calls with their results.
form client-side preflight validation
For client-side validation, specify a preflight schema by calling createPost.preflight(schema). This will populate issues() and prevent data from being sent to the server if validation fails. The preflight schema can be the same object as the server-side schema, though it won't be able to do server-side checks.
form programmatic validation with validate()
You can call validate() programmatically on a form to validate data without waiting for submission. This is useful for oninput callbacks (validating on every keystroke) or onchange callbacks. By default, issues are ignored for form controls that haven't been interacted with. Call validate({ includeUntouched: true }) to validate all inputs.
form validation error handling
If submitted data doesn't pass the schema validation, the callback will not run. Each invalid field's issues() method returns an array of { message: string } objects, and the aria-invalid attribute is set to true.
Remote function types: query, form, command, prerender
Remote functions come in four flavors: query (read dynamic data from the server), form (write data to the server via forms), command (write data from anywhere), and prerender (invoked at build time for static data). On the client, exported functions are transformed to fetch wrappers that invoke their counterparts on the server via a generated HTTP endpoint.
Remote function file naming and placement
Remote functions are exported from .remote.js or .remote.ts files. Remote files can be placed anywhere in the src directory except inside the src/lib/server directory. Third-party libraries can also provide remote files.
form select no-selection handling
If no selections are made in a select or select multiple input, the data will be undefined. For this reason, make the field optional in the schema, such as v.optional(v.array(...), []).
form select and select multiple inputs
Alternative to radio and checkbox groups, you can use select and select multiple inputs. Use .as('select') for single selection and .as('select multiple') for multiple selections.
form radio and checkbox value binding
For radio and checkbox inputs that all belong to the same field, the value must be specified as a second argument to .as(...). Use .as('radio', value) or .as('checkbox', value) to bind specific values to individual inputs.
form checkbox input handling
If a checkbox input is unchecked, the value is not included in the FormData object. Therefore, the value must be made optional in the schema. In Valibot use v.optional(v.boolean(), false), while in Zod use z.coerce.boolean<boolean>().
form file input handling
When a form contains file inputs, add an enctype="multipart/form-data" attribute to the form element. File inputs cannot be populated with default values via the second argument to .as().
form field nesting and value types
Fields can be nested in objects and arrays, and their values can be strings, numbers, booleans, or File objects. Nested objects and arrays are supported in the schema structure.
form field naming and type coercion
The generated name attribute uses JS object notation (e.g. nested.array[0].value). String keys that require quotes such as object['nested-array'][0].value are not supported. Boolean checkbox and number field names are prefixed with b: and n: respectively to signal SvelteKit to coerce values from strings prior to validation.
Enable remote functions in svelte.config.js
To use remote functions, you must opt in by setting two configuration options in svelte.config.js: kit.experimental.remoteFunctions must be set to true, and compilerOptions.experimental.async must be set to true.
form field rendering with .as() method
A form is composed of fields defined by the schema. To get attributes for a field, call its .as(...) method, specifying which input type to use. For most input types, you can also pass a second argument .as(type, value) to control the rendered value. The .as() method sets the correct input type, name, value population, and aria-invalid state.
form field schema validation
When a form callback uses the submitted data, it should be validated by passing a Standard Schema as the first argument to form(). The schema defines the fields in the form.
form programmatic validation with invalid helper
In addition to declarative schema validation, you can programmatically mark fields as invalid using the invalid helper from @sveltejs/kit. It throws like redirect or error and accepts multiple arguments that can be strings (for form-level issues) or standard-schema-compliant issues (for field-specific issues). Use the issue parameter for type-safe creation of such issues.
form function for server data mutation
The form function makes it easy to write data to the server. It takes a callback that receives data constructed from the submitted FormData and returns an object that can be spread onto a form element. The form object contains method and action properties that allow it to work without JavaScript (submitting data and reloading the page). It also has an attachment that progressively enhances the form when JavaScript is available, submitting data without reloading the entire page.
query.live service worker caching pitfall
It is essential to not cache live query responses in a service worker, since the cloned response will continue streaming long after the page is closed. Ensure caching logic excludes any responses with a Cache-Control header that includes no-store.
query.live async-iterable behavior
Live query instances are async-iterable. You can for await over the instance directly to get imperative access to the underlying stream of values. The first value yielded to a for await iterator is the most-recently-received value if one is available. Subsequent yields fire whenever a new value arrives. If values arrive faster than the consumer drains the iterator, only the latest pending value is kept.
form schema export location
You cannot export a schema from a .remote.ts or .remote.js file. The schema must either be exported from a shared module or from a <script module> block in the component containing the <form>.
requested().refreshAll() shorthand
The requested() function allows a shorthand: await requested(getPosts, 1).refreshAll() is equivalent to looping over the result and calling void query.refresh() for each item.
form field value access with value() method
Each field has a value() method that reflects its current value. As the user interacts with the form, it is automatically updated. Alternatively, fields.value() returns an object with all field values.
form field default values behavior
The value() of a field does not reflect defaults provided as a second argument to .as() (as in fields.title.as('text', '...')) until it is edited or submitted.
form field programmatic updates with set()
You can programmatically update a field or collection of fields via the set(...) method. Both createPost.fields.set({ title: '...', content: '...' }) and individual field updates like createPost.fields.title.set('...') are supported.
query.live connected property and reconnect method
Live queries expose a connected property and reconnect() method. If the connection drops, connected becomes false. SvelteKit attempts to reconnect passively with exponential backoff and actively if navigator.onLine goes from false to true. Unlike query, live queries do not have a refresh() method as they are self-updating.
form result property for return values
The form callback can return data, which is available as createPost.result. This value is ephemeral — it will vanish if you resubmit, navigate away, or reload the page. The result value need not indicate success and can also contain validation errors and data for repopulating the form on page reload.
query.live for real-time server data
query.live accesses real-time data from the server. The callback is typically an async generator function that returns an AsyncIterable. During server-side rendering, await getTime() returns the first yielded value then closes the iterator. On the client, the query stays connected while actively used in a component, with multiple instances sharing a connection. When no active uses remain, the stream disconnects and server-side iteration stops.
form error handling during submission
If an error occurs during form submission, the nearest +error.svelte page will be rendered.
Remote functions overview and availability
Remote functions are a tool for type-safe communication between client and server. They can be called anywhere in an app but always run on the server, allowing safe access to server-only modules containing things like environment variables and database clients. Remote functions are available since SvelteKit version 2.27. This feature is experimental and subject to change without notice.
form enhance automatic reset pitfall
When using enhance, the form is not automatically reset — you must call form.element.reset() if you want to clear the inputs.