-
-
Notifications
You must be signed in to change notification settings - Fork 69
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Export operation types separately #410
Comments
Hey @navicstein, got a naming suggestion? Also, can you share how (ugly) it looks when used with react-query? |
I think we can bring this back |
thanks @mrlubos or maybe provide it as an option - I'm currently using it via CLI with taskfile and it could be added as an option # https://taskfile.dev
version: "3"
dotenv: ['./server/.env']
tasks:
generate:client:
cmds:
- echo "Generating rest-client using endpoint -> $BASE_URL"
- "cd frontend; npx @hey-api/openapi-ts -i $BASE_URL/openapi.json -o ./src/rest-client --base $BASE_URL --format --enums javascript --lint --schemas --useOptions"
silent: false |
Oh that's sweet. How did you find out about these types? They were both added and modified silently |
I pay close attention to I even had an idea of generating react-query mutations and queries using |
There's https://github.com/7nohe/openapi-react-query-codegen, what do you think of that? But also, that's the integration we're planning to add next :) |
Hey, I am evaluating this library and it is going quite well - this is something that would also be beneficial on my side too 👍 |
Consider it done @samvaughton. I'm only worried about having a naming pattern that's clean and has low chance of clashing. I would hope no one names their parameters |
Nice one, I've seen comments around the postfix option too, perhaps simple callback options for altering the naming strategies services/types? No need to worry then if there is a clash. Just a thought, it won't affect me personally here :-) |
That would certainly be an option, but in that case we'd need to provide API for people to detect clashes and handle them. Without that, it wouldn't really be a better solution than a simple postfix |
Would love this as well - would make the development flow with types in projects much easier! |
Another followup thought to this one, for an API endpoint which returns an array, currently the type is something like this:
Which is actually an array type, in my case the return type is:
For me to get the type I would then have to do: $OpenApiTs["/example"]["get"]["res"][200]["values"] for example, which is now an array, I would then have to go a level deeper to get the actual data model that I need. I can then do $OpenApiTs["/example"]["get"]["res"][200]["values"][0] to actually get the type of the model. It would be great if possible that the actual model was exported, even if they are nested in the return. If it could be broken down something like below:
I can now import the data model as a single type value instead of having to get the nested values. Even if they were under the $OpenApiTs, it would still help, if it were $OpenApiTs["modelNameHere"] for example. |
@raffi1300 It is already exported like that, the only thing this issue is about is exporting top-level service types as individual exports |
My preference would be for inlining and fully expanding the types up to primitive types in the service methods directly instead of doing a type alias
|
Are you never trying to get the types for parameters or response @rubenfiszel? If yes, how would you do it with this inline approach? |
@mrlubos in our case we do not but I can see how this could be useful to craft bodies before using them in requests. Type aliases work well too! |
Hey all, going to add this in the next release. Data types will be exported as |
Fantastic, thanks a lot! |
I guess most of you saw the latest updates on this in v0.43.0. As I haven't heard anything since, I'll assume it works well. Just noting here that in the upcoming clients, there'll be an option to provide custom config for each request. This means that the function types will change, probably to something like |
Description
As I highlighted in the screenshot below, can we have the type annotation to be pure type eg
IData
instead of how it is now? I see it was present in earlier version but not is arbitry and doesn't look nice to be exported and used by other tools like react-queryThe text was updated successfully, but these errors were encountered: