expose event.routeId and page.routeId

[Rich-Harris]

closes #3840 (and #3907) by exposing the internal route.key as event.routeKey. This is a string based on the filename of the page/endpoint:

filename	event.routeKey
src/routes/index.svelte	""
src/routes/about.svelte	"about"
src/routes/blog/index.js	"blog"
src/routes/blog/index.svelte	"blog"
src/routes/blog/[slug].svelte	"blog/[slug]"
src/routes/blog/archive/[page=integer]/index.svelte	"blog/archive/[page=integer]"
src/routes/[...catchall]	"[...catchall]"

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:/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 pnpx changeset and following the prompts. All changesets should be patch until SvelteKit 1.0

[changeset-bot]

🦋 Changeset detected

Latest commit: d25b687

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

[Conduitry]

Do we want to expose this in $page as well? Or are you thinking that, if someone really wanted this on the client, they could expose it in $session manually?

[Rich-Harris]

We definitely could put it in page (one of the changes in this series of PRs makes all page keys available to the client as a side effect), I was just being as conservative as possible. Do you have a use for it?

[Conduitry]

It was one of my original ideas in #269 before that turned into exposing $page.stuff. When doing navbar-type things, there are still times where routeKey would be less work than manually having to set different stuff values in each route (which is probably only made more so with shadow endpoints, if the only reason you'd need a particular load is to set stuff).

[Rich-Harris]

In that case is page.routeKey the right property, or should it just be event.key and page.key?

[Rich-Harris]

For posterity: we decided on event.routeId and page.routeId

[Rich-Harris]

merging this into #4344 to try and minimise #4354-style git fuckups