Skip to content
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

Dates in return types are deserialized as strings #68

Closed
etiago opened this issue Apr 8, 2018 · 1 comment · Fixed by #83
Closed

Dates in return types are deserialized as strings #68

etiago opened this issue Apr 8, 2018 · 1 comment · Fixed by #83
Assignees

Comments

@etiago
Copy link

etiago commented Apr 8, 2018

Environment

Node version: 8.10
Npm version: 5.8.0
OS and version: MacOS 10.13.3
typed-rest-client version: stable

Issue Description

When using a type for the response which has Date as type for a field, that field ends up being a string, thus violating the type.

Expected behaviour

If I have a field which is a Date, I expect the deserialization to fail whenever the returned type isn't a date, or if the type does represent a parseable Date, that the field gets correctly transformed into a Date.

Actual behaviour

Instead of a Date, we get string. This means that any code that I write expecting there to be a Date, becomes type-unsafe as all the Date methods are not available in string objects.

Steps to reproduce

  1. Create type class with Date field.
  2. Make request to endpoint which returns a string-encoded standard JSON Date for that field.
  3. Verify that none of the Date methods are available in the deserialized object.

As I understand, this may be tricky to solve as JSON.parse will see a string and leave it as a string. However, we could possibly introspect the type of the response and handle the Date manually.

@bryanmacfarlane
Copy link
Contributor

@damccorm - good issue. think through compat on potential fixes.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants