Proposal: context function

[kran6a]

TL;DR: What it is

//+layout.ts
import type {ContextLoad, LayoutLoad} from './$types.js';

export const context = ({parent_context, url, ...rest})=>{
    const auth = new AuthService(/*parameters*/);
    const analytics = new AnalyticsService(/*parameters*/);
    return {
        services: {
            auth: instantiate_auth_service(/*Some parameters*/);
            async [Symbol.asyncDispose]() {
                await analytics.flush();
                analytics.close_ws();
            }
        }
    }
}) satisfies ContextLoad;

export const load = (({context})=>{ //context includes the value returned from the context function defined above
/*Code here*/
}) satisfies LayoutLoad;

Why it is necessary

1. As a mechanism for dependency injection and dependency management.
2. Better modularization primitives.
3. As an adapter-static enjoyer I abuse load functions to do this but it is not semantically coherent.

//+page.svelte
<script lang="ts">
    import type {PageProps} from './$types.js';
    const {data}: PageProps = $props();
    data.services.analytics.browser_data.send(/*some_data*/);
</script>

I am accessing services through a prop called data that the docs say should hold data, not services.

I also don't like abusing APIs like this because I know other devs will copy it without fully understanding its implications, things will break because they use adapter-node and they will proceed as explained in the following point.

4. Frameworks not giving you good abstractions result in either the wrong abstraction being used, a "clever" workaround being used (see point 3) or a new abstraction being created by the user. Depending on the user experience and skills the new abstraction can be good, mid, hacky, buggy, ai-generated or will make no sense at all (like using global state).
5. Standardization and normalization. "How do I X with Y framework? => read the docs" instead of "How do I X with Y framework? => we did it by creating an instance of RubeGoldberg2 then calling the static apply method on it but the team lead says we should use the RubeGoldberg4 class as the RubeGoldberg class was deprecated many years ago due to the many bugs it contains. Unfortunately the RubeGoldberg4 class does not support your use-case yet so you may want to use RubeGoldberg3V2 and change it when we update RubeGoldberg4, just make sure you delete the "DO_NOT_USE_RG3V2_OR_YOU_WILL_BE_FIRED" global variable immediately after calling the apply method because there is a test in CI that will break" . Standardization and normalization is specially useful for ai-generated code: less different ways to do a thing leads to better ai-generated code that the devs can actually understand and reason about instead of blindly accepting whatever slop the ai spits.
6. Can be used in both, universal and server files, no need to worry about return types being serializable as you won't be sending contexts over the net. Context in universal files may require being initializable in both, server and browser depending on the adapter you use (the same as load functions return types).

How it works

Similarly to load functions, values returned by stacked contexts are merged, and load functions have access to the value resulting from their sibling context function (merged with parent contexts).

+*.server.ts files do not share context nor context type with non +*.server.ts files and vice-versa.

+page.svelte and +layout.svelte get a context prop along with data, the context prop always refers to "universal" context in .svelte files as it makes no sense to refer to the server context there. The server context is meant for the server only.

Symbol.dispose and Symbol.asyncDispose are both called (if defined) when we navigate away from the corresponding page/layout so we can clean the mess (e.g: gracefully closing ws, clearing some localStorage keys used only to persist some form state, removing global event listeners, etc.).

Docs

First of all note that I only use adapter-static so I might be missing some edge cases here.

Docs should show a very big and red warning stating that server and client context are separate so doing context.clicked+=1 inside an onclick handler will not magically update the value of context.clicked in the server.

Docs should recommend using pure context functions.

Docs should discourage returning context data from load functions.

//+layout.ts
import type {ContextLoad, LayoutLoad} from './$types.js';

export const context = ({parent_context, url, ...rest})=>{
    const auth = new AuthService(/*parameters*/);
    const analytics = new AnalyticsService(/*parameters*/);
    return {
        services: {
            auth: instantiate_auth_service(/*Some parameters*/);
            async [Symbol.asyncDispose]() {
                await analytics.flush();
                analytics.close_ws();
            }
        }
    }
}) satisfies ContextLoad;

export const load = (async ({context})=>{ //context includes the value returned from the context function defined above
    const auth_result = await context.services.auth.login(/*Some params*/);//GOOD, context is used to generate a response we return
    return {
        auth: context.services.auth, //BAD, service is already available under the context prop and might not be serializable
        account: auth_result //GOOD
    };
}) satisfies LayoutLoad;

What about the current thing called context in svelte

I only have negative opinions in regard to that context.

I have never used it and I don't think I ever will. I even prefer using load functions for context management to using the existing context API.

Some of those my opinions against the current context API are:

1. I don't want to initialize services that start WS connections just because there are 2-3 pages that are rarely visited that really need it. I don't want to code a workaround to initialize them lazily and then manually de-initialize them when the user navigates elsewhere.
2. I don't want to get the context via getContext('key'). I am too dumb to remember what I named my contexts and too lazy to type their full names as strings. I want to write a letter and hit autocomplete to access my context. I want my context to be strongly typed out of the box so I can keep hitting autocomplete without ending up calling some service that is not really there or has not been initialized or even getting no context at all because I mispelled the context name.
3. I don't want to initialize things like an error reporting service globally while it is only used in a few pages. I don't want to remember how the context having the error reporting service is named. (see point 4 in "Why it is important")
4. I don't want to write code to make this context fit my needs. (see point 4 in "Why it is important")
5. I don't want to define a context per every combination of services I may use on any given page. That is not maintainable. I just want to specify which services are needed by layout and by page and get the context automagically merged and built, overriding parent services if necessary (for example overriding the account service on a layout meant for authenticated users so it includes methods only available to those users).

[MathiasWP]

Having dependency injection built in would be amazing!