`routeId` not tracked as dependency to layout `load`

[geoffrich]

Describe the bug

When you access event.routeId in a layout load function, the load function does not re-run when routeId changes. Since routeId is based on the URL, we should track dependencies to it similar to url and params.

This probably only makes sense in a layout load. On page loads, routeId should stay the same.

Reproduction

StackBlitz

1. Load page. Notice routeId for the current page is displayed
2. Navigate to another page. The routeId does not change until a page reload

In this case you could work around the issue by retrieving it from the $page store, but if you're doing something else with routeId, that would not be re-run.

// +layout.server.js
export const load = ({routeId}) => {
  return {
    routeId
  }
}

Logs

n/a

System Info

System:
    OS: Linux 5.0 undefined
    CPU: (4) x64 Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
    Memory: 0 Bytes / 0 Bytes
    Shell: 1.0 - /bin/jsh
  Binaries:
    Node: 16.14.2 - /usr/local/bin/node
    Yarn: 1.22.10 - /usr/local/bin/yarn
    npm: 7.17.0 - /usr/local/bin/npm
  npmPackages:
    @sveltejs/adapter-auto: next => 1.0.0-next.80 
    @sveltejs/kit: next => 1.0.0-next.499 
    svelte: ^3.46.0 => 3.50.1 
    vite: ^3.1.0 => 3.1.3

Severity

serious, but I can work around it

Additional Information

No response

[Rich-Harris]

Hmm — this one is tricky. We ran into problems with top-level tracked properties before because you can't do things like { ...event, extra_thing } without triggering the getter (unless you make it non-enumerable, in which case it won't appear in the new object).

[Leftium]

I needed layout load() to run when routeId was updated, so my workaround was to pass routeId with url, which does invalidate the layout. (Note you have to actually use data.url in the layout, you can't just return it from load(). I put data.url in a hidden HTML element)

[Rich-Harris]

@dummdidumm pointed out that we could make routeId dependency visible without the getter by doing what we did for clientAddress — turn it into an event.getRouteId() method instead. It's a tiny bit clunky/leaky but it doesn't feel terrible

[dummdidumm]

I looked at the possibility of changing this to getRouteId() and not so sure anymore about my proposal. In contrast to getClientAddress, routeId is used in places outside the load function - for example in $page.routeId -, which would make it feel even weirder (having one being a function and one not). routeId is also used all over the place internally, so not very ergonomic internally (although that's probably a less important argument).

Another idea would be to turn it into route: { id: string }, which would also make it possible to add more things to that later on (although I can't imagine anything useful right now).

[vnphanquang]

I ran into this today, not a blocker for me since I can workaround with url instead, but it would be nice to have routeId trigger load rerun.

I'm all for route: { id: string } purely from a personal user point of view, better than getRouteId indeed.