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.
Related
I'm working on a SPA that uses jQuery and one of the requirements is that I should trigger actions for particular values of input fields (checkboxes, dropdowns, text). I want to know from a performance perspective which of the following is faster or less cumbersome
$('input, select').on('click focus change', function(e){
//do something
});
or
$('form').on('click focus change', 'input, select', function(e){
//do something
});
Also, given that there will be asynchronous operations on the page, the second option is what I'm leaning towards but I wanted to check with you experts :)
The second snippet attaches the event to the entire form. If a user clicks/focuses/changes anything anywhere (especially the click) then the event fires. As soon as it fires it then checks to see if it was done on an input or select and if not it aborts. As a result, the second version has slightly higher overhead because it will sometimes fire for non input/select events.
The major benefit to the second format is for dynamically created elements. Lets say that something the user does causes an additional field to be created on the form. If that field was not on the page when the page initially loaded then the first version of your event will not fire when that field is changed/clicked. But, the second version would fire.
My recommendation: Unless you are specifically doing something with dynamic fields as I described, then I would use the first. Honestly though, there is such a tiny difference that either would be fine.
In terms of performance there isn't much to write home about. The difference (if any) is negligible. For asynchronous operations, i'd suggest you go for the 2nd snippet.
I have been reading a lot on the order in which events are handled in JavaScript. All articles I have read are about bubbling and capturing. That's all about the same kind of event being bubbled/captured from children to parents or from parent to children. You can't really predict in which order these events will be executed. That stuff is really clear.
My question is about the order of events in the following case:
Suppose a screen with a textfield with an onChange listener on it. Next to the field there's a button with an onClick listener on it.
Suppose you alter the textfield's value and keep the cursor in the field and directly press the button.
In all my testing it was always the onChange being executed before the onClick. I have reason to believe that this order is not always the same.
Does this sound familiar to you?
What can be said about the order in which these onChange and onClick events are handled? Does this also depend on the js implementation, or other factors?
Kind regards,
Guus
Okay, this should be pretty easy.
I have an input on a form that triggers the page to move to the next part of the form(on another page). I need to listen to that element for a click event and run a javascript function when it is clicked.
Problem is, most of the samples online show element types and element ids as the indicator of what to listen to, ie #confirm or input.
What I need is a way to listen to:
<input type="image" name="eventName.sbContinueEvent">
So far, I have this set to listen to input, but I need to further identify it as input with name of eventName.sbContinueEvent so as to not have it trigger on every input. I would apply an id, however this is a SAAS and I am not able to modify the code like that.
$("input").click(confirmedOrder);
Am I missing something obvious or is this something that requires more in-depth coding?
$('[name="eventName.sbContinueEvent"]').on('click', confirmedOrder);
note that if the page reloads, it could do so before the javascript function completes.
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.
So firefox has a nifty mechanism which will try to autocomplete values in fields when a page is reloaded or the back button is used. Which is great and all except when you have something like a drop-down which when set to a value modifies the page using ajax.
What winds up happening is that the browser reloads the page, the drop down is pre-filled with the remembered value, and then no change event is fired when the dom is ready. And therefore the change handlers attached don't fire and thus the page does not update.
Is there a good way to "fix" this behavior so that it works for the user as expected:
a) We do want the browser to auto-complete because that is a good user experience.
b) Still want that onchange event firing.
The only thing I can think of doing at the moment is to add an on-ready event to the document which has javascript pre-populated with initial values in the form, when the document loads the javascript will check the pre-populated values and if not matching what is in the input will trigger the change handlers.
Anyone have a better solution? Is there a lib that does this already?
(Using Rails 2.3.5 + jQuery)
Unfortunately there appears to be no way of actually disabling firefox from auto-filling fields when reloading a page or using the back-forward button. Fortunately the values are already there during $(document).ready() event so as long as everything in those inputs can have the .change even initially fired on them, it don't matter where the values came from and it just works.
I think you can add autocomplete="off" to prevent the browser from prefilling those fields.
You can also have a function that runs onload and basically checks to see if the value of the field matches what was specified in the value="" parameter.