Since PR #4393, success response types can no longer be resolved without explicit status/ok checks

[baseballyama]

PR #4393 improved the ability to get accurate types for specific status codes. While this is a great improvement on its own, it is causing an issue in my project.

In my project, we centrally manage 4xx and 5xx errors using a customized fetch function. Our design allows individual UI components to handle only the success cases. Previously, this meant our UI components were type-safe without needing to explicitly check the response code.

However, since v4.10.0 (where #4393 was released), we can no longer resolve the types without checking status or ok in each UI component. As a result, we are forced to add these checks to every single API call site. This negatively affects the codebase by reducing readability (due to increased boilerplate) and increasing the bundle size.

Is there a way to maintain type safety without manually checking status or code, just as we were able to do before? Any advice would be appreciated.

Originally posted by @baseballyama in #4575

[ambergristle]

here's the relevant discord thread, for anyone else experiencing this issue: https://discord.com/channels/1011308539819597844/1012485912409690122/1453023941634297979

the issue arises because ClientRequestOptions doesn't accept generic types for the custom fetch method (namely its response). i'm not sure what all the implications of making that generic might be, but i understand why there might be some hesitation.

• one work-around is to create a helper function that strips the error types
• another is to essentially push that back, wrapping hc instead and omitting

there are obvious problems with both of these solutions. adding a wrapper to every client call is tedious and creates a lot of room for error. likewise, maintaining a parallel/compatible type implementation that ignores error responses is not ideal.

a better path might be to also centralize error responses in onError. at least at this time, i don't think that's included in response typing. by throwing from handlers instead of returning, the success|error union is avoided entirely.

Filtering out error types from response

type ErrorStatus = 400 | 401 | 404;

type SuccessResponse<T extends ClientResponse<unknown>> =
  T extends ClientResponse<unknown, ErrorStatus>
    ? never
    : T;

export const handleResponse = async <
  T extends ClientResponse<unknown>
>(response: Promise<T>): Promise<SuccessResponse<T>> => {
  return await response as SuccessResponse<T>;
}

Custom Client typing (pseudo)

import { hc as _hc } from 'hono/client'
import { UnionToIntersection } from 'hono/utils/types'

type Client<T, Prefix extends string> = /** custom implementation */;

export const hc = <T extends Hono<any, any, any>, Prefix extends string = string>(
  baseUrl: Prefix,
  options?: ClientRequestOptions
) => {
  return _hc() as UnionToIntersection<Client<T, Prefix>>
}

[yusukebe]

Hi @baseballyama

Have you ever tried parseResponse()?

https://hono.dev/docs/guides/rpc#parsing-a-response-with-type-safety-helper

I don't fully understand your problem, so it may not be related to anything. But it may help you.

[ambergristle]

@yusukebe i think OP wants type-safety for RPC with custom fetch. their fetch implementation handles errors internally and/or with side-effects, and only ever returns ok responses.

const app = new Hono()
  .get('/', async (c) => {
    try {
      return c.json(null, 200);
    } catch (error) {
      return c.json(null, 500);
    }
  });

const client = hc<typeof app>('http://localhost:8080', {
  fetch: customFetch, // <- only ever returns `ok` responses
});

const response = client.index.$get(); // typeof response.status === 200

[baseballyama]

@yusukebe

Sorry for the late reply.

I didn’t know about parseResponse, so I tried it, but I don’t think it solves my issue. What @ambergristle said is actually my issue.

In my project, I export the result of the hc function and use it across the entire frontend.

export const backendClient = hc<AppType>("http://localhost", clientOption);

For most APIs, the design is to throw an error when the response status is 4xx or 5xx.
However, for some APIs, especially when the status is 400, we need to read the response body and show feedback on the UI.

So I have these requirements:

1. By default, I want API results to be typed assuming status 200.
2. In specific call sites, I want to keep the current typing, where types can be narrowed by status code.
3. I want to use both at the same time.

Requirement 2 is already solved. For 3, if 1 and 2 are possible, the rest can be handled in userland.

The problem is 1.
At the backendClient type level, type narrowing by status code is not possible, so I cannot get a type that assumes status 200. This is my issue.