[feat] helper for creating stores

[benmccann]

Describe the problem

You can't just blindly create a store in SSR or it'll end up being a global store shared by all users (#4339). We should provide a helper that ties it to the request.

Describe the proposed solution

At the very least we can make it part of the Svelte context. SvelteKit does this internally with its own stores.

I wonder if we couldn't make it available earlier. If we only make it part of the Svelte context then you can't use it in load. If we additionally tied it to the request it would be available throughout the rendering of the request.

We could have an API like:

export const getStore = function(key, request) {
  return request ? WEAK_MAP.get(request).get(key) : getContext(key);
};

When we're going to start rendering the templates we could populate the context from the map.

We could also have a method to create a store. Being able to call it in handle would solve #7107:

createStore(request, 'whatever', request.locals.whatever);

There are a couple things we might make optional. E.g. we could potentially look for 'whatever' in locals automatically. Or we could make the request optional - if it's not provided the store would only be available in the template (at least on the server).

Alternatives considered

The user could create the store themselves if we just want it available in the template. That starts getting cumbersome if they want it available either as a singleton in the browser or tied to the request on the server. It's impossible if they want to populate it from locals

Some of the APIs I've proposed here may be open for debate on the actual details

Importance

would make my life easier

Additional Information

No response

[williamviktorsson]

Great idea. Would it make sense to provide different options of how and when the store should be created and populated. Such as ”once on first page load” or ”for every page load” or

I Imagine this might be useful for the large amount of people who enjoy integrating client side stores with responsive backend functionality such as firebase authentication / snapshot listeners.

Not sure what it would look like though or if it makes sense, or if these types of behaviors would have to be solved by each developer.

[dummdidumm]

The idea sounds good, I'm not fully sure on the details yet. I think this only makes sense in the context of the shared load function, so it runs on the server on first render and is updated within the client afterwards. So locals would be the shared thing on the server and this would be the shared thing in the shared load (basically the same split as with session previously). Also, is handle the best place for this? handle runs for every request, but this would only be available inside the shared load function. Something like getSession makes more sense to me.

Another thing I'm not sure about is if this should be reserved for stores only, or if you could place arbitrary things in there. You could place arbitrary things inside stores though, and having it a non-store only makes sense for things that never update, which shouldn't live inside this anyway - so, probably fine?

[PatrickG]

Instead of createStore(request, 'whatever', request.locals.whatever); I think it would make more sense to add or set a store to the request.
Something like:

import type { Readable } from 'svelte/store';
function set/addStore<T extends Readable = Readable>(key: any; store: T): void;
function getStore<T extends Readable = Readable>(key: any): T;

Basically, we need something similar to Svelte's ContextApi, but on the server it is bound to the request, on the client it is bound to nothing.

[david-plugge]

A shared object across shared load functions would be amazing! (Maybe change the name to something else since it´s not only about session data?)

But creating stores would make things a bit complicated. Svelte stores are pretty useless on the server side, atleast i don´t get the benefit. We already have locals for server context, eventually something like session for shared context (like @dummdidumm suggested) and svelte´s context for ui context.

With $page.data we already have a store that´s always in sync and keeps all data in one spot. I wonder why that´s not sufficient?
Seems more like a doc thing making clear how stores work and how to safely use them with sveltekit.

[david-plugge]

If it´s just about using something shorter than $page.data.user this helper can be used:

import type { Page } from '@sveltejs/kit';
import { browser } from '$app/environment';
import { page } from '$app/stores';
import { derived, type Readable } from 'svelte/store';

function derivedFromPage<T>(fn: (page: Page) => T): Readable<T> {
	let store: Readable<T>;

	return {
		subscribe(run, invalidate?) {
			if (!browser || !store) store = derived(page, fn);
			return store.subscribe(run, invalidate);
		}
	};
}

export const user = derivedFromPage(($page) => $page.data.user);

[dummdidumm]

Copying my Discord-thoughts into here:

What became clear to me that getSession was used for multiple things at once.

1. pass data from server to client load functions
2. make cross-cutting data easily available across all client load functions
3. trigger a load function to rerun when data changes (e.g. $session.user = null)
4. a convenient writable store that is somewhat global

Because it had so many use cases in once, it became somewhat confusing what runs when, because people may only think about 4 and then wonder about 3. So I think removing it in its form was correct, but we need some features that bring back the mentioned points in a easy-to-use way. Right now we have this situation:

1. pass data -> can do this now by having a +layout.server.js and passing whatever you want to the client
2. cross-cutting data -> use await parent() -> this introduces a waterfall because you can't tell "hey I'm only interested in the data from parent X, don't wait on the 3 other layout loads after that". Something like locals for the client side would help with this.
3. trigger rerun -> there's nothing built-in for this right now. Rich shared a pattern somewhere about creating a custom state which triggers a unique invalidate function under the hood. Maybe it's enough to make this a blessed pattern and/or tidy it up a little and provide a wrapper around it.
4. convenient writable store -> again, nothing built-in, this would be this issue
   3+4. It's not clear to me how to achieve a combination of these two in a nice API. session made it possible because it was on both sides.

--> I feel like we need to add recipes and/or APIs to ease this

[david-plugge]

An issue i´ve run into a few times now is not beeing able to update $page.data client side.

Example:

You display some database rows in your app and add another row.
You call fetch and post the data to a +server endpoint or make use of the form actions.
The only option (that i know of) to get the added row is to call invalidate and reload all page related data.
This will obviously result in twice the network calls compared to just adding the newly created data to $page.data.

One way i´ve solved this:

import { invalid } from '@sveltejs/kit';
import type { PageServerLoad, Actions } from './$types';

export const load: PageServerLoad = async () => {
	return {
		// just some random test data
		posts: [{ title: 'Post 1' }, { title: 'Post 2' }, { title: 'Post 3' }]
	};
};

export const actions: Actions = {
	async addPost({ request }) {
		const data = await request.formData();
		const title = data.get('title') as string;

		if (!title) {
			return invalid(400, {
				titleMissing: true
			});
		}
		return {
			newPost: { title }
		};
	}
};

make it a store in +page.ts

export const load: PageLoad = ({ data }) => {
	return {
		posts: writable(data.posts)
	}
}

and update that store inside +page.svelte

<script lang="ts">
	import { applyAction, enhance, type SubmitFunction } from '$app/forms';
	import type { PageData, ActionData } from './$types';

	export let form: ActionData;
	export let data: PageData;

	$: posts = data.posts;

	const handleAddPost: SubmitFunction<{ newPost: { title: string } }> =
		() =>
		async ({ result, update }) => {
			if (result.type === 'success') {
				await applyAction(result);

				posts.update(($posts) => {
					$posts.push(result.data!.newPost);
					return $posts;
				});
				return;
			}
			update();
		};
</script>

<ul>
	{#each $posts as item}
		<li>{item.title}</li>
	{/each}
</ul>

<form action="?/addPost" method="post" use:enhance={handleAddPost}>
	{#if form?.titleMissing}
		<p class="error">Please enter a title</p>
	{/if}
	<input name="title" type="text" placeholder="Title" />
	<button type="submit">Submit</button>
</form>

I´m just curious if this api/helper, if it´s going to be a thing, will provide an easier way to get writable stores from the client to the server in such use cases.

[Rich-Harris]

One of the lessons of session was that stores as inputs to load is problematic. But we can return stores from load:

// src/routes/+layout.js
export function load() {
  return {
    count: writable(0)
  };
}

<!-- src/routes/+page.svelte -->
<script>
  import { page } from '$app/stores';

  $: count = $page.data.count;
</script>

<button on:click={() => $count += 1}>clicks: {$count}</button>

We can use this pattern for user-specific data, for app-wide data, and so on. It's easy to vary the type of store based on whether we're in a server or browser environment (e.g. get a snapshot of chat messages on the server, upgrade to a real time subscription in the client, etc).

Is there anything that isn't covered by this pattern, especially that needs to be resolved before 1.0?

[david-plugge]

I think this pattern is very powerful and covers most if not all use cases i can think of.
We just need some examples that make clear how and when to use this.

[dummdidumm]

I long wanted to write a "State Management" section for the docs, where we also can note the "careful what to put on the server, it's shared for all requests"-stuff. This pattern could also go in there.