Prevent a waterfall effect when needing to access locals in a child page?

[kevinrenskers]

I'm seeing a waterfall effect when loading data on a child page, when that child page calls await parent() purely to access an auth token which is stored in locals.

I have a small reproduction example set up here: https://github.com/kevinrenskers/sk-loading-waterfall. Start up the server, navigate to http://127.0.0.1:5173/child and check the logs. You can see something like this:

Starting A 1677925953894
Starting B 1677925954228

This is a waterfall effect: B only starts after A is complete, purely because the child page needs access to the token, stored in locals, via await parent(). If you remove that call in the child page's +page.ts file, you will see that both requests are now made at the same time.

My question is how to prevent this waterfall effect from happening, when I need access to the token, stored in locals, in a child page?

[kevinrenskers]

One way to fix this is to add a +page.server.ts on the child route with this content:

import type { PageServerLoad } from "./$types";

export const load: PageServerLoad = async ({ locals }) => {
  return {
    ...locals,
  };
};

And then in the child route's +page.ts I can change the code like this:

import type { PageLoad } from "./$types";

export const load: PageLoad = async ({ fetch, data }) => {
  const b = async () => {
    console.log("Starting B", Date.now());
    return await fetch(`https://dummyjson.com/products?token=${data.token}`);
  };

  return {
    b: b(),
  };
};

And voila, the waterfall effect is gone.

But that is a lot of boilerplate code, I'd have to copy the same +page.server.ts to every single child route that needs access to locals without relying on await parent(). Hopefully there's a better solution?

[kevinrenskers]

Are there really no better solutions?

[kevinrenskers]

I'm still hoping for some input here 😬 Anyone?

[david-plugge]

Many sk users brought this up already, the solution would be some kind of entry point for shared load functions. Pretty much like the handle callback but just for shared load functions. However it seems like the sk team is not interested in such thing.

Therefore your solution that brings some boilerplate is the best way to get rid of the waterfall currently

[david-plugge]

I worked out a solution for universal load functions: https://gist.github.com/david-plugge/33cd821a4c829059f67ce18468b8dfca.
The same would work for server load functions aswell. Its definately a hack but still better than a waterfall. This should be built into sveltekit.