What is the problem this feature would solve?

Currently the generated React Query hooks are great but in order to use them in our apps, we often need to define additional options like onSuccess, onError, meta, etc. in order to invalidate other queries, show an error flag when a mutation fails, show a success flag when a mutation succeeds, configure the error message, configure the success message, etc.
When using the generated React Query hooks in multiple apps, this leads to a lot of code duplication and maintenance overhead.
For example, if we forget to invalidate a query, it can easily result in stale UI state which is not great.
Today, we partially address that by creating and maintaining wrapper hooks to add the custom options.
However, we think this defeats a bit the purpose of generating React Query hooks.

External documents/projects?

I've opened a discussion here to discuss a little bit about the cache invalidation use case.
Indeed, I've discovered that there was an example in Kubb v2 using templates to generate an invalidations.ts file and update the generated React Query mutation hooks to use a manually defined useInvalidationForMutation() hook (see #853).
That's exactly the kind of solution I was looking for because it avoids the wrapper hooks and code duplication, it is very flexible (the declaration of queries to invalidate is optional) and type-safe (thanks to the generated Invalidations type).

However, when doing some research, I discovered that Orval has 2 options (queryOptions and mutationOptions) to define custom query options and mutation options by providing the path to a JS file.
The only thing they are missing is the type-safety (which is quite important in my opinion) and they don't provide the hook name as a parameter (which means we have to depend on the mutation key for example).
I think that's a good idea because it offers developers even more flexibility to define the custom options to be used by the generated React Query hooks (if we can solve the type-safety issue).

What is the feature you are proposing to solve the problem?

Introduce a new customOptions option to the @kubb/plugin-react-query plugin.
The option would take the path to a JS file (similar to how the client option works today) and the name of the exported hook.
When the option is set, the plugin would generate a type (for example, HookOptions) which maps hook names to hook options (like the invalidations.ts file in the example).
Then, developers could write a JS file defining a custom hook (for example, useCustomHookOptions) which takes the hook name and query client, and returns the custom options for the specific hook (and developers can use the generated type for type-safety).
I think that would be a very flexible way to define custom hook options, in a type-safe manner, and without having to write wrapper hooks, etc.

What alternatives have you considered?

• Currently, we create and maintain wrapper hooks but it defeats a little bit the purpose of generating the React Query hooks.
• We've also considered overriding the React Query generators but it seems to be a bit hard to maintain in the long run especially when keeping up with upstream changes.

Given that cache invalidation and shared hook behavior seem to be common concerns, I think addressing this use case directly in the library would likely benefit a broader audience.

What do you think? 😉