openapi-typescript-codegen
openapi-typescript-codegen copied to clipboard
ferdikoomen
Implementation for: Optional flag which changes string to Date in case of format data-time
This is the implementation for the issue #396.
Functionality
A new flag called useDateType is added and it is false per default. If it is used, then any generated model property which is of type string and format date-time, will be changed to Date.
Usage
This is useful if you use a response interceptor to automatically find and replace date-ISO strings with an actual Date object.
TODO
- [ ] Update Readme with documentation for new option and how to use
@NicoVogel Sorry for the late reply, so i see this an work, the only issue is serialize en deserialize flow. So i receive a date string from the backend, that gets auto converted, but then we should do the same when sending this back. That might be an issue, since date format is not standardised as far as i know...
This use case is the only reason I decided to fork a bit back. It be great to get this incorporated.
My client/XHR layer takes care of the back and forth @ferdikoomen describes above. Meanwhile the consumers of that client use the models (with dates where date-time formats applies).
@Paden What do you mean with "client/XHR layer takes care of the back and forth". Did you implement a custom XHR request?
@ferdikoomen yes, I have a custom fetch client that transforms date ISO strings to date instances. The consumer of that fetch has no idea that goes on. This is much easier than have two response types: one with dates as strings and another with dates as date instances.
If I were able to instead indicate to the codegen to treat date-time formats as dates my process could be less kludgy. I could instead use the $schema files to look for date-time formats to indicate which properties to transform to dates and then typings from the codegen would fit that.
@NicoVogel, please, why didn't this feature go to the master branch of @ferdikoomen?
To echo something @Paden said: I only want touse openapi-typescript-codegen to generate models, and my client wrappers take care of Date-to-string and string-to-Date automatically. A flag such as this would allow me to use the tool without forking it.
I would also be very happy if this flag/option could be added! Thx in advance!
Hi @ferdikoomen, @NicoVogel what is holding back the merge of this issue? Can I someone fix the remaining / open points? So we could proceed with the merge?
I also want this, but not quite the same - I want it to use the date-time types from a library not the JS standard one.
Rather than adding something specific, I think what could work is providing the ability to overridding the type mapping on https://github.com/ferdikoomen/openapi-typescript-codegen/blob/master/src/openApi/v3/parser/getMappedType.ts#L27, so the original requester can specify that type: string; format=date-time uses Date, but I could specify that a format maps to a library's date-time type.
I also want this, but not quite the same - I want it to use the date-time types from a library not the JS standard one.
Rather than adding something specific, I think what could work is providing the ability to overridding the type mapping on https://github.com/ferdikoomen/openapi-typescript-codegen/blob/master/src/openApi/v3/parser/getMappedType.ts#L27, so the original requester can specify that
type: string; format=date-timeuses Date, but I could specify that a format maps to a library's date-time type.
This would be really useful.
In my backend I'm already getting Dates from Prisma which get serialized, though I have to do some tricks to get them back into strings to work with the types as generated currently.
That said, on the client I use luxon rather than native js dates, so Ideally I'd like to have server side types generated which are expecting a Date, and deserialized types/clients which can get the ISO dates back into Luxon DateTimes.
Something that would allow the user to customize the mapping expected type would be great, even if to have different backend types would mean running two lots of codegen for front and backend.
