feature request: automatic date transformations based on "date-time" format prop

[smiley-uriux]

For JSON schema validated APIs dealing with string based dates (as opposed to numeric timestamps), its fairly common to serialize Date instances using .toISOString() client-side, validating them server side using the string format date-time and then deserializing them back to Date instances for backend business logic and further validation. One of the beautiful things about Oazapfts is that it captures my JSON schema as typescript interfaces so I don't have to explicitly share them between client and server. However when dealing with dates, an unfortunate transformation layer is required client side, since working with date strings is rarely convenient.

It would be absolutely fantastic if Oazapfts could take into consideration string properties with format = date-time and expect/transform all request parameters and response values as Date instances and then automatically perform toISOString() on said property values before sending to server. This behavior could be opt-in and behind a flag. I haven't started to dig into what an implementation would look like, but it seems like it should be possible. If there was interest, I might consider taking a stab at it. At first I thought some kind of generic transformation layer might be nice, but I really can't think of many other use cases for such a thing other than date transformation.

[Xiphe]

Hey, i agree that this would be a cool feature to have!

Since this is not a standard feature I'd agree that this behavior should be opt-in.

I'd like to explore if this could be solved in a generic fashion since this feature really calls "Plugin" to me and I've had a few edge-cases where a generic solution would have helped me work around a non-compliant backend.

Would you be interested in exploring this @smiley-uriux?

[smiley-uriux]

@Xiphe yeah I'd be interested in exploring it and potentially putting together a PR. If you (or anybody else following) can think of other use cases for a generic transformation/plugin layer, let's gather them together here. That might help identify the boundaries of such a feature and give us a good place to start.

[Xiphe]

Cool! Looking forward to see what you come up with 👍

As with the use-cases: I think the date transformation is a really good example of specific code that would fit really well in a plugin + as I said, creating workarounds was something that would have needed a few times now.