RFC: Astro.context
#230
RFC: Astro.context
#230
Conversation
|
|
||
| # Drawbacks | ||
|
|
||
| This change, as described, would only be usable via the NodeJS adapter. Further |
There was a problem hiding this comment.
Yeah, I think this is a bit of a problem. I think we would be hesitant to add a property to the Astro global that only worked in one adapter. If we had an idea to make it work for others that would make it more palpable.
In the past we have discussed ideas of middleware within Astro itself. Then presumably an Astro middleware could mutate a context object like you've described in this RFC.
|
As mentioned here: #221 (reply in thread) A generic mechanism where user code can expose a method that takes in adapter-specific details and outputs a "generic" context would be ideal. Something like: export interface RequestContext {
user: IUser;
}
export function beforeRequest(event: RequestEvent): Promise<RequestContext> {
// do auth stuff
const user = await /* ... */;
return {
user {
name: user.name,
id: user.id
}
};
}Though this specific and common case could also be handled by something like svelete's specifically designed session helper: https://kit.svelte.dev/docs/hooks#getsession So the above would turn into export interface MySession {
user: IUser;
}
export function getSession(event: RequestEvent): Promise<MySession> {
// do auth stuff
const user = await /* ... */;
return {
user {
name: user.name,
id: user.id
}
};
} |
|
@RichiCoder1 How would this work in dev? I think the underlying problem with this and related ideas is figuring out what role adapters should play in dev. Once we figure that out then features like this will be a bit easier to build. |
|
This idea came up again in relation to Cloudflare's |
|
I kinda asked the same I think. https://discord.com/channels/830184174198718474/1021517008061345892 |
|
Is it possible to implement something similar to SvelteKit's |
as of Today, middleware is not usable in dev mode, so why make this RFC depend on that ? I also don't see why this would not work with deno. |
|
I'm going to propose that we close this RFC. Middleware is officially on the roadmap now, and it's likely that we'll be addressing this use case through that API. Edit: updated the Stage 2 proposal to link back to this discussion |
Summary
Adds a "context" available in Astro files during SSR that can be provided from the SSR entrypoint. In template files, this is
Astro.context, and in API routes, this is thecontextproperty of the route's parameter. The purpose of this change is to makeit possible for state that is already derived by the server (such as
authentication state) to easily be passed from Express/Koa to an Astro template
via
Astro.context, so that this information does not have to be re-derivedfrom
Astro.request.headers.A minimal example
In the client, in an Astro template file:
In the client, in an API endpoint:
In the server, using NodeJS SSR adapter:
Links