Opt out of `load` invalidation

[Rich-Harris]

Describe the problem

When running a load function, SvelteKit notes what dependencies the function has...

• url.pathname, url.search, etc
• params.x, params.y
• resources loaded with fetch
• await parent()

...and re-runs the function when those things change. It's possible to force an invalidation with invalidate(resource) (where the load function called depends(resource)) or with invalidate() (which invalidates all load functions), but it's not possible to opt out of invalidation, which is occasionally helpful:

• you want to log some values but not 'observe' them
• you want to implement more fine-grained invalidation, a la Page load functions should return props via derived stores #5850

Describe the proposed solution

We could add an untrack function to load:

export function load({ params, untrack }) {
  untrack(() => console.log(`this will not re-run when ${params.foo}` changes...`));
  console.log(`...but it will re-run when ${params.bar} changes`);
}

Code executed synchronously inside the callback would not affect the function's dependencies.

Alternatives considered

The alternative is to require developers to be completely explicit about when load should re-run, or to always re-run every load function (which no-one wants).

Importance

nice to have

Additional Information

No response

[dummdidumm]

Another idea brought up by @Conduitry is to have a separate object which contains the same parameters but in an untracked way. The disadvantage is that the API is somewhat clunky, the advantage is that you are not constrained to "access inside untrack needs to be synchronously".

[stalkerg]

For my case, I must use the lang parameter from the URL query to make a request for the current session (user), and it should be only once.
Just to be clear about post-1.0 tag - this is a hard stopper for me, and I can't use SveltKit on production without such a feature.
Verbose await parent() from #6183 it's annoying, but we can leave with it but the current issue is much more severe.
In my situation, page load delay increased from 300ms to 600ms.

[stalkerg]

I found a way how I can avoid load invalidation with url, it's a hack, but maybe it can help somebody:

let symbolKeyCache;
/** @type {import('./$types').LayoutServerLoad} */
export async function load({ request }) {
  if (!symbolKeyCache) {
    symbolKeyCache = Reflect.ownKeys(request).find(key => key.toString() === 'Symbol(state)');
  }
  const query = request[symbolKeyCache].url.searchParams;
  ...

[Algoinde]

Had a showerthought about a possible solution for this. I think the concept of "automatic invalidation" is inherently confusing - you did not do anything to cause that, it just happens inside the framework. Most of the time you'd rather conserve on requests rather than invalidate everything, therefore you'll want imperative control over what exactly you want to invalidate, and what you want to just simply reference.

My idea is event.track - an object that includes all of the invalidating things like url, params and so on (even maybe moving depends there), and if accessed via it in the style of event.track.url.searchParams, will raise the invalidation flag. This way, you're very explicit about the behavior - and no need to opt out, you instead opt in.

I currently opt out via

const absolutelyNotSearchParams =
    Object.getOwnPropertyDescriptor(Object.getPrototypeOf(event.url), 'searchParams').get.call(event.url)

and it feels very cursed to do this. One thing I like about Svelte is I don't have to wrangle with it, it's permissive. Here I feel it turned out to be the reverse.

If the invalidation is preferred by default and you'd rather not change the entire API after 1.0, you can put the concept on its head and do event.untrack.url.searchParams. Via intellisense, this will neatly provide the context to what is being tracked.

[stalkerg]

@Algoinde it's not a bad idea, but firstly team should get back to this issue.

[dummdidumm]

Making this opt-in feels a little like React's useEffect with an explicit dependency array. I think this would be cumbersome for the majority of users/use cases. For example if I depend on a route parameter on my load function I'd expect it to rerun when that parameter changes.

We already have explicit opt-in through depends/invalidate, opting out would give us the missing piece here.

[Algoinde]

Yeah, I think simply shadowing it behind an event prop would be a good way to gain the control in a non-confusing way (which I feel the proposed untrack function is).

[dummdidumm]

So your proposal is something like event.untracked.url.. instead of untrack(() => event.url..)?

[Algoinde]

Yeah, pretty much. Scatter it around the load code, no need to wrap in anything every time - as long as you go through untracked or notrack or whatever the name should be, it's fine. And it only has properties in which getters are tracked by default.