SWR Integration for Hono RPC Client

[AprilNEA]

Summary

Add built-in SWR integration to Hono's RPC client, allowing developers to seamlessly use SWR's useSWR and useSWRMutation hooks through the existing chainable API.

Background

Hono's RPC feature provides an excellent way to create type-safe APIs that can be easily consumed by frontend applications. The current chainable client API (e.g., client.api.users.$get()) works great for direct API calls, but when building React applications, developers often want to integrate with data fetching libraries like SWR for better caching, revalidation, and loading states management.

Currently, developers need to manually wrap Hono client calls with SWR hooks, which leads to:

• Boilerplate code duplication
• Loss of the elegant chainable API experience
• Manual key management for SWR
• Inconsistent patterns across the application

Benefits

1. Seamless Integration: Developers can use SWR features without leaving the familiar Hono client API
2. Type Safety: Full TypeScript support inherited from existing RPC types
3. Automatic Key Management: SWR keys generated automatically from the API path
4. Reduced Boilerplate: No need to manually wrap client calls with SWR hooks
5. Consistent API: Maintains the chainable API pattern that Hono users love
6. Flexible: Still allows access to all SWR options and features

I have a working demo implementation and here is the demo situation:

The demo I currently implemented requires patching the @hono/client, as there is currently a lack of complete chain information for this function.

Check patch: https://github.com/AprilNEA/ChatRepo/blob/master/patches/hono.patch Check implementation: https://github.com/AprilNEA/ChatRepo/blob/master/cr-web/src/lib/hono-swr.ts Usage:

https://github.com/AprilNEA/ChatRepo/blob/8cb474819a23f50f192fa391bf2783444bb0f301/cr-web/src/App.tsx#L149-L151

I would be happy to contribute to this feature if there's interest from the maintainers.

[yusukebe]

@AprilNEA

It's interesting. I also thought of using the client with SWR. We'll need to consider implementing the patch you gave us. However, the library with the useHC export should be placed in honojs/middleware and released as @hono/swr or a well-named package, as it depends on an external library. I'll also review #4270 and consider these points. Thanks.

[speyar]

Hey any update on this? the solution @AprilNEA proposed is so much needed (atleast on my end), cause i either ended up wiring a fetcher for every route, or bring up some (not so clean) "hacky" solution to fix this. Would be really great to have swr integration with the client out of the box

[yusukebe]

Hi!

We've added parseResponse() helper in #4314 and you can use it: https://hono.dev/docs/guides/rpc#parsing-a-response-with-type-safety-helper

Is this what you wanted?

[speyar]

Hi!

We've added parseResponse() helper in #4314 and you can use it: https://hono.dev/docs/guides/rpc#parsing-a-response-with-type-safety-helper

Is this what you wanted?

Yep, this seems to do the trick! export async function honoFetcher<T>(fn: () => Promise<ClientResponse<T, StatusCode>>) { return parseResponse(fn()) as T; } this is the fetcher i made, it's pretty simple and will see how it goes overtime. Any opinion about this fetcher? The only thing i seem to note is that error from SWR is of type any, but it does throw error and SWR catches it, i also did this to test and it seems to work if (error instanceof DetailedError) return <div>Failed to load</div>; Thank you for your response!

[yusukebe]

Hi @speyar

Lacking types of the error object is caused by a TypeScript limitation. So, your way seems to be the best. Thanks!