`invalidate('...')` doesn't work after navigating to a page with parameters

[aradalvand]

Describe the bug

Repro: https://github.com/aradalvand/sveltekit-invalidate-with-params

It seems like having a route with params (e.g. routes/whatever/[id]) along with a load function that have depends(...) doesn't work as expected, when you navigate to that page with the client-side router, and then run invalidate('...'), it won't work. Very weird. I'm pretty confident this is a bug.

Reproduction

• Clone https://github.com/aradalvand/sveltekit-invalidate-with-params
• Run and open the app (the home page) in the browser
• Open the console, run invalidate('user'). You'll see that the layout's load function gets re-run, as expected:
  
• Now, click on the link in the home page titled "Go to foo"
• After navigating to the /foo/123 page, open the console and run the same command again. This time, it won't work, the layout's load function isn't re-run:
  

Logs

No response

System Info

System:
    OS: Linux 5.15 Ubuntu 20.04.4 LTS (Focal Fossa)
    CPU: (4) x64 Intel(R) Core(TM) i7-7500U CPU @ 2.70GHz
    Memory: 486.11 MB / 3.77 GB
    Container: Yes
    Shell: 5.8 - /usr/bin/zsh
  Binaries:
    Node: 16.15.1 - /usr/bin/node
    npm: 8.11.0 - /usr/bin/npm
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.65
    @sveltejs/kit: next => 1.0.0-next.445
    svelte: ^3.44.0 => 3.49.0
    vite: ^3.0.4 => 3.0.9

Severity

blocking all usage of SvelteKit

Additional Information

The problem only exists for pages that have parameters, I have no idea why, but I think this information could be useful for diagnosing the problem.

[dummdidumm]

This works as expected. The invalidate/depends function expects an URL / constructs one, so in this case depends('user') becomes http://127.0.0.1:5173/user, but invalidate('user') inside foo becomes http://127.0.0.1:5173/foo/user - this doesn't match, so nothing reruns.
I've been bitten by this, too, since I wasn't aware of it, and while the docs hint at it, they don't make it very explicit. So we should at least enhance the docs, or allow arbitrary values for depends and invalidate - but not sure how to do this in a way that also preserves existing behavior. @Rich-Harris FYI marking this as potentially breaking change and to the 1.0 milestone in the sense of "we need to decide on what to do here".

[aradalvand]

So we should at least enhance the docs, or allow arbitrary values for depends and invalidate

I'm surprised to hear that that's already not possible, I thought you could pass in any unique string to depends.

I think you should allow arbitrary values, as you said, it enables a variety of useful scenarios, such as the one in the repro I provided above, namely having depends('user') in +layout.ts and then running invalidate('user') whenever someone logs in or whatever to update the user information. And sometimes you have something like a GraphQL API where there's just a single endpoint (/graphql) and so you can't differentiate between the fetches via the URL so you have to resort to a custom string for depends.

[icalvin102]

All the urls you pass to depends or fetch will be registered as full urls.

Meaning they are passed through https://developer.mozilla.org/en-US/docs/Web/API/URL/URL before being saved.

const { href } = new URL(url, location.href)

Arbitrary values are possible if you make new URL() think that you passed a full url.
The url has to contain a protocol string to be recognized as full url. In other words it has to match this regex /^[a-z]+:.*/

So as long as you prefix your identifier with one or more lowercase letters followed by a colon you should be fine.

Example:

depends(
  'custom:foo',
  'page:HOME_PAGE'
);

invalidate('custom:foo');
invalidate((u) => u.startsWith('page'));

[icalvin102]

In my first proposed solution for custom dependencies in the load function (#1709) there was a lot of discussion with @Rich-Harris on how this could be implemented cleanly.

I wanted to have completely arbitrary identifiers for the invalidation. However the requirements of invalidating completely custom identifiers and urls don't mix well. For urls passed to fetch or depends one would like to resolve the full url from relative paths but custom identifiers should stay unaltered. The implementation and usage of this would be quite ugly because there we would need a way to differentiate between the "url" variant and the "custom" variant either by providing a flag or having separate functions for each variant.

Example:

function depends(identifier: string, isCustom?: boolean){}
function invalidate(identifier: string, isCustom?: boolean){}

This is of cause not very nice.

So I was quite happy when I came up with the solution described in my previous comment because it unifies the requirements of urls and custom identifiers. Of cause this does not give you complete freedom over what identifiers you can choose because of the (protocol like) prefix but it's close enough in my daily work. And being forced to use a prefix for custom identifiers makes it quite trivial to define namespaces/categories for them that are easily invalidated with a predicate.

Long story short: There is no need for another breaking change in this case IMO. The current implementation can deal with urls and custom identifiers quite fine. The only thing that is missing is good documentation on how to use it.