Feature Request: Allow Users to type into input box "safely"

[slominskir]

Sometimes the date is almost what the user wants and the user just wants to select a single digit and type a new one to replace it. Currently the default behavior is for the input box to be read-only meaning you can only modify the date using the widget. It seems using the option "lockInput": false allows users to type into the input, but it is potentially destructive since the user is allowed to type anything they want and leave the input in an invalid state. It would be a nice feature if there was a way (perhaps a focusout or blur event listener) that checked if the input matched the required format and simply reverted it to the previously valid state if invalid.

[jtsage]

That's a good point. I hadn't thought about saving the previous value and resetting it if there date object becomes invalid. I'm a bit swamped with $real_life, but I'll try and get this in sometime in the next few days.

Thanks.

[slavap]

@jtsage Please make this optional. I have my own logic on blur event, which is quite complex and trying to guess what actually users are entering, for example 021817 without any separators are parsed as 02/18/2017. Though as the last resort it would be nice to rollback to previous valid value.

[jtsage]

absolutely. and actually, I think I totally misread this anyway. I was thinking the input boxes inside of the datebox/timebox control - as I have no idea what they do right now when something invalid is put in.

But I can see the use in doing it on the original input. Right now, if it fails to read the date on open, it should default to today. But I could drop back to "last known good", perhaps "inputFallbackGracefully"?

As to .on('blur'...) - I don't think I deal with this right now. I but something like inputCheckOnBlur with similar behaviour, and maybe a inputRunOnBlur that calls a function with arguments of the input and what I think is a reasonable fallback?

None of these would be active by default, I don't think. In a lot of cases, it feels a bit intrusive to assume it should happen.

[slavap]

@jtsage inputRunOnBlur sounds good, so some "smart" conversion logic will be executed, and if no luck then datebox is free to decide what to do - default to today or "last known good".

[slominskir]

Might be able to just use a plugin like this:

https://github.com/RobinHerbots/Inputmask

[jtsage]

Alright, so there are about 1,000 ways to do this, none of which strike me as a "I like that". So, here's what I'm thinking:

if, and only if inputLock is FALSE, and runOnBlur is a function, run it on the text box value, prior to attempting to "read" the date from that text box.

The function will get the following inputs:

the previous date set by the control the new date that would be set by running the parser on it a boolean true/false that the parser would have been succesful - note that the above "new" date will be either "today" or the "default" date if it would not have been.

The function would have to return:

a boolean "I did something" value. If not, basically ignore further returns. a new date value, as a STRING, that'll go in the input box a boolean "run .change" on the box again.

At least, this is my thought process for now. ideas? concerns?

Thanks folks.

[slavap]

@jtsage Sounds good to me.

[jtsage]

So, I have a few other things to do first, this will get pushed out the door as 4.3.1 ina day or two.

[jtsage]

Ok, major changes to this workflow in v5.

@slavap, assuming you are still using your custom logic, and it's not hooked to the callback option, you're going to want to set safeEdit: false when/if you upgrade.

re: #449 is the new issue for this, with a very, very spiffy example in there.

[jtsage]

Closing this to move discussion to the new issue.