Removing session

[Rich-Harris]

Update: session was removed in #5946

One of the great joys of designing APIs is the realisation, when you finally hit upon the right design, that previously hard problems become trivial to solve. An example: while we were coming up with #5748, we realised that it gave us the opportunity to generate types for export let data, giving you incredibly low-effort type safety.

In other cases, it's being able to remove features of the design that existed to compensate for shortcomings that no longer exist. session is one of those features.

What is session?

session is an app-level construct that basically exists to get commonly-needed data from the server to the client. Most often, it's used for information about the current user. The data is available in load functions and via the session store.

It is created by the getSession hook.

Why don't we need it any more?

When we introduced 'page endpoints', we solved the problem of getting data from the server to the client, but only for 'leaf nodes'. After #5748, we have a much more general solution — all you need to do is put some data in your root +layout.server.js file...

// src/routes/+layout.server.js

/** @type {import('./$types').LayoutServerLoad} */
export async function load({ request, setHeaders }) {
  return {
    user: await db.getUser(request.headers.get('cookie'))
  };
}

...and every load function can access it with parent...

// src/routes/some/where/+page.js

/** @type {import('./$types').PageLoad} */
export async function load({ parent }) {
  const { user } = await parent();
  // ...
}

...and every page can access it via $page.data:

<script>
  import { page } from '$app/stores';
</script>

