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 :)