[fix] route invalidation comparison based on url and route, not on id

[Algoinde]

Reference issue: #8398

This solves layouts always invalidating and rerunning load if they mention event.route, even if the route ID did not change, due to a wrong comparison in the code.

I have no idea how to write tests, but this should be simple enough.

Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

• It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
• This message body should clearly illustrate what problems it solves.
• Ideally, include a test that fails without this PR but passes with it.

Tests

• Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

• If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

🦋 Changeset detected

Latest commit: 98bd50d

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package

Name	Type
@sveltejs/kit	Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

[Algoinde]

Are we sure the id, which serves as an unique identifier for caching from what I see, will always be an URL-type thing?

[dummdidumm]

the id in that instance (as its comment on hover suggests) is url.pathname + url.search - you can backtrack that variable to get_navigation_intent where it's computed as such

[Algoinde]

Yeah, I know it is currently pathname + search - I'm just considering:

• id name is closer to "route id" than to "URL", which it currently represents in essence - I think that's what caused the initial oversight
• we are not sure if down the line that id will change to something else more specific, breaking this comparison once again.

So I opted to shed that id dependency - especially because url is still there being returned for its intended purpose, while id's purpose is something else entirely.

[dummdidumm]

I agree that id is probably a misleading name in this instance because of route.id, but that id cannot change during the cause of a route change (only if another route change is triggered as a result of it, at which point a new id will be computed). I think we can keep it as is.

[Algoinde]

Oh, I meant "change" as in "someone changes what is computed inside get_navigation_intent at some point due to a caching requirement change and overlooks this comparison due to destructuring, commits and it's borken again".

Thanks for merging!

[dummdidumm]

Thank you!