Replies: 1 comment
-
|
Hi @dimik, Thank you for using Hono! I understand that you're looking for a way to simplify your code. However, with your approach, inferring the type for a client becomes very difficult. The type system is complicated, so it's not easy to explain. However, certain features, like export function composeHonoRoutes<H1 extends Hono, H2 extends Hono>(
routes: [H1, H2],
app = new Hono()
): H1 | H2 {
return routes.reduce((acc, route) => {
acc.route('/', route)
return acc
}, app) as never
}
const foo = new Hono().get('/foo', (c) => c.jsonT({ foo: 'foo' }))
const bar = new Hono().get('/bar', (c) => c.jsonT({ bar: 'bar' }))
const app = composeHonoRoutes([foo, bar], new Hono())So, I don't recommend creating |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
Hi @yusukebe , first of all, thank you for such an amazing router. We're using it for our BFF (backend for frontend) application.
I'm trying to migrate our bff-client app to your
hono/clientRPC to reduce types declaration boilerplate and it looks very promising.However i have a small complication with our routes composing helper, that aggregates routes in more declarative way, that now looks like this:
But looks like it's not the proper approach of routes aggregation for
hono/clientas i'm getting "unknown" when trying to do like so:In my understanding I need to change this helper like this to order to make it work, please notice that i return
Hono.route, instead of Hono instanceBut i have a complication to properly type it. Could you please help me with that?
So what i want to archive is instead of this one:
to do like this (please notice that I wish to use Hono.basePath as well)
thank you!
Beta Was this translation helpful? Give feedback.
All reactions