Introduce a feature for bottom-up page-to-layout communication

[aradalvand]

Describe the problem

Prior to the recent API overhaul (#5748), I used to have a Meta.svelte component that was rendered by my root layout. This component would read from $page.stuff — which I had typed in app.d.ts — and set various page-level head tags such as <title>, <meta name="description"> and so on based on those stuff values. Every page would then have to provide this information in its load function, like so:

export function load() {
  return {
    stuff: {
      meta: {
        title: 'Home page',
        titleSuffix: 'long',
        description: 'Blah blah blah'
      }
    }
  };
}

My app.d.ts file looked something like:

declare namespace App {
  interface Stuff {
    meta: {
      title: string;
      titleSuffix?: 'short' | 'long' | 'none';
      description?: string;
    };
  }
}

And the <Meta> component:

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

  const titleSuffixes = new Map<TitleSuffix, string>([
    ['short', ' | Foo'],
    ['long', ' | Foo Bar Buzz'],
    ['none', '']
  ]);

  $: ({
    title,
    titleSuffix = 'short',
    description,
  } = $page.stuff.meta);
</script>

<svelte:head>
  <title>{title + titleSuffixes.get(titleSuffix)}</title>

  {#if description}
    <meta name="description" content={description} />
  {/if}
</svelte:head>

Now, ever since the API has been re-designed and the stuff thing has been removed, I've been struggling to re-create this properly.
Asking questions on the Discord server and reading this part of the migration guide lead me to think that returning this information as part of the data returned by each load function is apparently the way things like this are meant to be handled now. But I find that this is an almost unacceptable alternative, for two major reasons + a more minor one:

1. No type-safety while providing the values in the load functions:

export const load: PageLoad = () => {
  return {
    meta: {
      title: true, // Nothing's preventing me from doing this
      titleSuffix: 'somenonsense', // or this
      descriptititoitnotintotn: 'Blah blah blah', // or this 
    }
  };
};

2. No type-safety while reading the values in the <Meta> component

Meta.svelte:

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

<svelte:head>
    <!-- Absolutely no type-safety here, `meta` is `any` -->
    <title>{$page.data.meta.title}</title>
</svelte:head>

3. These values will be visible from the +page.svelte file included as part of its data prop, which is weird since it's actually none of its business.

meta isn't really something that this page is concerned with, so this is slightly awkward.

This (particularly the lack of type-safety) clearly yields a drastically poorer developer experience compared to the previous API. I sense that not enough thought has been put into this particular requirement when re-designing the API, namely bottom-up communication between pages and layouts. Page data isn't really fit for this use case at all.

Describe the proposed solution

I don't have a clear-cut proposal here, the general idea is that perhaps you could consider introducing a new construct designed specifically for bottom-up page-to-layout communication, in order to properly accommodate use cases like this, which are by no means uncommon or unusual, or niche. It actually gets more complex in a real-world app where there are typically multiple levels of layouts, and each of them receives a different set of configurations/settings; which is why I believe this is something that deserves a dedicated feature, so to speak.

Importance

crucial

Additional Information

Please don't just hand wave this away, thanks. I know it's annoying that literally dozens of issues get created on this repo every single day and naturally it's almost impossible to give each and every single one of them a lot of attention, but this one is a real problem, I think, and one that is in need of a response from your side.

And tell me if I'm missing something, because I certainly raised an eyebrow while trying to do this but failing to find a satisfying solution, so it's possible that I'm unaware of something here.

[rmunn]

The discussion at #5748 (comment) suggested using stores for this purpose. The top-level layout puts a store, let's say it's called meta, into data. Then it subscribes to that store to make any changes (to title, etc.) that are needed. The page then does something like this (note: code NOT tested, just written into the comment box, so it could well be wrong in significant details):

const { meta } = data;
$meta.title = 'New title for this page';

That should fire the subscription in the top-level layout, which would then update the title with the new value.

[dummdidumm]

I don't think we will reintroduce something else, the "this pops up in my data" is negligible to me - you don't have to use it in your component. The type story is worse for now, but we will implement some level of type safety again for this.

[aradalvand]

@rmunn That's an interesting idea, but I tried it and it doesn't work during SSR which is a total deal breaker, as you would obviously need meta information like <title> to be set during SSR.

That should fire the subscription in the top-level layout, which would then update the title with the new value.

Unfortuantely that's precisely what doesn't happen (during SSR), for some reason.

[aradalvand]

I don't think we will reintroduce something else, the "this pops up in my data" is negligible to me - you don't have to use it in your component. The type story is worse for now, but we will implement some level of type safety again for this.

@dummdidumm As I said, that one is the most minor issue, but I thought it's worth mentioning as it could be indicative of a larger conceptual problem. The type-safety is non-existent, and I'm not sure exactly why you're opposed to introducing a new distinct construct for this, but even if you don't want to do that, at the very least I would say just make using stores possible here.

As soon as I read @rmunn's comment I thought yeah that's probably the perfect solution for this, but it turns out it doesn't work during SSR and that's a deal breaker, I would appreciate it if you explain why.

To be more specific, when I set a store value inside a page's <script> tag, the changes to the store aren't reflected in the layout in SSR, I hope that makes sense.

[Rich-Harris]

The type safety you had before was illusory — nothing was forcing your page load functions to return the properties you needed on stuff. You had type safety insofar as it would prevent you from returning the wrong properties, but it didn't guarantee the right properties. Runtime checking was always necessary.

Stores won't work for this in SSR because you're not setting the value until the leaf is rendered, by which point the layout... has already been rendered. $page.data works because the data for the page is resolved before rendering happens.

[aradalvand]

@Rich-Harris So then what approach would you take for implementing things like this currently? And it's not just meta information, you might have a hideFooter "layout setting" that needs to be set by the pages, and things of that nature in general?

This gets worse if you need, for example, default values for these settings. All of this renders $page.data unsuitable for this use case, in my opinion, which is the point I'm trying to make.

[abdo643-HULK]

@Rich-Harris So then what approach would you take for implementing things like this currently? And it's not just meta information, you may have a hideFooter "layout setting" that needs to be set by the pages, and things of that nature in general?

This gets worse if you need, for example, default values for these settings, all of this renders $page.data unsuitable for this use case; that's the point I'm trying to make.

A derived store in the root where you read the props you need from $page.data

[aradalvand]

@abdo643-HULK That still has all the downsides and limitations of $page.data that I've touched upon. Doesn't really solve anything.

[aradalvand]

Something like $page.statics proposed in #1459 (+ #269) is more or less what I'm suggesting. Those were deemed resolved when stuff was allowed to be set in pages and read by the layout, but now we're back to where we were since there's no stuff anymore and the supposed alternative which is $page.data is simply not fitting for such use cases.

I hope this is reconsidered. SvelteKit doesn't currently have a satisfactory answer to this need.

[abdo643-HULK]

Because it is a derived store you can create your own type for ts. And you also said that things like meta aren't concerns of the +page.svelte but I don't agree with that because each page has it's own meta data. Just because the component doesn't consume it because of layouts doesn't make it not part of the page data

[aradalvand]

Because it is a derived store you can create your own type for ts.

@abdo643-HULK You can create your own TS type already, and then just convert $page.data.meta to it like $page.data.meta as YourType, introducing a derived store is not necessary, that's not the point, the point is that any time you find yourself doing an explicit type conversion like this, that's what we call lack of proper typing.

And you also said that things like meta aren't concerns of the +page.svelte but I don't agree with that because each page has it's own meta data. Just because the component doesn't consume it because of layouts doesn't make it not part of the page data

Perhaps that wasn't the best of examples, fair enough, but I also provided others such as hideFooter, etc. The basic idea is simple and shouldn't be controversial: A layout can have various "settings" that are to be set by any page that derives from it, that's not really an exotic or unusual notion, so my point stands.

[aradalvand]

It is also awkward to have to create a separate +page.js file and a load function only to set some layout settings for a page, even though the page might not actually do anything else in its load function, the +page.svelte file feels like a more appropriate place for this kind of thing. I think this all clearly begs for a separate feature.

I must say I find it deeply frustrating to have to argue so elaborately for something that I feel should be obvious to anyone after minimal examination.

[dummdidumm]

You think you "elaborately" argue, I think you are being passive-aggressive. stuff was confusing to a lot of people, and $page.data achieves the same with a uniform solution which satisfied both the layout use case as well as the "don't want to do prop drilling" use case. What I decipher from your posts is that you don't want to mix layout concerns with other data in a single store, which doesn't sound like a concern to me. You are free to introduce a convention to your code that all layout-related data should be within a layout prop or sth like that. Your argument of needing to provide a load function was true for stuff, too, so I don't see a drawback here - and Rich explained why it isn't possible to do this in +page.svelte, because it's too late by then for SSR.

What's left is the TypeScript-story, which I agree needs to get better.

[aradalvand]

Your argument of needing to provide a load function was true for stuff, too, so I don't see a drawback here

Yes but it's obviously exacerbated by virtue of the fact that now you need to have a separate file for the load function and previously you didn't so it wasn't as big of a deal.

What I decipher from your posts is that you don't want to mix layout concerns with other data in a single store, which doesn't sound like a concern to me.
What's left is the TypeScript-story, which I agree needs to get better.

No, it's far deeper than that, even if the typing is improved, this will still not be a perfectly suitable solution for this kind of scenario. For instance, providing default values, as I mentioned above, would be non-obvious and awkward in this approach. And if you have multiple levels of layouts, the merging behavior won't work as expected, since a shallow merge is performed on the object. Consider the following (rather simple) example:

routes/+layout.svelte:

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

<Header type={$page.data.layout.headerType} />

<!-- As a side note, this is more or less how you would have to provide default values, and it's not ideal since the default values are scattered around the entire file and you would potentially have to repeat them in multiple places or otherwise resort to more awkward workarounds -->
{#if $page.data.layout.showFooter ?? true}
  <Footer />
{/if}

routes/whatever/+layout.js:

export function load(){ 
  return {
    layout: {
      headerType: 'secondary'
    }
  };
}

routes/whatever/deeper/+page.js:

export function load(){ 
  return {
    layout: {
      showFooter: false,
    }
  };
}

The resulting $page.data here would not include the values that routes/whatever/+layout.js set; because routes/whatever/deeper/+page.js essentially overrode the entire top-level property (layout) even though it only meant to modify a single property within it. Yes I know I can work around this like so:

routes/whatever/deeper/+page.js:

export async function load({ parent }){ 
  const { layout } = await parent();
  return {
    layout: {
      ...layout
      showFooter: false,
    }
  };
}

But now these two load functions are run serially as opposed to concurrently and that would have a performance cost if they're sending fetch requests and whatnot. I don't really need them to run serially, this is just what I have to do in this particular case because there's no other way to achieve what is needed.

The same problem more or less existed for stuff too, it's not like I'm a huge fan of stuff, I'm just saying that this is the type of thing that I think would greatly benefit from a native feature that's specifically designed around it, because trying to do it using already-existing features (page data in this case) clearly yields a lot of awkwardness and requires hacky and non-obvious workarounds. It's not really fitting, that's the best word I can think of to describe it. Correct me if I'm wrong.