dealing with data shared between pages

[half hamlet]

this kind of seems like a common question among meta frameworks w/ routing built in of, "how do i share data from one page to the next". in this case, the cache doesn't help as this really only dedups for a single round trip more or less

the scenario i'm dealing with, which i would appreciate advice, is follows:

i have a dashboard page where i fetch all of the groups the user belongs to, and i display them as cards. if the user clicks a card, it brings them to /groups/[groupId]. here i render out a heading with the group name (which of course i already fetched on the previous page) and then all the rest of the page, which takes a bit to render due to fetching im waiting on. it is a nice touch if the heading renders while the rest of the page loads via suspense. this seems like a no brainer as i already have the data i wanna show.. i just don't know the best way to get it where i need it

my current hack is, on pointerdown of the cards that trigger nav, i update a global object like so navigation.lastClickedGroupName = group.name, and then i read that on the next page. i originally was using a global signal, but i realized i don't think i really need reactivity, so just went to a regular object

my question is, this feels super hacky. it's starting to feel like a global store is kind of what i ultimately need. is that the solution here since i have significant state needs across pages? basically just want to know what would be a best practice

[coarse cedar]

i'd reach for tanstack query to do this, have a ["groups"] query and a ["group", number] query that you keep in sync manually

[half hamlet]

yea, so basically a proper cache?

(just realizing that sounds a bit aggressive ^, actual question not being sarcastic or anything)

[coarse cedar]

yeah query is only so useful

[half hamlet]

gotcha. is there any point that you'd reach for some sort of global state store? is it just because it's server state, so syncing that with a store would be annoying ?

[coarse cedar]

personally i'd put all async state in ts query and local state in stores

[half hamlet]

it just seems so much more intuitive to pass around the value i've already fetched than fall back to a server cache on page load. perhaps i'm just being stubborn though

like i know it's effectively the same

[coarse cedar]

wdym?

[half hamlet]

like basically: i have this piece of data. i click a button and see something new. i still need that piece of data but can't have it anymore without falling back to a server state cache. feels unintuitive to me

this is kinda inconsequential, it's what most meta frameworks i've seen do/recommend, so i think i'm just being dumb

[coarse cedar]

like going from list -> details view?

[half hamlet]

yea

i guess i only have partial data but still

[coarse cedar]

you could use the list data in your details view if you want, it just gets messy when your list data is only a part of the full details data

and you'd have to do a lookup in the array by index or id

[half hamlet]

well yea i just want to use it as a fallback in my suspense. once the full data comes in i'll use that

get list data, navigate to details view, while details are loading render title of item from list data, details loads and takes over

[coarse cedar]

we did something similar to that with tanstack query and some other things, a basic way you could do it is something like

const list = createQuery(listQuery);
const detail = createQuery(detailQuery);

const index = .. // get this somehow;

const getData = (cb) => cb(list.data[index]) ?? cb(detail.data)

const name = () => getData(v => v?.name)

getData would use the list data or suspend

[half hamlet]

right yea makes sense

[coarse cedar]

you could do something nicer with proxies

[half hamlet]

the way i was thinking was
in my layout where i render a suspense for the child page, grab the data from the list cache (which will be populated)

find the relevant item from the list using the id in the url

render that as the suspense fallback, then just use the actual data when it comes in

more or less the same thing i suppose

[coarse cedar]

yeah that's also an option

personally i prefer the example i gave since it lets you be more fine grained with your suspense boundaries

[half hamlet]

ok ill keep that in mind. i'm still trying to get used to how suspense works and what triggers what and when

[coarse cedar]

my favourite thing i've ever done in that regard is when i put suspense boundaries inside a card component so that no matter how i used it there was skeleton ui

[half hamlet]

so the components' render their own skeleton and fetch their own data?

[coarse cedar]

no the data is fetched by the route, but since props are read lazily the resource read happens in the component underneath its own suspense

[half hamlet]

ah i see

side note piece of feedback: it may sound counterintuitive, or at least was to me when i realized this, but i think the best way to get started with solidstart is with the server off.

i've gotten much more comfortable with solid and the action/query primitives using it this way than when i was working on an ssr'd project. especially, the action/query stuff, makes a lot of sense and is really useful in a spa setting, whereas when i was figuring this out, it was hard to distinguish these things from the server-first stuff like 'server only', etc.

it's also possible i just had already used start a bit by then so i was more comfortable, but i lean towards a lot of the primitives making more sense in a spa setting

[coarse cedar]

i'd say that makes sense, they're router apis afer all, not start apis

[half hamlet]

yea. using it not in ssr sense made the distinction much more clear. having all the docs in one place is nice, but also has this sort of pit fall where everything blends together

for some reason i never felt this way with next or sveltekit