Hook for initialization?

[hgl]

Is your feature request related to a problem? Please describe.
It should be pretty common for a svelt kit app to utilize external services that you need to initialize clients to talk to them. The doc demonstrates such use case:

import db from '$lib/database';

export async function get({ params }) {
	const { slug } = params;
	const article = await db.get(slug);
	// ...
}

One issue with this code is that it assumes db can be initialized in the module itself either synchronously (which is not always the case) or via top-level await (which svelte kit doesn't seem to support).

Describe the solution you'd like
Offer a hook like async func init() {} that only runs once when it starts?

Describe alternatives you've considered

How important is this feature to you?
Very, since it's pretty awkward to workaround when the initialization is async (e.g., force initialization to be synchronous and only call the async part when actually talk to external services).

Additional context

[ignatiusmb]

Possibly related to #1530

[hgl]

That issue is about client initialization. But yeah, the two issues should probably be considered en masse to ensure an intuitive API.

[hgl]

Another way to solve this problem is that svelte kit offers a central place to initialize such clients, and pass the clients as an argument to endpoints and hooks:

export async function get({ params, svcs }) {
	const { slug } = params;
	const article = await svcs.db.get(slug);
	// ...
}

This seems to be more conventional than the approach that a module is directly usable as an external service.

[babichjacob]

You seem to have missed the request.locals convention in the handle hook. Here's an example from the SvelteKit demo app:

kit/packages/create-svelte/templates/default/src/hooks.ts

Lines 1 to 7 in 6372690

	import cookie from 'cookie';
	import { v4 as uuid } from '@lukeed/uuid';
	import type { Handle } from '@sveltejs/kit';
	export const handle: Handle = async ({ request, render }) => {
	const cookies = cookie.parse(request.headers.cookie || '');
	request.locals.userid = cookies.userid || uuid();

There's no rule that you have to re-do work every request (or that the information involved has to be personalized to the user that made the request). Let me demonstrate:

// src/hooks.js
import { stuff } from "db-library";

async function setupDatabaseOrAnythingReally() {
    const dbClient = await stuff({ ...options });
    return dbClient;
}

// Initialize the database *once*
const dbPromise = setupDatabaseOrAnythingReally();

/** @type {import('@sveltejs/kit').Handle} */
export async function handle({ request, render }) {
    // Wait for the db to initialize the first time
    // or instantly get the result of when it was initialized
    const db = await dbPromise;
    
    // Make the database available to the endpoint answering the request
    request.locals = { db };
    return await render(request);
}

locals in an endpoint work the same as your svcs:

// src/routes/blog/[article].json.js
 export async function get({ params, locals }) {
	const { slug } = params;
	const article = await locals.db.get(slug);
	// ...
}

[babichjacob]

Another maintainer can re-open this if I'm mistaken about what this feature request was about.

[hgl]

Thanks for the tip.

However I think this means that clients are actually initialized at the first connection, potentially delaying it (and other connections) if the initialization is not trivial.

[babichjacob]

However I think this means that clients are actually initialized at the first connection, potentially delaying it (and other connections) if the initialization is not trivial.

I believe that promises automatically "start executing" the next tick after being created, so this shouldn't be an issue. You can verify by putting a console log at the beginning of the initialization function and see when it shows up.

[hgl]

Oh you are correct. I forgot how promise works lol. Thanks. This works.

[hgl]

Two minor issues I encountered while working with real code:

1. During development, hook.ts is not executed until there is a connection. I guess this is due to the lazy-loading nature of vite. It's not a big deal in development, but the disparity between dev and prod can potentially be a problem.
2. During build hook.ts is executed. This can be a problem if your build environment isn't qualified to initialize external services.

For #2, I guess it's executed because svelte kit tries to account for pre-rendered routes? I don't have any such routes, but even if I did, they don't always depend on external services.

[babichjacob]

2. During build `hook.ts` is executed. This can be a problem if your build environment isn't qualified to initialize external services.

Wrap the stuff you don't want to happen during build with if (!prerendering) https://kit.svelte.dev/docs#modules-$app-env

[ignatiusmb]

I've just spent an unnecessarily long time with a certain problem that might be simpler if this was a thing, I was thinking to post this in #1530, but "hook for initialization" might be more appropriate. Can this be reconsidered as it would be more straightforward than the solution/workaround below?

---

The problem I was having is with an external library that provides an .init() function that can be filled with our own options and properties, everything that needs to happen before any user code is executed. There's no server.js or client.js anymore and instead (replaced with?) just hooks.js.

Now, I feel it's reasonable to assume that hooks are both server and client combined, so placing the .init() once in there should makes sense and in theory prepopulate the library options. But that isn't the case here and I've got to mess around inside node_modules itself to find out that the options that should be passed through .init() are still undefined in certain places of execution. This actually breaks SvelteKit in a way that cannot be debugged at all, it renders the page with everything for a second and then immediately throws an error, that's weirdly not caught by the ErrorLoad but shows the error page.

Inlining the options in the node_modules file itself works and successfully runs the app no problem, so it's not the library nor SvelteKit's fault, but changing the package through node_modules directly can't be considered a solution. I tried a lot more other ways in hooks to solve this but none seems to work.

I even tried to block off the whole handle hook from running before .init() function finishes, and at this point I realize that it might just not run at all. As a last resort, I duplicated all the initializing that's called in hooks and copied them to __layout, and everything works perfectly. Now, this is a huge problem because as the docs stated, it runs on both pages and endpoints, so it should've prepopulated the options without having to call them in __layout again.

kit/documentation/docs/04-hooks.md

Line 11 in eae1b1d

This function runs on every request, for both pages and endpoints, and determines the response. It receives the `request` object and a function called `resolve`, which invokes SvelteKit's router and generates a response accordingly. This allows you to modify response headers or bodies, or bypass SvelteKit entirely (for implementing endpoints programmatically, for example).

[hgl]

@babichjacob Great tip! I totally forgot about build flags.

@ignatiusmb I believe hooks are server side only, "pages" in the referenced doc refers to their SSR step.

I do think hooks.ts's ability to function as the initiation point is not self-evident, might be worth to document it. I'll send a PR within the week if no one beats me to it.