Is there a way to parse Dates and date iso strings without losing toJsonSchema capabilities.
I'm trying to parse dates and also allow for date objects, but I also require toJsonSchema to work without exceptions.
Is there a way to have all three functionalities combined? It is fine if the json schema only shows the string input.
I don't want to convert date -> string -> date if possible and also keep only one schema.
10 Replies
Can you just define the string part first, convert that to JSON schema, then
.or
it with Date
for use in the rest of your app?
If not, another less efficient way would be to extract out the string part after with dateParse2.extract("string").in.toJsonSchema()
It is sadly not really possible for me to convert it first and than adding date.
Is it possible to target the extract in a nested obj and not loose other definitions i.e.
or in generally edit a nested obj? That would kinda solve my problem I think.
I mean you could
.merge
it and replace the date and I'm actually publish a map
API that will allow you to easily change one key in the next releaseMerge should work, have not thought about that yet, good idea
This is another case where a loose or lax mode could be helpful for converting to json schema i.e. when multiple types are given only use the valid ones.
Yeah I can see that, but I'm pretty wary of implicitly clobbering a bunch of stuff that could be important
Like if someone defines a symbol type, should I just delete it?
Seems pretty bad
I do think more options though around what you're describing would be good
But e.g. I don't think I would just randomly remove branches from a union
Yeah I see that. Maybe it should just be an optional parameter for the
.toJsonSchema({lax:true})
. Which is false by default and has some warnings in the docs 🤷♂️ Would have to think about this a bit more tooYeah I just mean even if you have that enabled, where is the line?
E.g. if my object is
[symbol]
, there is nothing valid I can really say about that
Symbols are totally impossible to represent in JSON or JSON schema and it's a single required elementI totally see that. Maybe the lax mode only works on optional types but again this is highly confusing imo
Yeah sadly a lot of the time you just want a particular thing for your use case but when you have to define it at a library level in a cohesive way that won't cause problems it becomes way more complex.
But there are some easy wins like a lax mode that could strip out constraints on your type like
.narrow
that were not serializable is pretty easy to define and would still be a winI guess the most problems regarding this stem from dates anyways. Maybe just handling them a bit differently would solve like 95% of problems people run into.
Again thanks for your input! I will think about this a bit more and create an issue the next days.