luxon icon indicating copy to clipboard operation
luxon copied to clipboard

Add invalidInput property to existing invalid object for invalid DateTimes.

Open TylerMatteo opened this issue 3 years ago • 2 comments

Is your feature request related to a problem? Please describe. When attempting to parse a string into a Luxon datetime, I have no way of knowing what string was passed in to parse when the parsing wasn't successful. My use case applies to fromFormat but this could apply to others as well, considering formFormat should be avoided when possible. The resulting Luxon datetime only tells me the invalid reason and explanation, but the value that it attempted to parse is lost.

Describe the solution you'd like Given a luxon DateTime in an invalid state, I would like to have the value of the input that couldn't be parsed as a part of the invalid object, ideally alongside invalidReason and invalidExplanation. This could be added to the existing functionality that constructs the invalid object.

Describe alternatives you've considered I have considered pre-validating the string I would pass in and setting "filler" values. For example, if the string I would parse is "10/" into a format of "MM/yyyy", then put in a filler year, such as the current year. Something similar could be done with fromObject by just only passing in the datetime pieces that you have and letting the rest go to the default (usually the current year, time, etc or 1). This is no ideal, particularly for scenarios where I am parsing a date entered as a string into an <input> because I end up having a luxon datetime that doesn't reflect what the user has entered so far and I have to account for that downstream

Additional context This would be particularly useful in the context of code to manage the state of html inputs that have the pattern of supplying parse and format function where the former takes the string in the input field and returns a more useful data type (such as a luxon datetime in this case) and the latter takes the value of that data type and returns the string to show inside the input field. In this case, this new property would allow me to store an invalid luxon datetime as the "real" value of the field but still know what string to display to the user. You can see examples of this pattern discussed or documented at: https://github.com/formium/formik/issues/1525 and https://final-form.org/docs/react-final-form/types/FieldProps#parse

TylerMatteo avatar Nov 29 '20 17:11 TylerMatteo

Is there any interest in a feature like this? It would be very useful for my use case and I'm happy to take a shot at a PR for it.

TylerMatteo avatar Dec 02 '20 17:12 TylerMatteo

Yeah, we could have an invalidData field. I think we'd accept that PR

Note that in 2.x, we are planning to not have invalids at all and just throw, since invalid DateTimes have created a lot of headaches

icambron avatar Jan 24 '21 03:01 icambron