I have am using the Vuejs-datepicker
The problem I am having is I want to use a typable input as well as the datepicker, but when I type into this input field it fires the keyup event which triggers its v-on:selected event.
Meaning if I start typing in '2012-02-02' with it submits on ever key up.
Usually this would be easy to solve as you can use a .length but this vue component always hands back a Date that is parsed. So that won't work.
I have the idea to deconstruct the component and build my own but was hoping someone might have an idea for a different solution
Did you tried the Event Modifiers?
You could try to use then in #keyup, something like #keyup.prevent...
Se at, look for "Event Modifiers":
https://v2.vuejs.org/v2/guide/events.html
Related
I want to internationalize the form validation messages. I managed to do that for standard inputs using this solution. For React Select, though, it's behaving a little differently. Apparently, all that is needed is to override onChange and onInvalid inside an inputProps prop.
However, it seems that the embedded <input/> doesn't fire its onChange function when its value changes. That means that, once the Select is invalid, it never changes back to valid. Another thing that might be related is that the embedded <input/>'s value is null after an option is selected.
Here is a CodeSandbox that shows how far I've got. The first Select works as expected, but with the default validation message. The second Select have a custom message, but doesn't work as expected. The <input/> is there to show that onChange is not being called in the embedded <input/>.
Please let me know if it's possible to make it behave as expected.
Thanks in advance.
I managed to do something usable but, as I said in comments, it's not pretty. If that link goes dead, it involves setting required to true/false in order to try to make the message appear only once, and using setCustomValidity whenever the message inevitably appears.
I'll raise an issue in React Select because I think there has to be a better way, as it's shown in the example with pure <input/>.
I noticed in a Knockout binding to an HTML5 date input, that the binding was firing whenever a key was pressed when typing into the control. This is in contrast to the regular <input type="text"/> box where the value only causes the observable to update when focus is lost, or enter is pressed.
I believe Knockout by default is using the change event, and so for a simple example of how this behaves without Knockout, I produced a small fiddle here (http://jsfiddle.net/qm282xdm/).
You can see that the input text box doesn't fire the change event until you lose focus or hit Enter on the box, but if you type a new date into the <input type="date"/> then every keystroke causes the change event to fire.
Is this supposed to behave this way? The differing behaviour of the text vs date input is a little counter-intuitive. I'm running Chrome Version 34.0.1847.116 and I have a feeling an older version behaved more like I am expecting, but I can't be sure.
Edit: I would like to know if this is a problem with Chrome or 'by-design'. The firing of the change event is intuitive on a text type input, and I would expect it to be the same from a date type input. In the absence of any ideas on how to work around this, I will write a custom binding that fires in the cases I expect.
It's not really clear what kind of answer you're looking for. If the question is just "is it supposed to behave this way?" then the answer is "yes". The answer to "Why?" is a bit less clear.
If you want to make them a bit more consistent, you can use the textInput binding instead of the value binding, which ensures you get immediate updates from textbox bindings. Or, with older versions of knockout, use value binding with valueUpdate: 'afterkeydown'.
How do I force blurring, but without calling onBlur event in JavaScript/jQuery?
I'll try to describe you what I need it for:
when onBlur is called, I call a PHP script via jQuery and validating input. If there's something wrong, it returns a message and then I display it back in jQuery script.
if a blurred field isn't filled, script should focus user back to that field.
And the problem is that if you press TAB to change field, and your first field is not filled, script will focus you back, but then is called onBlur from second field that is also not filled, and then it causes an infinite loop.
So, i want to blur a field and focus to another without calling onBlur event.
It's not an answer as spec'ed in your question, but what I'd suggest you do (in a somewhat UX sort of perspective) is to scrap the auto-refocus on invalid input, and instead mark the invalid field (may I suggest red, for example?). Now, you can go and deal with the (arguably) simpler problem of preventing a form submit on invalid data, instead of the problem of preventing a natural browser behavior type of an event.
Additionally, I'd dare to say that auto-refocusing is irritating for the user. Imagine tabbing to the second field, start typing, then suddenly yoink! You get dragged to the first field.
Why not just use on "change" and "keyup" instead of on blur?
I agree with Richard above, there's nothing more annoying than losing focus in the middle of typing, but if you do need to do this (Due to a customer requirement etc) - in the code that auto-focuses the field, disable the onBlur function temporarily until you've focused the field, then re-enable it.
In the form that I am developing, I need to implement a screen rule which is - Clear button is greyed out until atleast one input field is not null. For this, I have added a js function which checks all input fields and gets called during "onmousemove" event. I have added this to body tag.
I does work, but I suspect if this is the best way it can be done.
Are there better ways to implement this?
No, it's not a good idea to bind to onmousemove, especially on body — that means every time someone moves their mouse, your function is called. What you really want is to bind to blur (navigates away from an input field) or change (the value of a field is changed – be careful with IE). If you really want to get granular, you can check one of the keyboard events — keyup, keydown, keypress. And you should bind these events to the input fields themselves.
I was thinking of forcing an onblur handler to run by calling the element's blur method. But then, I thought it wouldn't work, because I remembered that calling submit on a FormElement does not cause its onsubmit method to be run.
After some experimentation, I found that calling blur does cause the element's onblur handler to get called. This seems very inconsistent, not that it surprises me (this is JS after all). Still, if there's a good reason for this, I'd like to know. Is there a good reason to call the handler in the case of blur but not submit?
I agree it seems inconsistent. My take is that OnSubmit behavior has a ton of legacy baggage because much of its functionality was designed so that people could code right inside of form elements. To this end onsubmit was used to validate input without cracking open a source editor or javascript file. My guess is that when they coded this behavior (a long time ago), this seemed wise because once you are in javascript the programmer can easily validate the input themselves so the automatic check isn't necessary. Seems like an oversight to me.
This following website on quirksmode specifically warns of this, so clearly many people are being confused by this.
http://www.quirksmode.org/js/forms.html