Closed aersam closed 2 years ago
Ok, seems to be trivial to implement. Only tests are missing. Let me know what you think. Would you consider merging this if I add tests?
See https://github.com/cyclosproject/ng-openapi-gen#limitations, 4th bullet. The generator does no data transformations. Having a field typed as string | Date would result in serializing the Date.toString() representation, which is not the ISO format. So I don't think this is a good idea.
Ok, you are talking about Pushing things? My use case is more get-related which you not require serialization. Also I override Date.toString to produce ISO anyway ;)
I just want to be able to assign a Date to a string | Date field after having received data
I see no other practical way than to cast the object to a mirrored interface type which have the date field as string | Date
.
yes that would work. But my life was simpler if I could just override arbitrary types :) But I understand it's a dangerous feature. In general it would be really nice if ng-openapi-gen
would be more extensible so that something like this could be done in an extension or a separate package that uses ng-openapi-gen
as an API. That's probably a bit a larger thing to do I guess :)
Well, we've written ng-openapi-gen (and previously ng-swagger-gen) for our own https://github.com/cyclosproject/cyclos4-ui project, but published it online in the hope it could be useful for others, and also to increase the project's quality.
That's probably a bit a larger thing to do I guess :)
Surely. We consider ng-openapi-gen to be mature and feature complete, and don't focus in new developments anymore. I don't think we'll ever include new groundbreaking features, and this would sure be quite large :) As more and more people use the generator, it is common that requests come in, but except for critical stuff, I wouldn't hold my breath ;)
Ok, makes sense. But also means it should be easy to keep a fork up-to-date with things I need :)
Sure, feel free to fork. actually, the fix should be quite easy, just changing the tsType()
function in gen-utils
to return a different data type for date, similar to the current condition for Blob:
// A Date
if (type === 'string' && schema.format === 'date-time') {
return 'string | Date';
}
I think it is very correct to say that a Code Generator for OpenAPI should by default say a date field is a string. Personally I like to have the type as
string | Date
or maybe one nice daystring | Temporal.ZonedDateTime
. This allows me to override the value in a loop or so - but only if required and all my code has to deal with both types.If you want I'll implement a property that allows overriding the default type for Dates. Or maybe it's even better to allow overriding based on any format?