The beauty of $page.data and how to name/structure the top-level props (brainstorming)

[205g0]

Just pressed Shift-K on $page.data and got some beautifully orchestrated type of all the data I send from various endpoints. It's an amazing feature and should get more visibility.

I have already some structure but wondered if there's something better. Something intuitive, that works for all types of data, won't create conflicts, generic and specific at the same time. My initial ideas for the top level:

1. header and body, think that's too close to the actual Response object and creates confusion
2. meta alnd payload already better but still IDK
3. Just payload for the actual payload and everything else into the top-level, maybe too crowded
4. Group them semantically, i.e. content, user, etc., actually nice but then we have a third structure to keep in min (next to the file tree and the types/data entities)
5. Naming exactly as the types even if the page.data types are just Partials of the real types, so this could lead to many top-level props and might also confuse because, you never send the full type/object to the client
6. Use the REST path from where the data comes from, ie. /users/[userId] would turn into usersUserId, no that's ugly, too long and super cumbersome
7. Just don't overthink it and let page.data grow over time haha
8. Edit3: Or what about using the og entity names + some postfix signaling they've some embedded objects (similar to 5)), so it's clear where they come from AND that they are enriched, instead of user, userExtra but yeah, something nicer and terser than "extra"; if they haven't been extended they just have the og entity name.

Looking forward to your ideas!

Edit: After going over my own ideas, I look more and more on option 5. I mean, I can deal with Partials, this shouldn't be any problem. But I might embed some objects into other ones. This is done already on server level, ie. user and other n-to-n tables will be merged to one user object. So this kind of merged type actually doesn't exist before it's sent and might also create confusion. Ok, back to zero

Edit2: In this context, there's also request.event..locals and the q if this should get a dedicated top-lever structure or be derived from one of the above.

Edit 4: I tend now more to option 8 (similar to 5) and locals should be derived from that and not the way around because former will be richer. not sure if this makes sense yet but let's see. Edit 5: What's really good about this option--it's crystal clear which entity embeds and which not. In particular with n-to-n relations where you can have both entities in the page.data and both could embed both you know instantly which embeds which (the one with the postifx). Only gripe sometimes you would want to extend both but in different ways. Then, both would have the postfix and it wouldn't be clear in which way they've been extended. Do they embed each other entirely, just parts, if yes, which parts?

Edit 5: Since EVERY entity is altered in some way. It never has all the og props, then it has very often other entities embeded, maybe it should just carry the same name. Otherwise every entity has this postfix. Isn't it better just to assume that every entity on the client is altered and period. Yes, this might confuse but maybe not. When I'm on the backend I have og entities, when on the frontend not. Shouldn't be so hard to remember. Not sure if this is the way. But adding a long postfix to everything isn't either. So, edit 5 is about keeping all names, ie. user just stays user and everything else go in a ded. top level prop, ie others

Edit 6: Ok, all the options all BS except 7 ("don't overthink it"). Since the Response objects reflects one REST path only, the risk for conflicting keys is rather small. So, the primary requirement is too have something intuitive, easy to remember, that can be applied everywhere and terseness, so as few nodes as possible, just to keep the lines short where the props are accessed. Use the og entity names for entities and non-entities which usually come from +layout.ts are just put to the top-level.