Openapi-generator: [Question] [typescript-axios] Only interfaces output with typescript axios generator

Created on 13 Apr 2020  路  18Comments  路  Source: OpenAPITools/openapi-generator

Hi there,

thanks for this awesome tool! It works quite well, the only thing I'm wondering is, how can I generate classes instead of interfaces with typescript-axios?

With the typescript-node generator it works fine, classes are generated. Would be nice if someone could help me out.

Using version "@openapitools/openapi-generator-cli": "^1.0.12-4.3.0"

Thanks in advance

TypeScript Bug

Most helpful comment

It is in active use in our company now so I think the answer is yes. I will make an effort today.

All 18 comments

馃憤 Thanks for opening this issue!
馃彿 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

Are you just wanting the classes and none of the api generated? If so you could still use the node version and just script remove all the code you do not want while retaining the class interfaces.

I want the API as well as the classes. For me it makes sense to extend the classes coming from the backend with some properties I only use in the frontend, thats the reason behind this question.

Thanks,
Andi

Hi @andreasseiler,
I've recently met the same issue and locally made some changes to make it work.

Do you think an additional boolean property (like --additional-properties=modelsAsClasses=true) would suit your case? If yes, I'll proceed with a PR containing the required changes.

Hi @andreasseiler,
I've recently met the same issue and locally made some changes to make it work.

Do you think an additional boolean property (like --additional-properties=modelsAsClasses=true) would suit your case? If yes, I'll proceed with a PR containing the required changes.

Hi @n0idea, thank you for your reply! Yes, thats exactly what I would need! And I guess other people too! If you introduce this flag, it might make sense to remove the flag -withInterfaces, as it seems to be doing nothing anyway for the typescript-axios generator, am I right?

Thanks alot for your help!

Andi

Note that TS interface just describes a shape of an object - it only exists at compile time.
However, a class is a runtime entity. Now the problem is that data coming via http is plain JS object. And the code generated by typescript-axios doesn't currently doesn't do anything with this raw object.
In order to support classes you would need to recursively traverse the whole response body and map raw data to a tree of class instances.

@amakhrov thanks for the reply. I'm quite sure everybody using this tool knows the difference between interfaces and classes ;)

To be honest, I haven't looked into the implementation of the typescript-node generator, but I'm confident the people implemented it, have done it returning "real" classes.

My question was more in the direction if the implementation of the typescript-node generator can easily be used in the typescript-axios generator, after all the flag withInterfaces exists in the typescript-axios docs. For me that implies, that the logic is somehow connected to the typescript-node generator.

Thanks anyway for pointing it out, in case someone missed it.

Andi

@andreasseiler I just wanted to point out that changing from interfaces to classes here is not a simply matter of changing a template for a model. Api calls themselves should be updated to transform data at run-time (similarly to typescript-node or typescript-fetch) - which is currently not the case for typescript-axios.
That's all :)

Hi @amakhrov,

@andreasseiler I just wanted to point out that changing from interfaces to classes here is not a simply matter of changing a template for a model. Api calls themselves should be updated to transform data at run-time (similarly to typescript-node or typescript-fetch) - which is currently not the case for typescript-axios.
That's all :)

This is exactly what I was referring to with:

I've recently met the same issue and locally made some changes to make it work.

What I did in a local build was to modify the sourcecode to accept a modelsAsClasses additional property and to use that property in .mustache templates to:

  • generate Models classes instead of interfaces;
  • generate an ObjectSerializer class (the same one used in typescript-node);
  • generate all the mappings needed for ObjectSerializer to work;
  • perform run-time objects casting to classes before returning Axios responses;

This works quite well for my project's specific requirements, but I'm waiting to have some spare time to cleanup everything and run some additional testing before putting all of this in a PR.

@andreasseiler I just wanted to point out that changing from interfaces to classes here is not a simply matter of changing a template for a model. Api calls themselves should be updated to transform data at run-time (similarly to typescript-node or typescript-fetch) - which is currently not the case for typescript-axios.
That's all :)

Thanks! Didn't want to sound arrogant or something ...

Hi @n0idea,

your solution would be exactly what I was looking for!

Thanks!
Andi

Hi @n0idea ,

did you get the chance to create a PR yet for this?

Thanks,
Andi

@n0idea if you haven't had a chance to finish your PR, I will need to reimplement what you have done. The API also needs to correct for snake and camel case in APIs as well, so this generator needs a lot of TLC to be really properly usable, even for basic OpenAPI support.

I am tagging relevant issues in case I can get some feedback for my updates to this generator. I have written extensions to the generator and it is here: https://github.com/rvowles/openapi3-typescript-axios

I would like people to test it out if they can so we can iron out all of the issues before submitting it back.

@rvowles could you please share the current status of your improvements? There are no open issues in your fork, does it mean that it's ready to be merged into the main repo?

It is in active use in our company now so I think the answer is yes. I will make an effort today.

@rvowles any chance to take a look on PR?

I haven't - because it works nicely outside of the main openapi core, there isn't a huge driver to merge it back in. I actually really really don't like that all these generators are part of this beast. It is working really well for us.

Was this page helpful?
0 / 5 - 0 ratings