Easy and maintainable way to extract paramters / args type from client-fetch functions?

[lukaskoeller]

The function we use with the @hey-api/client-fetch looks like this:

export const getArticles = <ThrowOnError extends boolean = true>(
  options?: Options<ArticlesData, ThrowOnError>,
) => { /* … */ }

Since we do not use the tanstack/query plugin we create the queryOptions manually. For this we need the functions arguments / parameters type. For me, there's is no clear path how to do it in an easy an maintainable way.

Question

What is the recommended way to use the type given for parameters of a fetch function from outside? (…that is ideally "migrating safe" for future updates of the library

Considered Approaches

1. Use ArticlesData type directly

Just using ArticlesData leaves you with the problem that the type always includes the url which you obviously do not want to pass since it's set already in the function.
I remember that for older versions the url was not part of the type I believe, is that correct?

2. Use Options<ArticlesData, true>

The Options type omits the url property from the type but requires a second argument for ThrowOnError. This is also already given by the function itself and changing the configuration (e.g. throwOnError: true to false) would mean we need to adjust it in all queryOptions as well. Not ideal too…

3. Use Omit<ArticlesData, "url">

We could use Omit<ArticlesData, "url"> but seems not very clever given the lib is updated and behavior changes, you're left with migrating a lot of types of queryOptions too.

4. Use Parameters<typeof getArticles>[0]

I tried to use something like Parameters<typeof getArticles>[0] but this seems very verbose and leads to ts errors with the queryFn in queryOptions

[mrlubos]

Hey!

1. Yes
2. ...
3. This is what I'd do today
4. ...

The bigger question I'd like to understand is this

Since we do not use @hey-api/openapi-ts we create the queryOptions manually

Can you elaborate on why? Maybe solving this would be the better path forward

[lukaskoeller]

Ok thanks. Are there any plans to make usage of parameter types more easy in the future. More easy meaning importing a type directly without adjusting it, e.g. by Omit<ArticlesData, "url">?

When it comes to why we do not use the tanstack plugin, there's no hard argument against it. Reasons were to be more flexible and not vendor lock-in too deeply. Additionally, IIRC the plugin was also not ready yet (or in beta) when we adopted @hey-api

[mrlubos]

I might provide utility types at some point but those would effectively do the Omit hidden behind a fancier name.

Vendor lock-in, what would you classify as such? There's certainly some stuff around flexibility I want/need to add, but curious about your thinking there

[lukaskoeller]

That would be indeed helpful.

On second thought, vendor lock-in is probably the wrong word. Let's stick with flexibility. In general, I like to stay close to "vanilla", especially in the case of, let's call them "second-level dependencies", because it just increases the risk of having a large part of your application dependent on some code that over time proves to be missing things for your use case. Then it's harder to remove that layer of dependency. Sure, your library does a great job, that's why we use it, and it adds a lot of value. Buying in further and using the tan stack plugin on top of it was just not the right thing for us. However, I could see using it for smaller projects or projects where there is room to try things out.

[mrlubos]

Thank you for the context, appreciate it!