feat(query): generate query return type along with hooks

[CPatchane]

Status

READY

Description

When dealing with hooks generated using react-query, it's currently difficult to get the actual return types from the queries (not those from the schemas).
In a case where we process the data from the API (changing the case for example) using a custom client, we can't directly rely on the schemas types that have been generated, we have to get the response type from the queries generated instead.
This PR exported those new types for each functions in order to use them in components that used data from those, looking like:

export type GetDemoQueryResult = NonNullable<AsyncReturnType<typeof getDemo>>
export type GetDemoQueryError = ErrorType<GetDemo400>

// Then we can use like
type MyComponentPropsType = {
  foo: GetDemoQueryResult["foo"]
  bar: GetDemoQueryResult["bar"]
}

Note: We have to use NonNullable for some cases when the client can return undefined (201 requests) and avoid type with | undefined. In that case, the final type will be never.

Wdyt?
I guess it could be considered as a breaking change, should we maybe put this behind a config property and make it optional?

[vercel]

Someone is attempting to deploy a commit to a Personal Account owned by @anymaniax on Vercel.

@anymaniax first needs to authorize it.

[melloware]

Just to clear up my confusion can you post what it generates NOW and what your proposed patch will generate? Or is what you are saying you are generating these "additional" values?

[CPatchane]

Sorry for the confusion, indeed this PR generates new types

[anymaniax]

Hello @CPatchane, it's a good idea! There is no breaking change from what I see no? You just add new types?

[CPatchane]

Hello @CPatchane, it's a good idea! There is no breaking change from what I see no? You just add new types?

Indeed, this is only new types for the queries part only.
I was thinking maybe that new types can generate more things some people might not need, but I am clearly ok to add this feature as it and maybe put behind a config according to future feedbacks.

Btw, I just pushed a new change to use MutationResult and MutationError naming suffix for mutations for better consistency.

[melloware]

I personally love this @CPatchane . Since its add new code its really just adding new features and flexibility for users without breaking backwards compatibility I am all for it!

I just started using React Query and I can't believe I did not know about it before but its an absolutely amazing library and this Orval generator makes my life so much easier since I already have OpenAPI generated from my Spring Boot apps!

[anymaniax]

It's only done for react-query here but we should do it for all the clients

[CPatchane]

@anymaniax Is it normal we don't generate hooks for swr mutations? When I generate on my side I only have hook for queries, for mutations I only have functions 🤔

[anymaniax]

Swr doesn't have mutations like react query

[CPatchane]

@anymaniax Let me know, it should be good for the other clients :) (swr, angular and axios)

[anymaniax]

Really great job