Send data from hooks to page load functions without a server load function

[pilcrowonpaper]

Describe the problem

When implementing auth, it's impossible to run load functions in parallel. This is roughly how auth are implemented right now:

1. Check for the user in hooks, add user data in locals
2. Read locals in +layout.server.ts and add that to page data
3. await parent() in load functions to check for user

It would be great if we can move step 2 to a new function from a load function so it won't block all load functions below it from running.

Describe the proposed solution

I would like to see something similar to getSession() in hooks, that runs between hooks and load functions. This function can populate page data or populate a different new object.

Alternatives considered

none

Importance

would make my life easier

Additional Information

No response

[cdcarson]

It would be great if we can move step 2 to a new function from a load function so it won't block all load functions below it from running.

Totally agree there needs to be a way to clearly separate business logic from data retrieval/caching. The former probably needs to be run every request (as used to be possible with load' and getSession`.) The latter only when a part of the cache is explicitly invalidated in client code.

Related to #6315.

[giuseppe-palmeri]

I only partially agree.
The

2. Read locals in +layout.server.ts and add that to page data

it could also be

2. Read locals in +page.server.ts and add that to page data
3. ...

The fact is that locals only lives on the server side and not the client side.

This I believe is for security reasons, in the sense that it is assumed that the data produced by hooks.server.js should not first of all serve the client side, but only a selected part of it.
hooks.server.js may produce sensitive data that you don't want to be propagated to the client.

The consideration made is more than fair, it is what I would also need.

But at this point we might think we have 2 types of data:

locals -> data that are propagated only in the server side;
shareds (or something similar) -> data that is propagated everywhere and is always available
both on the server side and on the client side through any type of load function.

[Rich-Harris]

@pilcrowonpaper you seemed to have a change of heart in #7107 (comment) (and I think you're right that #7107 was a dupe of this) — does that mean this issue should be closed?

(For anyone following along: #7107 (comment) articulates why passing data from locals to client-side load functions is something we should avoid.)

[pilcrowonpaper]

@Rich-Harris oops, forgot to close this, thanks for reminding me!