You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is related to closed issue #1153 . We are experiencing the same issue with dates, and workarounds are proving a lot more "hacky" than we would like. While I understand what yup is doing, it would be nice to isolate its changing of the input value to only supporting the validation, but to be able to transform the input back into the expected format before processing downstream. The issue is that an ISO date only string (ex. "2021-04-01") comes back from yup as a time-zone-assigned date/time object, which is semantically a different thing. When this is serialized to JSON, it is possible that a server processing in UTC could interpret this as a different date entirely. (Again, there are workarounds here, but the cleanest solution would involve not propagating the reassignment of the input out of yup.
I'd be willing to take a swing at a pull request to add something like a postValidationTransform (see codesandbox example) but without being at all familiar with the yup library internal, would this even be feasible or desired? Or would this be outside the scope of what this library is intended to achieve?
This is related to closed issue #1153 . We are experiencing the same issue with dates, and workarounds are proving a lot more "hacky" than we would like. While I understand what yup is doing, it would be nice to isolate its changing of the input value to only supporting the validation, but to be able to transform the input back into the expected format before processing downstream. The issue is that an ISO date only string (ex. "2021-04-01") comes back from yup as a time-zone-assigned date/time object, which is semantically a different thing. When this is serialized to JSON, it is possible that a server processing in UTC could interpret this as a different date entirely. (Again, there are workarounds here, but the cleanest solution would involve not propagating the reassignment of the input out of yup.
I'd be willing to take a swing at a pull request to add something like a
postValidationTransform
(see codesandbox example) but without being at all familiar with the yup library internal, would this even be feasible or desired? Or would this be outside the scope of what this library is intended to achieve?https://codesandbox.io/s/sweet-faraday-15x8g
The text was updated successfully, but these errors were encountered: