A helper function for sequencing multiple handle calls in a middleware-like manner.
The behavior for the handle options is as follows:
transformPageChunk is applied in reverse order and merged
preload is applied in forward order, the first option "wins" and no preload options after it are called
filterSerializedResponseHeaders behaves the same as preload
/// file: src/hooks.server.jsimport{sequence}from'@sveltejs/kit/hooks';/// type: import('@sveltejs/kit/hooks').Handleasyncfunctionfirst({event,resolve}){console.log('first pre-processing');constresult=awaitresolve(event,{transformPageChunk:({html})=>{// transforms are applied in reverse orderconsole.log('first transform');returnhtml;},preload:()=>{// this one wins as it's the first defined in the chainconsole.log('first preload');returntrue;}});console.log('first post-processing');returnresult;}/// type: import('@sveltejs/kit/hooks').Handleasyncfunctionsecond({event,resolve}){console.log('second pre-processing');constresult=awaitresolve(event,{transformPageChunk:({html})=>{console.log('second transform');returnhtml;},preload:()=>{console.log('second preload');returntrue;},filterSerializedResponseHeaders:()=>{// this one wins as it's the first defined in the chainconsole.log('second filterSerializedResponseHeaders');returntrue;}});console.log('second post-processing');returnresult;}exportconsthandle=sequence(first,second);
The example above would print:
first pre-processing
first preload
second pre-processing
second filterSerializedResponseHeaders
second transform
first transform
second post-processing
first post-processing
Calling resolve invokes the next handler in the sequence (or SvelteKit itself, if it is the last one). To pass data between handlers, use event.locals.
A helper function for sequencing multiple handle calls in a middleware-like manner.
The behavior for the handle options is as follows:
transformPageChunk is applied in reverse order and merged
preload is applied in forward order, the first option "wins" and no preload options after it are called
filterSerializedResponseHeaders behaves the same as preload
/// file: src/hooks.server.jsimport{sequence}from'@sveltejs/kit/hooks';/// type: import('@sveltejs/kit/hooks').Handleasyncfunctionfirst({event,resolve}){console.log('first pre-processing');constresult=awaitresolve(event,{transformPageChunk:({html})=>{// transforms are applied in reverse orderconsole.log('first transform');returnhtml;},preload:()=>{// this one wins as it's the first defined in the chainconsole.log('first preload');returntrue;}});console.log('first post-processing');returnresult;}/// type: import('@sveltejs/kit/hooks').Handleasyncfunctionsecond({event,resolve}){console.log('second pre-processing');constresult=awaitresolve(event,{transformPageChunk:({html})=>{console.log('second transform');returnhtml;},preload:()=>{console.log('second preload');returntrue;},filterSerializedResponseHeaders:()=>{// this one wins as it's the first defined in the chainconsole.log('second filterSerializedResponseHeaders');returntrue;}});console.log('second post-processing');returnresult;}exportconsthandle=sequence(first,second);
The example above would print:
first pre-processing
first preload
second pre-processing
second filterSerializedResponseHeaders
second transform
first transform
second post-processing
first post-processing
Calling resolve invokes the next handler in the sequence (or SvelteKit itself, if it is the last one). To pass data between handlers, use event.locals.
Applies custom transforms to HTML. If done is true, it's the final chunk. Chunks are not guaranteed to be well-formed HTML
(they could include an element's opening tag but not its closing tag, for example)
but they will always be split at sensible boundaries such as %sveltekit.head% or layout/page components.
input
the html chunk and the info if this is the last chunk
:({html(parameter)html:string})=>{ // transforms are applied in reverse order
consolevarconsole:Console.log(method)Console.log(...data:any[]):void
The console.log() static method outputs a message to the console.
Determines which files should be preloaded. Files are preloaded via <link> tags added to the
<head> tag; if output.linkHeaderPreload is enabled, dynamically rendered pages use the
Link response header instead.
By default, js and css files will be preloaded.
For font files, input also has a filename property, the source file's pathname relative
to the project root, so that a filter can match on it instead of the hashed path. js and
css files are bundled and have no single source file name.
input
the type of the file and its path
:()=>{ // this one wins as it's the first defined in the chain
consolevarconsole:Console.log(method)Console.log(...data:any[]):void
The console.log() static method outputs a message to the console.
Applies custom transforms to HTML. If done is true, it's the final chunk. Chunks are not guaranteed to be well-formed HTML
(they could include an element's opening tag but not its closing tag, for example)
but they will always be split at sensible boundaries such as %sveltekit.head% or layout/page components.
input
the html chunk and the info if this is the last chunk
Determines which files should be preloaded. Files are preloaded via <link> tags added to the
<head> tag; if output.linkHeaderPreload is enabled, dynamically rendered pages use the
Link response header instead.
By default, js and css files will be preloaded.
For font files, input also has a filename property, the source file's pathname relative
to the project root, so that a filter can match on it instead of the hashed path. js and
css files are bundled and have no single source file name.
Determines which headers should be included in serialized responses when a load function loads a resource with fetch.
By default, none will be included.
name
header name
value
header value
:()=>{ // this one wins as it's the first defined in the chain
consolevarconsole:Console.log(method)Console.log(...data:any[]):void
The console.log() static method outputs a message to the console.
A helper function for sequencing multiple handle calls in a middleware-like manner.
The behavior for the handle options is as follows:
transformPageChunk is applied in reverse order and merged
preload is applied in forward order, the first option "wins" and no preload options after it are called
filterSerializedResponseHeaders behaves the same as preload
/// file: src/hooks.server.jsimport{sequence}from'@sveltejs/kit/hooks';/// type: import('@sveltejs/kit/hooks').Handleasyncfunctionfirst({event,resolve}){console.log('first pre-processing');constresult=awaitresolve(event,{transformPageChunk:({html})=>{// transforms are applied in reverse orderconsole.log('first transform');returnhtml;},preload:()=>{// this one wins as it's the first defined in the chainconsole.log('first preload');returntrue;}});console.log('first post-processing');returnresult;}/// type: import('@sveltejs/kit/hooks').Handleasyncfunctionsecond({event,resolve}){console.log('second pre-processing');constresult=awaitresolve(event,{transformPageChunk:({html})=>{console.log('second transform');returnhtml;},preload:()=>{console.log('second preload');returntrue;},filterSerializedResponseHeaders:()=>{// this one wins as it's the first defined in the chainconsole.log('second filterSerializedResponseHeaders');returntrue;}});console.log('second post-processing');returnresult;}exportconsthandle=sequence(first,second);
The example above would print:
first pre-processing
first preload
second pre-processing
second filterSerializedResponseHeaders
second transform
first transform
second post-processing
first post-processing
Calling resolve invokes the next handler in the sequence (or SvelteKit itself, if it is the last one). To pass data between handlers, use event.locals.
A helper function for sequencing multiple handle calls in a middleware-like manner.
The behavior for the handle options is as follows:
transformPageChunk is applied in reverse order and merged
preload is applied in forward order, the first option "wins" and no preload options after it are called
filterSerializedResponseHeaders behaves the same as preload
/// file: src/hooks.server.jsimport{sequence}from'@sveltejs/kit/hooks';/// type: import('@sveltejs/kit/hooks').Handleasyncfunctionfirst({event,resolve}){console.log('first pre-processing');constresult=awaitresolve(event,{transformPageChunk:({html})=>{// transforms are applied in reverse orderconsole.log('first transform');returnhtml;},preload:()=>{// this one wins as it's the first defined in the chainconsole.log('first preload');returntrue;}});console.log('first post-processing');returnresult;}/// type: import('@sveltejs/kit/hooks').Handleasyncfunctionsecond({event,resolve}){console.log('second pre-processing');constresult=awaitresolve(event,{transformPageChunk:({html})=>{console.log('second transform');returnhtml;},preload:()=>{console.log('second preload');returntrue;},filterSerializedResponseHeaders:()=>{// this one wins as it's the first defined in the chainconsole.log('second filterSerializedResponseHeaders');returntrue;}});console.log('second post-processing');returnresult;}exportconsthandle=sequence(first,second);
The example above would print:
first pre-processing
first preload
second pre-processing
second filterSerializedResponseHeaders
second transform
first transform
second post-processing
first post-processing
Calling resolve invokes the next handler in the sequence (or SvelteKit itself, if it is the last one). To pass data between handlers, use event.locals.
The handle hook runs every time the SvelteKit server receives a request and
determines the response.
It receives an event object representing the request and a function called resolve, which renders the route and generates a Response.
This allows you to modify response headers or bodies, or bypass SvelteKit entirely (for implementing routes programmatically, for example).
The handle hook runs every time the SvelteKit server receives a request and
determines the response.
It receives an event object representing the request and a function called resolve, which renders the route and generates a Response.
This allows you to modify response headers or bodies, or bypass SvelteKit entirely (for implementing routes programmatically, for example).
Applies custom transforms to HTML. If done is true, it's the final chunk. Chunks are not guaranteed to be well-formed HTML
(they could include an element's opening tag but not its closing tag, for example)
but they will always be split at sensible boundaries such as %sveltekit.head% or layout/page components.
input
the html chunk and the info if this is the last chunk
:({html(parameter)html:string})=>{ // transforms are applied in reverse order
consolevarconsole:Console.log(method)Console.log(...data:any[]):void
The console.log() static method outputs a message to the console.
Determines which files should be preloaded. Files are preloaded via <link> tags added to the
<head> tag; if output.linkHeaderPreload is enabled, dynamically rendered pages use the
Link response header instead.
By default, js and css files will be preloaded.
For font files, input also has a filename property, the source file's pathname relative
to the project root, so that a filter can match on it instead of the hashed path. js and
css files are bundled and have no single source file name.
input
the type of the file and its path
:()=>{ // this one wins as it's the first defined in the chain
consolevarconsole:Console.log(method)Console.log(...data:any[]):void
The console.log() static method outputs a message to the console.
The handle hook runs every time the SvelteKit server receives a request and
determines the response.
It receives an event object representing the request and a function called resolve, which renders the route and generates a Response.
This allows you to modify response headers or bodies, or bypass SvelteKit entirely (for implementing routes programmatically, for example).
Applies custom transforms to HTML. If done is true, it's the final chunk. Chunks are not guaranteed to be well-formed HTML
(they could include an element's opening tag but not its closing tag, for example)
but they will always be split at sensible boundaries such as %sveltekit.head% or layout/page components.
input
the html chunk and the info if this is the last chunk
Determines which files should be preloaded. Files are preloaded via <link> tags added to the
<head> tag; if output.linkHeaderPreload is enabled, dynamically rendered pages use the
Link response header instead.
By default, js and css files will be preloaded.
For font files, input also has a filename property, the source file's pathname relative
to the project root, so that a filter can match on it instead of the hashed path. js and
css files are bundled and have no single source file name.
Determines which headers should be included in serialized responses when a load function loads a resource with fetch.
By default, none will be included.
name
header name
value
header value
:()=>{ // this one wins as it's the first defined in the chain
consolevarconsole:Console.log(method)Console.log(...data:any[]):void
The console.log() static method outputs a message to the console.
A helper function for sequencing multiple handle calls in a middleware-like manner.
The behavior for the handle options is as follows:
transformPageChunk is applied in reverse order and merged
preload is applied in forward order, the first option "wins" and no preload options after it are called
filterSerializedResponseHeaders behaves the same as preload
/// file: src/hooks.server.jsimport{sequence}from'@sveltejs/kit/hooks';/// type: import('@sveltejs/kit/hooks').Handleasyncfunctionfirst({event,resolve}){console.log('first pre-processing');constresult=awaitresolve(event,{transformPageChunk:({html})=>{// transforms are applied in reverse orderconsole.log('first transform');returnhtml;},preload:()=>{// this one wins as it's the first defined in the chainconsole.log('first preload');returntrue;}});console.log('first post-processing');returnresult;}/// type: import('@sveltejs/kit/hooks').Handleasyncfunctionsecond({event,resolve}){console.log('second pre-processing');constresult=awaitresolve(event,{transformPageChunk:({html})=>{console.log('second transform');returnhtml;},preload:()=>{console.log('second preload');returntrue;},filterSerializedResponseHeaders:()=>{// this one wins as it's the first defined in the chainconsole.log('second filterSerializedResponseHeaders');returntrue;}});console.log('second post-processing');returnresult;}exportconsthandle=sequence(first,second);
The example above would print:
first pre-processing
first preload
second pre-processing
second filterSerializedResponseHeaders
second transform
first transform
second post-processing
first post-processing
Calling resolve invokes the next handler in the sequence (or SvelteKit itself, if it is the last one). To pass data between handlers, use event.locals.
first pre-processing
first preload
second pre-processing
second filterSerializedResponseHeaders
second transform
first transform
second post-processing
first post-processing
Calling resolve invokes the next handler in the sequence (or SvelteKit itself, if it is the last one). To pass data between handlers, use event.locals.
functionsequence(...handlers:Handle[]):Handle;
CaughtError
The error passed to the handleError hooks.
Use the kind discriminant to distinguish errors from your app (thrown with the
error helper), errors generated by
SvelteKit itself (such as 404s), validation errors, and unknown errors (thrown by your code,
or code it calls).
typeCaughtError<IssueextendsStandardSchemaV1.Issue=StandardSchemaV1.Issue>=|{[KindinkeyofCaughtErrorMap]:{/** Identifies the category and origin of the error */kind:Kind;/** The caught error. Its type depends on `kind` */error:CaughtErrorMap[Kind];/** Only present for validation errors */issues?:undefined;};}[keyofCaughtErrorMap]|ValidationCaughtError<Issue>;
ClientCaughtError
The error passed to the client-side handleError hook.
The init will be invoked once the app starts in the browser
typeClientInit=()=>MaybePromise<void>;
Handle
The handle hook runs every time the SvelteKit server receives a request and
determines the response.
It receives an event object representing the request and a function called resolve, which renders the route and generates a Response.
This allows you to modify response headers or bodies, or bypass SvelteKit entirely (for implementing routes programmatically, for example).
The client-side handleError hook runs for every error thrown while navigating, except redirects.
Errors that were already transformed by the server-side hook are not passed to it a second time.
The kind property discriminates between app errors (thrown with the error helper),
framework errors (generated by SvelteKit itself, such as 404s) and unknown errors (thrown by your code, or code it calls).
The hook returns an object matching App.Error, in which status and message are optional — return them only to
override the defaults. Omitted properties are inherited from the caught error: the body passed to error(...) for app errors,
the status and safe message for framework errors, and 500 / 'Internal Error' for unknown errors. Return nothing to
keep the defaults entirely (if you augment App.Error with required properties, you must return those).
Make sure that this function never throws an error.
The handleFetch hook allows you to modify (or replace) the result of an event.fetch call that runs on the server (or during prerendering) inside an endpoint, load, action, handle, handleError or reroute.
The server-side handleError hook runs for every error thrown while responding to a request, except redirects.
The kind property discriminates between app errors (thrown with the error helper),
framework errors (generated by SvelteKit itself, such as 404s), validation errors (caused by invalid remote function arguments)
and unknown errors (thrown by your code, or code it calls).
The hook returns an object matching App.Error, in which status and message are optional — return them only to
override the defaults. Omitted properties are inherited from the caught error: the body passed to error(...) for app errors,
the status and safe message for framework and validation errors, and 500 / 'Internal Error' for unknown errors. Return nothing to
keep the defaults entirely (if you augment App.Error with required properties, you must return those).
Make sure that this function never throws an error.
input the html chunk and the info if this is the last chunk
Applies custom transforms to HTML. If done is true, it’s the final chunk. Chunks are not guaranteed to be well-formed HTML
(they could include an element’s opening tag but not its closing tag, for example)
but they will always be split at sensible boundaries such as %sveltekit.head% or layout/page components.
Determines which headers should be included in serialized responses when a load function loads a resource with fetch.
By default, none will be included.
Determines which files should be preloaded. Files are preloaded via <link> tags added to the
<head> tag; if output.linkHeaderPreload is enabled, dynamically rendered pages use the
Link response header instead.
By default, js and css files will be preloaded.
For font files, input also has a filename property, the source file’s pathname relative
to the project root, so that a filter can match on it instead of the hashed path. js and
css files are bundled and have no single source file name.
ServerInit
Available since 2.10.0
The init will be invoked before the server responds to its first request
typeServerInit=()=>MaybePromise<void>;
Transport
Available since 2.11.0
The transport hook allows you to transport custom types across the server/client boundary.
Each transporter has a pair of encode and decode functions. On the server, encode determines whether a value is an instance of the custom type and, if so, returns a non-falsy encoding of the value which can be an object or an array (or false otherwise).
In the browser, decode turns the encoding back into an instance of the custom type.
The transport hook allows you to transport custom types across the server/client boundary.
Each transporter has a pair of encode and decode functions. On the server, encode determines whether a value is an instance of the custom type and, if so, returns a non-falsy encoding of the value which can be an object or an array (or false otherwise).
In the browser, decode turns the encoding back into an instance of the custom type.
The transport hook allows you to transport custom types across the server/client boundary.
Each transporter has a pair of encode and decode functions. On the server, encode determines whether a value is an instance of the custom type and, if so, returns a non-falsy encoding of the value which can be an object or an array (or false otherwise).
In the browser, decode turns the encoding back into an instance of the custom type.