search

gcanti / io-ts-types

A collection of codecs and combinators for use with io-ts
https://gcanti.github.io/io-ts-types/
MIT License
311 stars 40 forks source link

DateFromISOString custom type requires Date, not string #132

Closed jerenmb closed 4 years ago

jerenmb commented 4 years ago

🐛 Bug report

Current Behavior

I have a custom type that has properties of type DateFromISOString. When attempting to populate those properties, I get an error when attempting to pass a string (as in Date().toISOString()). The desired type is Date, but this should be the case for the date type, not DateFromISOString. Passing values of type Date to these properties cause Mocha tests to fail due to "Invalid Value Supplied" errors.

Expected behavior

My understanding from the documentation is that properties with this type should be sent a string in ISO format.

Reproducible example

Suggested solution(s)

Additional context

Your environment

Which versions of io-ts-types are affected by this issue? Did this work in previous versions of io-ts-types?

I have not tested this behavior with previous versions of io-ts-types.

Software Version(s)
fp-ts 2.5.4
io-ts 2.2.1
io-ts-types 0.5.7
TypeScript 3.8.3
mlegenhausen commented 4 years ago

DateFromISOString encodes Date -> string and decode string -> Date. Could you please post your code that produces the error?

jerenmb commented 4 years ago

Essentially I am defining types that have several date fields and I need to be able to use these types locally as well as map to them when handling API calls. When creating and modifying types locally I get the error I listed above (something like Invalid value "2020-07-09T21:45:46.169Z" supplied to : Array<Exact<({ id: string } & Partial<{ created_at: DateFromISOString }>/ created_at: DateFromISOString). This occurs when supplying Date types to the properties using the DateFromISOString type. I get an error in the code locally if I try to pass a string to the created_at property which states this property requires the Date type. However, if I pass that same string ("2020-07-09T21:45:46.169Z") in the JSON body of a POST request, the type is handled just fine.

If I use the date type from io-ts then I get the opposite problem. Working with the property locally behaves just fine, but passing ISO formatted dates in API calls results in the Invalid Value error (Invalid value "2020-07-09T21:45:46.169Z" supplied to : Array<Exact<({ id: string } & Partial<{ created_at: Date }>/ created_at: Date)

Given this information, can you help me understand if there is a type that will correctly handle both situations (API calls and local) or will it be necessary to perform manual parsing to make this work properly?

mlegenhausen commented 4 years ago

Could you please provide a minimal code example that reproduces the problem?

jerenmb commented 4 years ago

We determined that the DateFromISOString type was working well for ISO strings coming in from API Post bodies which were then decoded as part of the ingestion process. However, we were attempting to run this same functionality on types being created locally as part of tests, and when an attempt to decode them was made, the properties of type DateFromISOString were already JavaScript Dates and could not be decoded properly. Our solution for now is to make the types a union of DateFromISOString and string to enable the same functionality for handling API data and to allow tests to populate these properties with strings that are in ISO format.