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
-
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/client
RPC 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/client
as 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