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

Can we accept middleware in @hono/zod-openapi's openapi method? #159

Closed
naporin0624 opened this issue Sep 15, 2023 · 5 comments · Fixed by #161
Closed

Can we accept middleware in @hono/zod-openapi's openapi method? #159

naporin0624 opened this issue Sep 15, 2023 · 5 comments · Fixed by #161

Comments

@naporin0624
Copy link
Contributor

Thank you for creating a very usable library.
I am now using @hono/zod-openapi for my project.

It is possible to insert middleware as follows

const app = new OpenAPIHono()
app.use("*", anyMiddleware)
app.openapi(route, c => {
  // something
})

Is it possible to change the interface to accept middleware as handler, like Hono.get or Hono.post? I'd like to create a PR, but I'm wondering if there are any barriers that have prevented me from doing so in the past?

const app = new OpenAPIHono()
app.use("*", anyMiddleware)
app.openapi(route, anyMiddleware, c => {
  // something
})
```
@naporin0624
Copy link
Contributor Author

naporin0624 commented Sep 15, 2023

Because of the presence of hook after handler, ...handler: Handler[], you can't do that.

@yusukebe
Copy link
Member

Hi @naporin0624

Thank you for using it.

I'd like to create a PR, but I'm wondering if there are any barriers that have prevented me from doing so in the past?

Yes. Of course, I'd like to support various patterns, but it's too difficult to keep type infering correct. To make it come true, I think we have to write type definitions like complex this:

https://github.com/honojs/hono/blob/main/src/types.ts#L70

For this middleware, we/I want to the type definition keep simple.

@naporin0624
Copy link
Contributor Author

Yes. Of course, I'd like to support various patterns, but it's too difficult to keep type infering correct. To make it come true, I think we have to write type definitions like complex this:
https://github.com/honojs/hono/blob/main/src/types.ts#L70

Sorry, I'm not sure what to do. It took me a very long time to reply.

I looked at reselect and rxjs.pipe as similar implementations.
It seemed very difficult to match the complexity of the current openapi method type definitions with the complexity of the handlers type definitions.

Is this a recommended way to apply middleware to a specific path while using the openapi method?

app.on([route.method], route.path.replaceAll(/\/{(. +?)} /g, '/:$1'), . .middleware)
app.openapi(route, handler)

I will also try to operate a compose function that combines the middleware and handler into one by applying a HandlerInterface-like type there.

Thank you very much.

@yusukebe
Copy link
Member

@naporin0624

How about adding a method like getRoutingPath() to route?

app.use(route.getRoutingPath(), mw) // if `path` is `/users/{id}`, it will be `app.use('/users/:id', mw)`
app.openapi(route, handler)

@naporin0624
Copy link
Contributor Author

It's a very simple and good idea!
We will create PR under this policy! Thank you very much.

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

Successfully merging a pull request may close this issue.

2 participants