Trying to find a generic solution to wrap react-query easily

[Meess]

Currently the documentation shows different methods to use @tanstack/react-query (on the Hono Stack page) and SWR on the RPC page.

However both felt a bit clunky to me. My preference would be to have a hook in which you add the endpoint, and the data needed and done (expect if you want to add extra options). Somethings like:

const results = useEndpoint(
    client.api.echo[':echo'].$get, // route path
    { param: { echo: 'from the browser' } } // route data
    options: { /* optional:  react-query / SWR options */}
 )

This would be ideal as:

• No need to make a custom hook for each endpoint, as (at least often for me) in 90% of the cases this is most that is needed
• If custom hooks are have to be made this will make it super easy
• No hassling with type inference as currently described in the docs
• No more finding the right endpoint / import, as the hono/client has amazing autocomplete
• No need for manually adding query keys, as we can use the the generated path (without params filled in) as query key, so we can if needed also invalidate easily, as additional query key we can add the params to make it unique.

After some fighting with the types, I've make a small POC that works quite well for get requests (open for suggestions / improvements), mainly one issue I haven't resolved yet:

• How to extract either the Path and the Method from the hono/client. This so it becomes easier to make a wrapper component. As some of the typings (combined with the proxies, become quite complex / difficult to infer).

As a workaround I've now added one extra argument, in which I add the $url as key, i.e.:

const results = useEndpoint(
    client.api.echo[':echo'].$get, // route path
    { param: { echo: 'from the browser' } } // route data
    baseQueryKey: client.api.echo[':echo'].$url().toString(), // URL as key
    options: { /* optional:  react-query / SWR options */}
 )

The POC for the endpoint hook atm looks like this:

export const useEndpoint = <
    T extends (
        args: InferRequestType<T>,
        options?: Parameters<T>[1],
    ) => Promise<
        Awaited<ReturnType<T>> extends ClientResponse<
            infer T1,
            infer T2,
            infer T3
        >
            ? ClientResponse<T1, T2, T3>
            : never
    >,
    TQueryFnData = InferResponseType<T>,
    TError = DefaultError,
    TData = TQueryFnData,
    TQueryKey extends QueryKey = QueryKey,
>(
    endpoint: T,
    params: InferRequestType<T>,
    baseQueryKey: string,
    options?: Omit<
        UseQueryOptions<TQueryFnData, TError, TData, TQueryKey>,
        // no need for queryKey and queryFn as they are derived from hono/client
        'queryKey' | 'queryFn'
    >,
) => {
    return useQuery<TQueryFnData, TError, TData, TQueryKey>({
        // TODO: cast to unknown cheats the typing system, should be properly inferred but not sure how atm
        queryKey: [baseQueryKey, params] as unknown as TQueryKey,
        queryFn: async () => {
            const res = await endpoint(params)
            return (await res.json()) as InferResponseType<T>
        },
        ...options,
    })
}

So not really satisfied yet, but does save some boiler plate each useQuery call and enforces consistency throughout the codebase. As I found it difficult to infer the types I was able to use "client.api.echo[':echo']" as param (i.e. without .$get), as then we would be able to call $url and $get inside useEndpoint(...) and the key could be automatically set instead of manually added via an extra param.

Maybe a .$meta can be added which returns related data (path, method, endpoint itself so request and response types can be inferred from it), and as a sidecar I think that would also make it easier to make extensions on it (for instance adding axios instead of fetch).