-
Notifications
You must be signed in to change notification settings - Fork 6k
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
Typescript: Dates Are Not Deserialized #2776
Comments
Noticing this for format: byte as well. Sets data type to ByteArray but is not deserializing that from the string. |
@pixelshaded thanks for reporting the issue. Would you have cycle to port the solution from JS to TS: #2030 ? |
Potentially. Honestly I've got a workflow where the source swagger spec goes through a processor before going in to codegen. In this processor, I essentially make up for any short comings in codegen - remove format date-time and byte so I get strings as the data type, along with removing enums from definitions because they dont get generated correctly atm. I may be able to take some time this weekend to start looking at these issues. |
I would suggest that the desiralization of date are not handled by swagger codegen, or that it is optional, because the proper place for this would be in the $httpProvider.defaults.transformResponse collection as described here http://aboutcode.net/2013/07/27/json-date-parsing-angularjs.html |
@moanrose thanks for the suggestion. For other langauges (e.g. C#, Java, Ruby, Python, etc), the auto-generated SDK handles the deserialization of string back into datetime object in the language automatically so doing the same in Angular 1or 2 API client will make the developer experience more consistent. If it's more common for Angular 1 or 2 developers to handle the deserialization in their own program, then one workaround I can think of is to document the datetime string as (Re-post: #3105 (comment)) |
@moanrose I agree with @wing328 that the deserialization should happen as part of the generated code. The article you linked to simply provides one option for a place to deserialize date objects in Angular code, but it doesn't necessarily mean that it's the "proper" place to deserialize date objects. In fact, from a software engineering perspective, I would argue that |
There are also the other TypeScript clients (e.g., TypeScript Fetch) which don't have a feature like |
So we already define DateTime fields in swagger.json as
However, they do not get deserialized from string (ex. EDIT: using 2.3.0 branch from a week ago. EDIT2: to work around that, currently I have to name the field as Thanks |
What we ended up doing, and what works for us is a combination of the following We are using JSJoda - LocalDate, LocalDateTime on the client to keep dates and date times seperated. We have configured Spring Boot to serialize all dateTime to a zoned datetime format in UTC - which get deserialized using Local Time Zone on the client. The Dates gets serialized as ISO 8601 Date We use regular expressions to substitute properties with matching date formats, to instances of corresponding JSJoda date types - in a recursive fashion. We have modified both the AbstractTypeScriptClientCodegen, api.mustache, and model.mustache to accomplish this |
FWIW, I opted to pass the date fields through the Date pipe in Angular to display them in local time. With that, the input can either be an ISO string or a Date object. But if we test these with Date objects, technically the test input differs from the runtime input of ISO strings, even though the results look the same. So it's just a matter of being pedantic for now. But if we haven't used pipes, the manual deserialization to local time (e.g., using toLocaleString()) would incorrectly assume that we get Date objects, and would pass unit tests while failing in production (unless we catch that in e2e). A workaround for that would be to manually create Date objects out of those fields first, e.g. All in all, this is still inconsistent behavior, in that it defines the date-time fields to be of Date type, while not doing anything on the real outputs to turn them into Dates. We need to either keep them defined as strings (as they are in Swagger), or do an explicit conversion in the generated code after http.request(). Since the latter requires more work, it'd be easiest to just keep them as strings. Or to define them to be of compound type |
@dinvlad I like Swagger It would also be easy to write mapping utility functions:
|
I've run into this problem and I've made a fork and a branch to fix it for our use case. We are using the https://github.com/karlvr/swagger-codegen/tree/correct-types The changes I've made:
My implementation is very |
@karlvr thanks for sharing the solution. Do you mind submitting a PR so that we can more easily review the fix? |
I suggest to configure the type mapping as suggested in #5587 (comment) |
Some minutes ago I was going to fix an issue by @wing328 way described here. However I see 7 typescript templates! They are pretty different and don't have a common shared logic. I don't understand which exactly template should be fixed in scope of the current "bug". Maybe we should extract http request logic to a separate file and reuse it in all templates. But then it's strange to have templates like Also it looks like at least one template doesn't have datetime issue: see typescript-node I see there is a beautiful common javascript template. It would be cool to have typescript analog. |
I think I'm experiencing the same issue, but wanted to double check. The main issue is when using type The second bug that this issue is not addressing is that regardless if the format is Are there any plans to fix these bugs? Should I open up a PR to fix these issues in Part of swagger spec:
|
If you are using autogenerated-config.json you can add this config so it gets autogenerated to:
|
Any news on this topic? This bug seems still to exist. |
If you have a property in a definition that is a string with date-time format, the typescript generated model makes that property a Date type. However, the response in the client is given verbatim. It never looks for date strings and actually transforms them in to Date objects. So the project will build, but fails at runtime if you try to access Date specific methods since it's actually a string.
I imagine this relates to:
#1951
Since this PR focuses on deserializing dates in the response. I would suggest making those properties strings until deserialization is supported, otherwise the type checking isn't actually accurate.
The text was updated successfully, but these errors were encountered: