You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi! Thank you very much for this project, it has served me extremely well. Today, the hey-api code generator produces an SDK artifact which exports an ordinary JavaScript function for each operation declared in the input OpenAPI schema. This has worked pretty well, but I've run into a two snags:
The more pressing one, which is the issue of resolving the underlying client for the SDK to use (FYI I am using fetch). If I understand correctly, according to https://heyapi.dev/openapi-ts/clients/fetch, my two options are to either set a global client, or to specify the client for each call. Our issue with the global client is that we have simulation/test workloads where multiple clients are accessing the API, in the same process space. We use cookies for auth so the underlying fetch instance for each client needs to be distinct. As far specifying the client per call goes, I'd like to avoid it since its really easy to miss one (I believe this behavior was slightly changed in a recent release?)
In terms of UX, its difficult to rely on autocomplete for discovery what operations are available in the SDK. This is slightly addressed with wildcard imports, but my editor isn't smart enough to automatically insert one.
A instance-based interface where the client is injected via the constructor would solve both of these problems nicely I think. The client (and other configuration) is set once for the lifetime of that class instance, and you can create multiple of them at will, free of conflicts. Then the client can be passed around as desired to whoever needs it.
Could be implemented as a class or object, but usage could look something like this:
Hi, yes! This is in fact one of the most request features and of course will be implemented. The recent change you're referring to is that you can make the client required in each call if you want. Stay tuned for more updates and thank you for using this package!
Description
Hi! Thank you very much for this project, it has served me extremely well. Today, the hey-api code generator produces an SDK artifact which exports an ordinary JavaScript function for each operation declared in the input OpenAPI schema. This has worked pretty well, but I've run into a two snags:
A instance-based interface where the client is injected via the constructor would solve both of these problems nicely I think. The client (and other configuration) is set once for the lifetime of that class instance, and you can create multiple of them at will, free of conflicts. Then the client can be passed around as desired to whoever needs it.
Could be implemented as a class or object, but usage could look something like this:
Don't know if this has been considered before or the feasibility of it - but thanks for taking the time to read!
The text was updated successfully, but these errors were encountered: