winstxnhdw
commented
2 months ago I am not exactly satisfied with the current implementation. I understand that we want to reduce dependencies, so here's a compromise: Let's write incomplete type stubs for each adapter.
Here's an example.. Although this hono adapter consumes a ctx, we can write a contract for only the properties we need.
const hono: FrameworkAdapter = (ctx) => {
let resolveResponse: (res: Response) => void;
return {
update: ctx.req.json(),
header: ctx.req.header(SECRET_HEADER),
end: () => {
resolveResponse(ctx.body());
},
respond: (json) => {
resolveResponse(ctx.json(json));
},
unauthorized: () => {
ctx.status(401);
ctx.statusText(WRONG_TOKEN_ERROR);
resolveResponse(ctx.body());
},
handlerReturn: new Promise<Response>((resolve) => {
resolveResponse = resolve;
}),
};
};In this case, we only need req, req.json, req.headers, body, json, status and statusText. So we can write an interface like the following:
export interface HonoContext {
req: {
json: () => Promise<Update>;
header: (header: string) => string | undefined;
};
body: () => Response;
status: (status: number) => void;
statusText: (statusText: string) => void;
json: (json: string) => Response;
}Then our webhookCallback can be:
export function webhookCallback<C extends Context = Context>(
bot: Bot<C>,
adapter?: "hono",
webhookOptions?: WebhookOptions,
): (request: HonoContext) => Promise<Response>;This is a good idea because we already use the following properties in our implementation: req, req.json, req.headers, body, json, status and statusText. It is not a bad thing to have them typed. If there are any breaking changes on the adapter side, we would have to fix it on our end regardless of whether they are typed or not.
In the long run, there may be the added benefit of easier maintenance. Do let me know what you think.
KnorpelSenf
codecov[bot]
allcontributors[bot]
Background
Traditionally,
webhookCallbackhas never been strictly typed. It returns a handler that takes in arguments ofany[]and returnsany. This can be confusing to new users, forcing many attempts at different configurations beforewebhookCallbackis able to work correctly.Objective
This PR will overload
webhookCallbackwith typings for all adapters, allowing TypeScript to resolve the appropriate handler parameters and return types. We also add tests to track any incompatibility between our supported web frameworks and the respective adapter implementation.With the newly resolved types introduced with structural typing, our intellisense can now emit an error when an incorrect configuration is entered.