invalidate/special fetch is confusing and potentially limiting?

[smblee]

I have been using SvelteKit for a bit now and I am still having trouble getting used to invalidate + special fetch.

I come from NextJS and am used to using SWR cache libs like react-query and useSWR as an abstraction layer on top of raw "fetch" layer to interface with API data. I am used to thinking in terms of "domain" objects (that could be fetched from linking various Rest APIs, GraphQL endpoints, from local storage, or mocked API response, etc. whatever the detail, doesnt matter). This greatly simplifies the application logic as it allows me to never think about how something is grabbed under the hood.

It allows me to think about & interact with domain objects in unique cache keys like posts or postById.123 or currentUser. The interactions could be: accessing, refetching (or "invalidating"), polling. And I love that all of this could be done agnostically across SSR/CSR thanks to seemless hydration + simple access API like const { data, loading, error } = usePost({ id: 123 }) and queryClient.invalidate("post.123").

I've felt that SvelteKit is quite limiting/confusing to implement the access pattern like above for the following reasons (granted, some of these are going away with the next major update):

1. Exact recommended usages for session vs stuff vs svelte store isn't really clearly documented.
2. Svelte store/context is impossible/confusing to use if usage in SSR is desired.
3. load function is hybrid rendered (SSR + CSR) - lifecycle is unclear, i.e. when which code gets run.
4. page render lifecycle, and when what gets run is unclear. e.g. hooks => layout => layout override => page => etc. .
5. magical fetch. => don't know how the "dependencies" list actually gets built, and what things exist in dependencies.
6. magical fetch + invalidate is the documented approach to share data from SSR => CSR, but it forces you to only think about fetch + Route URL as the method of getting data (even tho the data could be fetched from other locations like cookie, graphql client, local storage, etc.).
7. invalidate method can handle both API routes that have been fetch-ed using the magical fetch, or the whole page itself?

At the end of the day, I want an easy way to abstract and unify how a "data" is accessed within the application code no matter SSR/CSR context.

I feel that it's been very easy to write brittle code as i have yet to find an idiomatic way to abstract all this.

I know lots of changes are coming (especially regarding storage methods like session/stuff), but I would love to hear everyone's thoughts on this topic in general.

[benmccann]

Thanks for sharing your experience! We'll consider all this, but in the meantime I wanted to just leave you with one note for a small portion of this that has been addressed.

Exact recommended usages for session vs stuff vs svelte store isn't really clearly documented.

session and stuff have both been removed in the latest version 😄

[lukaszpolowczyk]

I'll say this:
I'm only slowly beginning to understand what all this invalidate and depends and fetch is about.
But I don't fully understand yet.
But I can't tell what I don't understand. :D

I don't know if every load executes anyway, but only fetch doesn't execute (uses previous data?).
It seems to me that sometimes fetch may not execute at all, but I am not 100% about that.
I don't know at all if there could be a situation where load executes, but only one fetch in it executes, and the other doesn't?

As I wrote, some things I seem to understand better than I did the first time I read the documentation, but it wasn't at all easy to understand all those links load, invalidate, depends, fetch.
And I still don't understand everything.

[lukaszpolowczyk]

Related - #6211