Improve type safety on error responses

[SferaDev]

Right now, fetchers do not have a way to include error responses types. Add them and make the default fetcher to type the union of them.

Also, create types for inlined responses.

[fabien0102]

Some points after a call with @SferaDev to have more context:

The idea is to add a TError that can extends all possible errors types in the fetcher

Then, since the type will be passed in every operations, this will force the user to implement every error cases (and typescript will warn on every new error introduce in openapi)

[fabien0102]

Thinking a bit more about this, some ideas that I would love to integrate to improve the error type safety.

1. Adding an ErrorWrapper in the fetcher.ts

export NamespaceErrorWrapper<TError> = TError

This will permit to easily extend and tweak the error type, as example

// Adding a fallback error type
export NamespaceErrorWrapper<TError> = TError | { type: "unknown"; message: string; }

2. Generate a more accurate error type on components.ts

export MyRouteError = NamespaceErrorWrapper<
 | { status: "404"; payload: Responses.NotFoundError } // $ref in openapi
 | { status: "422"; payload: { message: string; field: string; } } // inline in openapi
 | { status: `5${string}`; payload: Responses.BasicError }
>

and injecting this error to the fetcher (as describe previously) as generic.

So it's easier to discriminate on status to deal with the error.

3. Exporting an AllErrors union in components.ts

export type AllErrors = Responses.NotFoundError | Responses.BasicError | { message: string; field: string; }

So we could use this in as extends value in the fetcher.ts

export async function namespaceFetch<
  TData,
  TError extends NamespaceErrorWrapper<{ status: string; payload: AllErrors }>
  /* ... */
>(){}

[SferaDev]

@fabien0102 I like your proposals.

Just make status a number please (as in Response.status).

And do we really need things like 5${string}? I think you chose string to have template literal types, but I don't see them possible.

[fabien0102]

The thing is… in openapi, you can define 5xx (https://spec.openapis.org/oas/v3.0.3#patterned-fields-0)

And also default, and this is not making our life easy in term of generation 😓
I still need to play a bit with TS to see how I can type this properly, so far I'm really happy with the result…

[SferaDev]

The thing is… in openapi, you can define 5xx (https://spec.openapis.org/oas/v3.0.3#patterned-fields-0)

Then yes it might make sense to use strings.

Although maybe we could have a union without doing any parsing.

type Status = 200 | 201 | 400 | 404 | "5xx" | "default";

And the fetcher will have to discriminate or build the logic they want per union member.

Even though I like having the status code, I don't really see the real usage other than knowing that it's likely the error will happen so I need to make sure to treat the scenario. We already get the status code from the response error in runtime.

[fabien0102]

I have the pattern to generate the correct error type 😁

So we can have numbers and discriminate properly 🎉