Open rhuanbarreto opened 3 months ago
Those are edge-cases that cannot be solved.
The problem is that you'd require the TypeBox schema on Eden's side of things to be able to decode a JSON into it's declared schema because in JSON there's no way to tell apart a Date
from a plain string
.
Therefore Eden does a best-effort and if a string looks like an ISO8601 Date it goes ahead and parses it into a Date because that's what 99% of developers would do.
If you need the string on the client-side you can still call toISOString()
I agree that the "smartness" of checking if a value is a date by regexing it is fair enough.
But at least the "get random object" test should pass because 99% of the developers as you say would expect a date inside an object coming as a Date object from a JSON response. Same for the WebSocket failure.
Havent fully gone through the code as I am on the go, but I'll check it later. Should be easy enough to fix
I just cloned your fork and ran the tests.
I do believe the test case you wrote is still one of these edge-cases that cannot be solved; as the toEqual
expects property g
to be a string but eden parses that into a Date since the value of g looks like a Date. Therefore a string representing a Date is not equal to an actual Date object.
As I mentioned in my previous comment; you cannot really solve this ambiguity problem (whether to parse a string that looks like a date or not) without the actual specification TypeBox schema definition.
This PR is still failing tests. This is to show that the complex object case is failing.