Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Type error when using middleware #70

Closed
danielsundq opened this issue Jul 7, 2023 · 5 comments
Closed

Type error when using middleware #70

danielsundq opened this issue Jul 7, 2023 · 5 comments

Comments

@danielsundq
Copy link

danielsundq commented Jul 7, 2023

There is a type error when using ordinary itty-router middleware together with an OpenAPIRoute class instance:

import { withParams } from 'itty-router';
...
router.get('/devices/:id/alarms', withParams , TodoList);

The error reads:

TS2769: No overload matches this call.   Overload 1 of 3, '(path: string, ...handlers: OpenAPIRouteSchema[]): OpenAPIRouterSchema', gave the following error.     Argument of type '(request: IRequest) => void' is not assignable to parameter of type 'OpenAPIRouteSchema'.   Overload 2 of 3, '(path: string, ...handlers: RouteHandler<IRequest, []>[]): RouterType<Route, any[]>', gave the following error.     Argument of type 'typeof UnitDeviceAlarms' is not assignable to parameter of type 'RouteHandler<IRequest, []>'.       Type 'typeof UnitDeviceAlarms' provides no match for the signature '(request: IRequest): any'.

Note that the route and the middleware works as it should. This is just a type issue.

@tuzzmaniandevil
Copy link

Getting the same error. not fond of having to use //@ts-ignore

@ashishjullia
Copy link

Hi @danielsundq @tuzzmaniandevil
Is it possible to achieve this: #84 with a middleware here?

With a framework like expressjs (out of context of cf workers) which provides you (req, res, next) and makes it easier to follow middleware pattern and extracting say (email key) from body as req.body.email.

Is is possible to achieve the same with this itty-rotuer-openapi? I'm aware that it has (request, env, context, data) but unable to get the data.body.email and next in the similar fashion :/

@G4brym
Copy link
Member

G4brym commented Aug 31, 2023

Hey there, i've just published the new v1.0.0 release that fixes this issue
Upgrade to the latest version, if the issue is still not solved please re open this issue to let us know
Migration guide to 1.0.0 available here

@G4brym G4brym closed this as completed Aug 31, 2023
@kwhitley
Copy link
Contributor

Hi @danielsundq @tuzzmaniandevil Is it possible to achieve this: #84 with a middleware here?

With a framework like expressjs (out of context of cf workers) which provides you (req, res, next) and makes it easier to follow middleware pattern and extracting say (email key) from body as req.body.email.

Is is possible to achieve the same with this itty-rotuer-openapi? I'm aware that it has (request, env, context, data) but unable to get the data.body.email and next in the similar fashion :/

In general, itty follows a different pattern for middleware/handlers. In express, next must be explicitly called to proceed to the next middleware/handler. In itty, this is achieved by simply not returning (from the middleware). Anything that fails to return, or returns undefined, hands the flow back on to the next handler. The equivalent of not firing next (which ends the chain), is returning anything (or throwing an error).

@kwhitley
Copy link
Contributor

const expressMiddleware = (req, res, next) => {
  // do something
  next() // continue to the next handler
}

const ittyMiddleware = (req, ...other) => {
  // do something, but don't return
}

In short, middleware === handler in itty, and either can effectively become middleware by not returning. Likewise, any middleware can intercept the chain (e.g. to return a 401 early) by returning something.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants