Access values exported by routes (in RequestEvent)
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 20.8k
- Forks
- 2.3k
- Avg merge
- 1d 16h
- Merged PRs (30d)
- 156
Description
Describe the problem
I have got several routes (API routes / endpoints specifically) which all need different types and levels of authentication, and possibly some more route-specific configuration options, which I would need access to e.g. in a server hook. Sometimes, the configuration even needs to be method-specific, e.g. the POST handler needs different authentication than the GET handler.
Currently, it is quite difficult to specify this configuration in a nice, clean and understandable way, even though there already would be a great place for values exported by routes.
Describe the proposed solution
A nice way that came to my mind would be something like this:
// +server.ts
export const config = {
foo: true,
sveltekit: "love"
}
export const GET = (async (event) => {
// ... maybe even be able to access it here (see hook file below) ...
}
// hooks.server.ts
export const handle: Handle = async ({event, resolve}) => {
const routeConfig = event.route.config // <- the part where it fails since something like that is not implemented in SvelteKit
if (routeConfig.sveltekit === "love") {
// ... e.g. handle specific auth ...
}
return await resolve(event)
}
In my opinion, this would be a great implementation, since it makes use of the route field which already exists in the RequestEvent interface. Currently, it only has an id field, but it would be a very clear and understandable place for values that were exported by the route.
Alternatives considered
One alternative would be to export this config in a centralized place and import it elsewhere, something like this:
// src/lib/RouteConfig.ts
export const routeConfig = {
"/api/foo": {
auth: "auth_1",
// ...
},
"/api/bar": {
methodAuth: {
GET: "auth_1",
POST: "auth_2",
},
// ...
},
// ...
}
This has some clear disadvantages though:
- When changing the path of the route, it also needs to be changed here. Forgetting this could also have bad consequences, if the config is used for something like authentication (at least if there aren't any tests covering this).
- The configuration can get large and confusing (it could be split into different files, but that does not solve that it is not a great solution in general).
- The (thinking) context of the route is lost, in the sense that there are values which are exactly specific to a route, but they live in a totally different place somewhere between the configuration of many other routes.
Importance
would make my life easier
Additional Information
I am not sure if there would be any other places where the values exported by routes could become useful, which is why I put the "in RequestEvent" in the title in parentheses.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the RequestEvent interface in packages/kit/src/exports/public.d.ts, then review the +server.ts route exports and hooks.server.ts Handle entry point described in the issue. Determine how route-exported configuration should be represented on event.route, including method-specific values. Done means a route's exported configuration is available to the server hook as proposed.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100