{#if $page.data.user}
  <h1>Welcome back {$page.data.user.name}!</h1>
{:else}
  <p>Please <a href="/login">log in</a> or <a href="/register">register</a>.</p>
{/if}

If a load function didn't depend on user, it would no longer be blocked on db.getUser, unlike today.

Ok but is it doing any harm?

Yes.

For one thing, any concept that increases the API surface area is bad, other things being equal — it's just more stuff to learn. In the case of session it touches the API in three separate places — load, $app/stores and getSession.

It causes confusion in other ways. Navigating from a prerendered page to a non-prerendered page results in an unpopulated session (#4426), which is very hard to solve cleanly. Because it's a writable store, people sometimes write to it, and that causes load to re-run at times they don't expect (#3732/#2301).

It also causes unnecessary work. On https://svelte.dev, we have to read session data from Supabase for every single request, even though the only place we actually need session data is https://svelte.dev/repl and https://svelte.dev/apps. (I only just realised this, but since we're prerendering most of the site, this means we're affected by the unpopulated session bug described in the last paragraph. That's how insidious the bug is!)

Getting rid of all this stuff would be a huge win.

[n-pn]

I'm all for removing getSession and $session store all together, but using const { user } = await parent(); is less than ideal. For some type of application this line will be yet another mandatory boilerplate code that you'd need to copy all the time. And you lose the ability to stream html output, too.

[cdcarson]

@tedsteen I'm not sure that's true. My understanding of the +layout.server.js tree is that it is intended as a cache. Any +layout.server.js in the tree will only be re-fetched if it accesses event.params or event.url (and those things have changed) or if your client code has invalidated that part of the tree. If not, the client router uses its cached version of the data. https://kit.svelte.dev/docs/load#invalidation

But I may be wrong, or misunderstanding what you are getting at.

[tedsteen]

It might be a bug then because that's how it behaves atm.

[cdcarson]

It might be a bug then because that's how it behaves atm.

Not for me. For src/routes/+layout.server.ts, if I do this...

import type { LayoutServerLoad, LayoutServerLoadEvent } from './$types';
export const load: LayoutServerLoad<App.PageData> = (
  event: LayoutServerLoadEvent
): App.PageData => {
  console.log('root +layout.server.ts called', event.url.pathname) //<-- accessor
  return {
   // ...whatever
  };
};

...the load is called every client side page navigation, since I'm accessing event.url.pathname. But if I get rid of that...

import type { LayoutServerLoad, LayoutServerLoadEvent } from './$types';
export const load: LayoutServerLoad<App.PageData> = (
  event: LayoutServerLoadEvent
): App.PageData => {
  console.log('root +layout.server.ts called') //<-- removed accessor
  return {
   // ...whatever
  };
};

...the load is only called during a full page reload (when the user first goes to the app, or I force a redirect) or when a piece of client side code does invalidate().

If this is not what you're seeing, you probably should file a bug.

[CaptainCodeman]

From the code you posted in discord, it's your load function - it almost looks like you're trying to create your own routing system inside of /+layout.ts. If your data depends entirely on the URL pathname, then changing it triggers a reload.

[tedsteen]

This was a bug at my end.. I had an exception in the +layout.ts which would cause all kind of weird things. If I had more time I would give a something reproducable but I'm afraid I dont..
Sorry for the noise.

[j4w8n]

I love session! 😭

But I'm all for change that resolves issues and uses the new capabilities we have.

[dummdidumm]

What are you using it for currently? Would your use case(s) still be possible to solve without session?

[j4w8n]

@dummdidumm yes, Rich addressed them in his post.

[CaptainCodeman]

Is the $page.data.user updatable from the client?

And if so, what will know to update and how?

[hmt]

It took me a serious amount of time to understand that using invalidate() to rerun the load function will not rerender or mount/unmount the page. It just runs the loader to fill the data: PageData prop with its data that may or may not have been modified elsewhere (in my case using an Action). That should somehow be made clear in the docs. The concept of the load function is not self explanatory.

[dummdidumm]

To clarify: you'd like to have a note in the load section that says "if a load function is triggered to rerun, the page will not remount, only the export let data prop if its corresponding Svelte file will be updated"?

[hmt]

That would be it. At least it would have helped me to better understand its function. I know you guys are working hard on naming everything right. The naming of the files with + and separation of server and page is great. The connection between load and data is also clear but the implications of the data flow is sometimes a little bit too much magic so a red alert box with this piece of information spelled out is a nice to have.

[CaptainCodeman]

Now I'm back at square one with Firebase in Sveltekit....what am I supposed to do now? Remake the session store and redo all the functionality that was just deleted?

It depends, unless you need SSR there may be no need to have any session at all (just keep the auth on the client, and use it to interact with firebase).

If you do need it, you'll still be posting to the server to set a cookie, but will now use that cookie to set a prop on locals (e.g. locals.user) and can then output that as part of a root layout data which can be used to populate your own session store on the client (and / or use invalidate to trigger and update).

[CaptainCodeman]

Why would I not need SSR?

Some potential reasons:

• If data is user-specific
• If you don't have need for SEO
• If you load your data from the client (e.g. firestore client lib)

[weepy]

Is this still happening ? Wasn't sure of the meaning of

in #5778

[Rich-Harris]

we just decided to do it in a separate PR

[martinbeentjes]

How could I reach the data from a +server.ts endpoint?

[Rich-Harris]

event.locals

[martinbeentjes]

Clear, thanks! I have the feeling I am in favor of removing the session object. If we've already have those beautiful two ways to get the data.

[zlepper]

I just tried doing this on a project, and it does work quite fine for the SSR, but the moment the client goes to another page and the client side navigation has to trigger a load, the call to parent just returns an empty object, rather than the object I created on the server originally. This is using version 1.0.0-next.411 of sveltekit.

// +layout.server.ts
import type { LayoutServerLoad } from '../../.svelte-kit/types/src/routes/$types';
import type { Session } from '$lib/models/session';

export const load: LayoutServerLoad = ({ locals }): { session: Session } => {
	console.log('load server'); // Only logged on server (as expected)
	return {
		session: {
			authToken: locals.authToken,
		},
	};
};

// +page.ts
export const load: PageLoad = async ({ parent, fetch, params }): Promise<{ some: Thing }> => {
	console.log({ p: await parent() });
       // On server: { p: { session: { authToken: 'some_token' } } } 
       // On client on navigation: { p: { } } 
}

Otherwise I'm a big fan of the idea. I have been cursing that session object for quite a while.

[Rich-Harris]

I suspect you're running into #5904, which will be fixed by #5916

[zlepper]

That looks exactly like the issue I have. Thank you!

[hubert-ix]

Has this been fixed in the latest version of SvelteKit? I'm experiencing the same issue where I set a user object in +layout.server.js. Then I redirect somewhere but user is not picked up by any +layout.js until I refresh the browser.

[kevinrenskers]

I had the same, but adding an invalidateAll call before the redirect solved the problem.

[weepy]

So I'm having a similar issue with 1.0.0-next.415.

// layout.server.js
export async function load({url, request}) {
    const session = await db.getSession(request.headers.cookies)
    console.log("session", session) // << does get here
    return session
}

// layout.js
<script>
export let data
</script>

<slot />

{JSON.stringify(data) }

// logout/page.server.js

import cookie from 'cookie'
import { redirect } from '@sveltejs/kit'

export async function load({ request, setHeaders }) {
    
    const str =  cookie.serialize("sid", "", {
        path:"/",
        expires: new Date(0)
    })

    setHeaders({'set-cookie': str})
    throw redirect(302, "/")
}

when i navigate to logout I see something in the terminal like the following which indicates
that the layout.server.js is being called correctly

session { user_id: '2GebH2MmsQLszZFX4pUlK', username: 'jonah', role: '' }
session {}

However the data in the layout doesn't update until I manually refresh the page.

[weepy]

OK - so this was because I had an error in my hooks.js file - which was silently swallowed. Working now.

[coryvirok]

This change makes me super happy. Mostly because it makes the DB part of this #4822 no longer a pain.

[JLAcostaEC]

Not in my case, i need to rethink all app structure because i was in love with session, but I won't stop, I know I'll find a way to make everything better thanks to all these changes :D

[silvestrevivo]

Look at the solution from #5883 (reply in thread) I made some adjustments on another projects and the change is minimal.

[ponderingexistence]

I'm rethinking my entire existence looking at all the changes in SvelteKit over the last couple of weeks.
You guys seem to be very keen on removing every bit of convenience that made this framework special. Routing a couple days ago, now this, what next? The direction this is all going is very worrying...

From now on, you need to do $page.data.session instead of $session, because, hey, LeT's DeLeTe StUfF! Most importantly you can no longer update the session on the client-side, you will have to reload absolutely everything just to update the session, how efficient and smart of a design is that! And @Rich-Harris talks about this like it's a good thing, my goodness...

I have the utmost respect and admiration for everyone involved in the development of this framework, I really do, but it has to be said, this is all very disappointing and backwards.
The recent design decisions have been against the very core of Svelte's philosophy, so un-Svelte-like, if you will, and it's the overconfidence here that's truly astonishing.

[mihaon]

After SSR, hydration does a lot of unnecessary things. I'll try to give an example later (after updating my project to a new SvelteKit version and resolving the situation with the $session).

[mihaon]

I didn't like this change, but I have to accept this is the right direction to solve the $session store. I found very confusing the overwrite of the $session in the client side, being the store mounted in the server.

The $session store is mounted on the server for SSR and updated on the client in real time. Just an isomorphic application. I don't understand what's wrong with that.

[CaptainCodeman]

Just curious, what does expensive and inexpensive hydration look like? I don't understand the subject that well.

It's easy to end up sending a lot of data twice - once in the HTML and again embedded as data. If that content isn't going to change or re-render at all it's a waste.

Unfortunately, the control you have over it is a rather blunt tool and you can only turn it all on or off and turning it off means you can't have any interactivity in Svelte JS, so you have to resort to using something like Web Components or Alpine to enable menu buttons etc...

[eltigerchino]

What's the solution to make hydration cheaper? Is it difficult to achieve partial hydration? (something I've been seeing a lot from astro.js and deno's fresh framework).

[mihaon]

expensive hydration make me think about choosing another framework. It is very sad :(

Just curious, what does expensive and inexpensive hydration look like? I don't understand the subject that well.

The promised example: #6874

[danawoodman]

Could we have this moved to "announcement"? Might make it easier for people to see these changes more visibly

[Rich-Harris]

done

[danawoodman]

Thanks! 🙇‍♂️

[JacobZwang]

Under "Why don't we need it any more?", the example uses GET.

// src/routes/+layout.server.js

/** @type {import('./$types').Get} */
export async function GET({ request, setHeaders }) {

Shouldn't it use load?

/** @type {import('./$types').LayoutServerLoad} */
export async function load({ request, setHeaders }) {

I used this code as reference when refactoring my codebase and couldn't figure out why it wasn't working until I looked at the docs and tried changing it to load.

[Rich-Harris]

You had to spot the comment directly beneath it:

Note that #5875 proposes changing GET to load

At the time we wrote this up, we hadn't done that yet, but now we have. I've updated the sample — thanks for calling it out

[david-plugge]

I dont think removing session is that bad. However, i dislike the loss of type safety for global state.

[Rich-Harris]

We plan to address this with a new App.PageData interface. Long meandering thread here: #5951

The tl;dr is that you'll be able to do this...

// src/app.d.ts
declare namespace App {
  PageData {
    // user is always available as $page.data.user
    user: {
      firstname: string;
      lastname: string;
    };

    // every page must have a <title>
    title: string;

    // if a `load` function returns a `showNav` property, it must be a boolean,
    // but it's okay if it isn't returned because it's marked as optional
    showNav?: boolean
  }
}

This gives us much more comprehensive type safety — for user it's equivalent to App.Session, which was enforced as a return value from getSession, but for everything else it's more powerful than the old App.Stuff because we're able to enforce that every page in your app returns a title (if not from the page load function then from a parent layout load function), whereas App.Stuff could only say 'if you return this value it should look like this'.

[stukennedy]

It also causes unnecessary work. On https://svelte.dev, we have to read session data from Supabase for every single request, even though the only place we actually need session data is https://svelte.dev/repl and https://svelte.dev/apps. (I only just realised this, but since we're prerendering most of the site, this means we're affected by the unpopulated session bug described in the last paragraph. That's how insidious the bug is!)

Getting rid of all this stuff would be a huge win.

@Rich-Harris Have you migrated svelte.dev yet? I'm using supabase with their auth-helpers and now don't know how to use it with the latest sveltekit as it expects session in the Helper, which I've put in my root layout:

<SupaAuthHelper supabaseClient={supabase} {session}>
  <slot />
</SupaAuthHelper>

Any ideas how to get this working without rewriting the supabase auth helpers?

[Rich-Harris]

The auth helper will need to be updated eventually, but for now you could create a writable session store populated with $page.data:

const session = writable();
$: $session = $page.data.session;

[stukennedy]

ok cool ... will try and get it working.
I am in favour of the session removal and think the strength of this framework is about making SSR more natural, so this is great.
(loving that most of my app is just basic HTML forms and some simple API stuff now)

However, not a fan of the forced routes file renaming. Why couldn't they stay as they were?
Now every file I'm editing has the same name, which is a nightmare in the IDE tabs

[dummdidumm]

We did this change for a number of reasons:

• One way to do the same except for multiple (about/index.svelte and about.svelte vs only about/+page.svelte)
• Opens up possibilities for type checking
• Easier to see at a glance what this route is doing vs previously where it wasn't clear if this is an endpoint or page
• No longer create routes by accident because you forgot the _ in front of your private Svelte file

Your file names would be the same name anyway as soon as you go the about/index.svelte route, only that they are called +page instead of index now.
In the screenshot the foldername is visible to the right, so I would still quickly know where I am.

[stukennedy]

fair enough ... I suppose a big change like this just takes some getting used to.
It all seems to be very well considered even if it's radical.

[faustodc]

However, not a fan of the forced routes file renaming. Why couldn't they stay as they were? Now every file I'm editing has the same name, which is a nightmare in the IDE tabs

WebStorm puts the folder name first before the file name, which is appreciated for the current situation

[steffenstolze]

Hey guys,
in our case we have a main layout, now called +layout.svelte and a named layout for auth routes called +layout-auth.svelte

In our hooks.js we extracted the browser language from the request headers in getSession:

//add the language the user's browser accepts as main language
/** @type {import('@sveltejs/kit').GetSession} */
export function getSession(event) {
	const languageHeaderParsed = parseHeader(event?.request?.headers?.get('accept-language'));

	let acceptedLanguage = languageHeaderParsed && languageHeaderParsed[0] ? languageHeaderParsed[0].code : 'de';

	if (!supportedLanguages[acceptedLanguage]) {
		acceptedLanguage = 'de';
	}

	return {
		'user-language': acceptedLanguage
	};
}

We now could access the language using $session['user-language'] in every component to set the correct language in SSR.

If I understand you correctly I now have to put the logic I've put into getSession into both of my layout files and access the user-language via $page.data.user-language on the server side (SSR)?

Thank you!

[david-plugge]

you can create a main layout that handles all the global stuff.

src/routes/+layout-main.server.ts

import type { LayoutServerLoad } from './$types';

export const load: LayoutServerLoad.main = async () => {
	return {
		globalData: 'works'
	};
};

src/routes/+layout-main.svelte

<script lang="ts">
	import type { LayoutServerData } from './$types';
	export let data: LayoutServerData.main;

	console.log('layout main data', data);
</script>

<slot />

You can access the data using $page.data.globalData whenever you use that layout.

Edit:
@dummdidumm The types seem to be messed up when using named layouts and generated types.
.svelte-kit/types/src/routes/$types.d.ts

...
export namespace LayoutServerLoad {
	export type main<OutputData extends Record<string, any> | void = Record<string, any> | void> = undefined;
}

I dont think LayoutServerLoad.main should be typed as undefined. Correct me if i´m missing something.

[tedsteen]

This will cause all pages to force a server load for every navigation. I can't figure out where I would put logic that resolves geo/language from ip/request-header (accept-language) and then re-use it in the app

[AdaptingAFM]

@dummdidumm The generated types by Svelte on this example aren't correct. You'd expect any page that taps onto the default layout's server load function to have typed in its returning value, and it completely lacks any information about that signature. It seems to be due to named layouts.

src/routes

+layout.server.ts

generated types after forcing sync

import type * as Kit from '@sveltejs/kit';

interface RouteParams extends Partial<Record<string, string>> {}
interface LayoutParams extends RouteParams {}

export type Errors = undefined;
export type PageData = Omit<LayoutData.front, keyof Kit.AwaitedProperties<Awaited<ReturnType<typeof import('./proxy+page.js').load>>>> & Kit.AwaitedProperties<Awaited<ReturnType<typeof import('./proxy+page.js').load>>>;
export type PageLoad<OutputData extends Record<string, any> | void = Record<string, any> | void> = Kit.Load<RouteParams, null, LayoutData.front, OutputData>;
export type PageLoadEvent = Parameters<PageLoad>[0];
export type PageServerData = null;
export type LayoutData = Omit<Record<never, never>, keyof Kit.AwaitedProperties<Awaited<ReturnType<typeof import('./proxy+layout.server.js').load>>>> & Kit.AwaitedProperties<Awaited<ReturnType<typeof import('./proxy+layout.server.js').load>>>;
export type LayoutServerData = Kit.AwaitedProperties<Awaited<ReturnType<typeof import('./proxy+layout.server.js').load>>>;
export type LayoutServerLoad<OutputData extends Record<string, any> | void = Record<string, any> | void> = Kit.ServerLoad<LayoutParams, Record<never, never>, OutputData>;
export type LayoutServerLoadEvent = Parameters<LayoutServerLoad>[0];

export namespace LayoutData {
	export type front = Record<never, never>;
}

export namespace LayoutLoad {
	
}

export namespace LayoutLoadEvent {
	
}

export namespace LayoutServerData {
	export type front = null;
}

export namespace LayoutServerLoad {
	
}

export namespace LayoutServerLoadEvent {
	
}

page endpoint parent fn return value referring to a type that lacks of type information of the base layout

[kevinrenskers]

I'm trying to refactor my app to the latest SvelteKit version. Updated to 414 first, took a few hours but everything works and the code got better I think (absolutely love the new data prop vs the old stuff). But now I have to deal with the session change and I can't get it to work.

hooks.js

import cookie from "cookie";

export async function handle({ event, resolve }) {
  const cookies = cookie.parse(event.request.headers.get("cookie") || "");
  event.locals.token = cookies.token;
  return await resolve(event);
}

+layout.server.js

export async function load({ locals }) {
  return {
    ...locals
  };
}

+layout.js

export async function load({ fetch, parent }) {
  const data = await parent();
  console.log(data);
}

I get an empty object here, even though the token is definitely returned from +layout.server.js

[ftognetto]

hi @kevinrenskers I'm also trying to rewrite a large codebase that is using session massively.
I found that I have used a solution very similar to your implementation, but yours is cleaner anyway.

layout.server.ts

export const load: LayoutServerLoad = async ({ locals, url }) => {
	debugger;
	const { sessionToken } = locals;
	if (sessionToken) {
		return {
			sessionToken
		};
	} else {
		throw redirect(302, '/login?redirect_url=' + encodeURIComponent(url.toString()));
	}
};

layout.ts

export const load: LayoutLoad = async ({ data, fetch, url }) => {
	debugger;
	const { sessionToken } = data;
	if (!sessionToken && !url.pathname.startsWith('/login')) {
		throw redirect(302, '/login?redirect_url=' + encodeURIComponent(url.toString()));
	} else {
		const api = new ApiHelper(fetch);
		// retrieving data from api...
		const user = await api.get('/users/me');

		return {
			sessionToken,
			user,
		};
		
	}
};

But I found that load in layout.server.ts and load in layout.ts are always called for every page in my app, making a network call (/users/me) that can be avoided if already fetched.

I know that in #6056 are working to reduce layout.server.ts runnings but in my (and yours) case I'm making a network call in layout.ts that should be avoided if already called.

I thought to put the layout.ts logic into layout.server.ts and then pass down data but than I saw your implementation and I asked myself if you found a solution or maybe I am missing something.

Thank you :)

[kevinrenskers]

The code in that post isn't the full code. The real +layout.js looks like this:

import { browser } from "$app/env";
import { get, readable } from "svelte/store";
import { user as userStore } from "$lib/store";
import { getApi } from "$lib/api";

export async function load({ fetch, data }) {
  // If we don't have a token then bail out immediatately
  if (!data.token) {
    return { fetchedUser: readable(false) };
  }

  // If we already have a stored user, then don't fetch it again
  if (browser && get(userStore)) {
    return {
      ...data,
      fetchedUser: userStore,
    };
  }

  // Fetch the user, store it, return it
  const fetchedUser = await getApi(fetch, "/auth/me", data.token);

  if (browser) {
    userStore.set(fetchedUser);
  }

  return {
    ...data,
    fetchedUser: browser ? userStore : readable(fetchedUser),
  };
}

So this prevents fetching the user on each and every page load. I do the same kind of "cache in a store if in the browser" logic in every +layout.js and +page.js file basically, using a technique I wrote about here.

For example on /routes/campaigns/id]/characters/+layout.js:

import { characters as charactersStore } from "$lib/store";
import { fetchContent } from "$lib/fetch";

export async function load({ params, fetch, parent }) {
  const data = await parent();
  const store = await fetchContent(fetch, charactersStore, params.campaignId, "characters", data.token);

  return {
    ...data,
    fetchedCharacters: store,
  };
}

See the post I linked to above (this one) for that fetchContent function. So yeah that is how I prevent duplicate requests to the external API. It's a bit of a bummer that this kind of boilerplate is necessary but it still so much better than the other web frameworks.

I've now added a note to the session refactor blog post to warn people that my simplified example will result in a request on each and every page change, with a link back to this comment with the full example.

[ftognetto]

Thank you very much @kevinrenskers, I will therefore create a special store to contain the data of the main load function, so as not to add unnecessary network calls.

What I don't understand is, if we are removing the session from sveltekit because with the new tools we have available there is no longer a need, but we still have to create a store to keep those data in memory then in reality we are not taking advantage of these new ones tools, because instead of passing the data down in the load function to make it available to the others, we could simply access that store from the other load functions.

Perhaps #6056 also relates to the + layout.ts functions instead of just the + layout.server.ts functions.

I'm sure there is something that I don't understand but that in doing so we arrive at a cleaner architecture :)

[kevinrenskers]

The store only works in "browser" mode, not in SSR. So that's why passing down the data is better then just accessing the store directly from every page. But I feel like we're getting very much off topic and this could be moved to its own discussion, for the sake of everyone subscribed to this one 😅

[ftognetto]

Yes in fact, as I said, I'm new to svelte and maybe I'm missing out on something fundamental. Thanks again and congratulations for the article :)

[stukennedy]

for those who have been struggling to get SvelteKit and Supbase Auth to play nicely. I've been battling away and got it working as nicely as I can figure. I'm still unsure why we need to set the cookies, as I expected the Supabase auth redirection to do that, but it doesn't seem to happen in Firefox. Anyway; suggestions for improvement in my approach more than welcom.

Sveltekit-Supabase-Magic-Link-Auth-using-SSR

[j4w8n]

@stukennedy I love this! I'm sort of doing the same thing, but I like how you pull some of the endpoint fetch out of onAuthStateChange into its own file. And how you're setting supabase auth token in handle() - I was doing it in a server.js file, which means at scale, I'd have to do that in every file. Using handle() is way better.

[juancamiloqhz]

I'll be great if @Rich-Harris can review your post and share some comments.

[ak4zh]

@stukennedy I implemented this on my project, and everything seems to work fine.
Do you have any issue with the redirect in src/login/+page.svelte

SvelteKit: onUserUpdate redirect don't work

[ZetiMente]

@stukennedy This was a great help! Thank you!!!

[ZetiMente]

@stukennedy Did you use LayoutData + invalidate() for changing the UI on the front end between when the user is logged in and when it's not?

[migbash]

What would be the alternative solution then to the removal of $session in the use case of having components A.svelte and B.svelte to communicate between each other when $session.hide = true changes ?

• Is there any $session alternative ?
• Is $page.data writiable and reactive ?

This is massive update, as the simple use of $session.<variable> is super convenient in such inter-component communications that made sapper & sveltekit standout that worked perfectly and reduced development time. $session is like the Jocker Card within sveltekit that once you found out about made development so much exciting and simpler.

Not sure it's the best decision.

Seem like all the recent changes have taken away from Sveltekit what made it unique and easy to use.

[0gust1]

what (and where) would change the value of $session.hide in your app ?

If it's an user action and if it concerns only this user (and not coming from server-side state like DB or auth), a classic svelte writeable store imported in A and B will do the job. inter-components communication via stores is a thing enabled by Svelte, not Sveltekit.

Is $page.data writiable and reactive ?

only readable. Its job is to bring together contextual data to the current page (data coming from parent layout(s), errors, ). As all stores, it's reactive by default.

[CaptainCodeman]

Assuming $session.hide was something that came from the server originally (otherwise you could just use a local store), this is what I do:

I have a currency default that is set on the server (based on locale / location HTTP headers, or cookie override) and served via /+layout.server.ts:

import type { LayoutServerLoad } from './$types'

export const load: LayoutServerLoad = async ({ locals }) => {
  const { site, currency } = locals
  return { site, currency }
}

On the client I have a store:

import { writable } from 'svelte/store'

export const currency = writable<string>()

That is imported into the root /+layout.svelte and set from the LayoutData which loads from the server (via hooks / locals):

import { currency } from '$lib/stores'
import type { LayoutData } from './$types'

export let data: LayoutData

$: currency.set(data.currency)

(it probably doesn't need to be reactive)

Now any component can import and use that store, but when setting it I PUT to the server to set the override cookie so the state is in-sync and it's persisted for the next request.

What the local store does is saves you having to invalidate() the data which would trigger a re-load. I want to avoid also re-loading other site-specific but static data.

A proper custom store can ensure the write-back to the server is in one place and consistently called whenever the value is set.

[silvestrevivo]

From my point of view, this is the most controversial part in all this API update. But after implementing on some projects and seeing the solution from @j4w8n here #5883 (reply in thread) I have to admit that this is a much cleaner way to solve the $session store, splitting up server and client side clearly and not mixing in one store what could happen on both sides.

Yes, I a bit more boilerplate ( just a bit...), but at least in my experience working with new devs, the moment I explained how $session store works is confusing, specially when you could overwrite it in the client side ( that's pretty ugly/awful/confusing.... ).

Congrats @Rich-Harris for this update ( I hope the last big one ) and I think in the long term we will see the benefit of all theses changes.

[j4w8n]

I've now refactored my code to not use a custom store with a context, but rather the built-in $page store and invalidate(). Might still be some use-cases for a store, but for my demo app it wasn't needed.

Still a work in progress...
https://github.com/j4w8n/sveltekit-supabase-oauth

[alexreid]

One problem I'm going to run into with this change is that I was previously using the ability to update the session client-side as a way to provide limited personalisation on pre-rendered pages (after the initial load, obviously) – think about the common case where you have some sort of navigation bar that has different states depending on whether the user is logged in or not. Previously, I'd created an endpoint that just returned the contents of the server generated session, so I could just fetch that in my root layout's onMount and update the session store with the results.

Non-prerendered pages could use session directly, while prerendered pages could still use session data asynchronously within components via the session store. I can definitely recreate a session store myself, but it does feel like SvelteKit is a bit less straightforward in this use case as a result.

[j4w8n]

I still don't have the pre-rendered lingo down, but I had created my own session store to solve the sveltekit session store being gone; then switched to using the sveltekit $page store and invalidate(). Not sure if it'll help your use-case.

https://github.com/j4w8n/sveltekit-supabase-oauth

[alexreid]

Interesting, thanks – the page store may make things simpler! I'll see how it goes!

[alexreid]

Just an update here for anybody who was previously using the session store to personalise pre-rendered pages – the approach using invalidate() doesn't work for pre-rendered pages, since the _data endpoint SvelteKit uses behind the scenes to re-run load asynchronously client-side will always return the page data collected during pre-rendering (that is, at build time) rather than running afresh. I can see why this may be the correct behaviour, but it's still surprising to me that invalidate() would result in stale data being fetched!

[david-plugge]

In case anyone is interested, this is what i came up with (works great with supabase):

Types can be declared like before
src/app.d.ts

/// <reference types="@sveltejs/kit" />
declare namespace App {
	interface Locals extends UserSession {
		user: import('@supabase/supabase-js').User;
		accessToken?: string;
		error: import('@supabase/supabase-js').ApiError;
	}

	interface Session {
		user: import('@supabase/supabase-js').User;
		accessToken?: string;
	}

	interface PageData {
		session: App.Session;
	}
	// interface Platform {}
}

src/lib/stores.ts

import { getContext, setContext } from 'svelte';
import { writable, type Writable } from 'svelte/store';

// store creation
export const session = getContextStore<App.Session>('__SESSION__');

// helper functions

export function setupContextStore<T>(key: string, data: T) {
	const store = setContext<Writable<T>>(key, writable(data));

	let initial = true;
	function update(data: T) {
		if (initial) {
			initial = false;
			return;
		}
		store.set(data);
	}
	return {
		store,
		update
	};
}

function getContextStore<T>(key: string): Writable<T> {
	const store: Writable<T> = {
		subscribe: (cb) => setup().subscribe(cb),
		set: (cb) => setup().set(cb),
		update: (cb) => setup().update(cb)
	};
	return store;

	function setup() {
		const { set, update, subscribe } = getContext<Writable<T>>(key);
		store.set = set;
		store.update = update;
		store.subscribe = subscribe;
		return store;
	}
}

provide the session data

src/routes/+layout.server.ts

import type { LayoutServerLoad } from './$types';

export const load: LayoutServerLoad = ({ locals }) => {
	return {
		session: {
			user: locals.user,
			accessToken: locals.accessToken
		}
	};
};

use parent data

src/routes/account/+layout.ts

import { redirect } from '@sveltejs/kit';
import type { LayoutLoad } from './$types';

export const load: LayoutLoad = async ({ parent }) => {
	const data = await parent();

	if (!data.session.user) {
		throw redirect(302, '/signin');
	}
};

setup the store

src/routes/+layout.svelte

<script lang="ts">
	import { session, setupContextStore } from '$lib/stores';
	import type { LayoutData } from './$types';

	export let data: LayoutData;

	const { update: updateSession } = setupContextStore<App.Session>('__SESSION__', data.session);

	// update the store whenever the layout data is invalidated
	// ignores the first run
	$: updateSession(data.session);
</script>

use the store

src/routes/+page.svelte (or any other page/component nested in the root layout)

<script lang="ts">
	import { session } from '$lib/stores';
</script>

<!-- print out the users email -->
<p>{$session.user.email}</p>

[CaptainCodeman]

It depends on how / where you load data. I'm often switching to a client-side subscription to Firestore so it's ideal for that. If you do have data coming from load functions that you need to re-run, it might be possible to use depends to trigger it. I haven't had need to try that yet.

[david-plugge]

So you don't use load at all to fetch user specific data? If so you loose all prefetch functionality and ssr right?

I'm curious to see your solution in a working app, can you share some code?

[CaptainCodeman]

No, you can still fetch on the server and SSR, but then switch to the client-side subscription to have the live-updating on the client.

I posted the gist of it on another discussion somewhere, can't remember which one it was right now.

[sainathkm]

@david-plugge Any chance of getting an example repo created for this? I am new to programming and find it bit difficult still to implement this to replace the existing supabase example which i got from their site!

[david-plugge]

@sainathkm i´ll create one in the next few days

[RamiAwar]

Can we update the sveltekit realworld app to reflect this update? I always go back to that as a reference and it would really clarify things for me. This has been the most confusing change to me as a beginner.

Only reason I updated to latest was cause session was misbehaving for some reason, but now I see this :D

[kbsali]

Very good idea! The realworld app indeed lacks an example on how locals work.
Actually it would be great if it had an authentication process/feature.

[chrislentz]

I have successfully converted my app from the old session method to $page.data with invalidate(), with the exception of one specific use case. On my sign in page, I have a redirect() inside my +page.js that redirects already authenticated users to the homepage if the parent session is set.

The issue I am having, is that on successful sign in, I am using invalidate() to have my app reload the session from the newly set cookies. But because my redirect is in the pages load(), it gets rerun and the user is sent back to the homepage, which is not what I want to do when users successfully sign in.

Is there anything inside the LoadEvent that I could use to determine if the load is being executed via navigation or via invalidate? This would allow me to only redirect on navigation, not invalidate.

e.g.

export async function load({ parent, invalidated }) {
	const { session } = await parent();

	// Redirect the user if already signed in
	if (!invalidated && session.uuid) {
		throw redirect(302, '/');
	}
}

[eltigerchino]

Perhaps you can tell if it's an invalidate if the request url is the same as the sign in page.

- export async function load({ parent, invalidated }) {
+ export async function load({ parent, url }) {
  const { session } = await parent();
  
-  if (!invalidated && session.uuid) {
+  if (url.pathname === '/signin' && session.uuid) {
    throw redirect(302, '/');
  }
}

[chrislentz]

The url.pathname is just the path to the current page, so it always reports "/sign-in" regardless if it is loading via navigation or invalidate.

[eltigerchino]

The url.pathname is just the path to the current page, so it always reports "/sign-in" regardless if it is loading via navigation or invalidate.

Whoops, I misunderstood. How about this navigating store?

When navigating starts, its value is a Navigation object with from, to, type and (if type === 'popstate') delta properties. When navigating finishes, its value reverts to null.

https://kit.svelte.dev/docs/modules#$app-stores-navigating

[theClarkSell]

I'm a little late to this party; hopefully, someone can help get me straightened out. I'm migrating our big ole app and working through all of this. Like many of you, I've got user deets in session. Taking @Rich-Harris example up top doesn't seem to work $page.data doesn't seem to reflect was +layout.server.js returned. Now I've found this https://kit.svelte.dev/docs/load#input-properties-data, which leads me to if that is now the way, what is the point of $page?

All in all, I've read through this and a few other things multiple times but I'm confused AF. I'd like to make sure I get this right as 1/2 of my site used the old session damn near everywhere.

[geoffrich]

Wrote up a quick demo that might help show things better: StackBlitz

Since we no longer have getSession, instead the root +layout.server.js returns a data object. This will be available to all pages using $page.data

// +layout.server.js
export const load = () => {
  console.log('getting the user...')
  return {
    // this will be available to pages using $page.data
    user: {
      name: 'Geoff'
    }
  }
}

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

<h1>Hello world</h1>

<p>The logged in user data is coming from $page.data, which contains all data returned by load functions for this page (including +layout.server.js)</p>

<p>The logged in user is {$page.data.user.name}</p>

In most cases this should be sufficient to use the data in components/pages. However, if a load function also needs access to that data, you can use await parent() to get the data from parent load functions.

// /another/+page.js
export const load = async ({ parent }) => {
  // if we need to return data based on parent data, 
  // we can do so with await parent()
  const parentData = await parent();
  return {
    capital: parentData.user.name.toUpperCase()
  }
}

<!-- /another/+page.svelte -->
<script>
  export let data;
</script>

<h1>Another page</h1>

<p>Capital user: {data.capital}</p>
<p>The load function in +page.js gets the parent data with await parent() and returns additional data based on it (the capitalized version of the name)</p>

The docs you linked are for when you have multiple load functions (one in +page.js and one in +page.server.js) and should be a more niche use case.

More relevant docs:

• page store
• await parent

[theClarkSell]

@geoffrich thank you for that. Your last point is what's been throwing me. I had both +layout.server.js and +layout.js thus multiple loads functions. and if that's the case then I need to take in data and then return it. I wasn't thinking I had to given page was a store.

thank you. seriously.

[Sirneij]

@Rich-Harris @dummdidumm I have an application written around session in $app/stores. There is no hooks.js and my authentication uses Django's simple-JWT's access token and refresh token for authenticating and authorizing users, not cookies. Currently, access token expires after every 5 minutes and to renew it, one needs to generate it by sending the refresh token to a specialized API for that.

Currently, I store the user's data, including these pair of tokens, in session after a user successfully logs in.

// routes/accounts/sign-in/+page.svelte
...
const handleLogin = async () => {
		const [res, err] = await post(`${BASE_API_URI}/login/`, {
			user: {
				email: email,
				password: password
			}
		});
		if (err.length > 0) {
			errors = err;
		} else {
			const userResponse: UserRequest = res;
			if (userResponse.user) {
				$session.user = userResponse.user;
				$notificationData = {
					message: `Login successful ${happyEmoji}...`,
					backgroundColor: `${greenColor}`
				};

				await goto($redirectUrl || '/');
			}
		}
	};
...

And subsequently, in protected routes, check whether or not a user is authenticated. In my +layout.svelte, I do:

// routes/+layout.svelte
...
const refreshToken = async () => {
		if (!isEmpty($session.user)) {
			const res = await fetch(`${BASE_API_URI}/token/refresh/`, {
				method: 'POST',
				mode: 'cors',
				headers: {
					'Content-Type': 'application/json'
				},
				body: JSON.stringify({
					refresh: $session.user.tokens ? $session.user.tokens.refresh : ''
				})
			});
			const accessRefresh = await res.json();
			$session.user.tokens = accessRefresh;
		}
	};
...
let clear: any;
$: {
	clearInterval(clear);
	clear = setInterval(refreshToken, 499990);
}

To get and update user tokens at intervals. How can I migrate this to the new SvelteKit version since the session store has been removed?

[Sirneij]

@david-plugge Thank you. I should be able to use this custom store in the load function to redirect unauthenticated or unauthorized users from accessing some very private pages. Also, I don't think there is $app/env again, $app/environment is the new one.

[david-plugge]

I should be able to use this custom store in the load function to redirect unauthenticated or unauthorized users from accessing some very private pages.

Yes, but you will always be redirected away from private pages on browser refresh since the load functions will run on the server an there is no valid session. You can disable ssr for private pages to make sure that does not happen.

[Sirneij]

Thank you @david-plugge and @s3812497

[xmlking]

for load we have parent but for actions we don't have parent
is this expected ?

[dummdidumm]

yes, parent only exists in the context of load functions