I'm developing a touchscreen application that, aside from everything else, records the amount of times the screen is used so that the user can be reminded to clean the screen after a predefined number of clicks.
I've got the click functions written nicely, all I need now is make sure the function is called on a click.
I imagine $('*').click(function() { //do something }); would accomplish my goal, but is that the best way? Also, would that overwrite other click functions assigned to the elements?
It would add, not override, but a better solution would be this:
$(document).click(function() {
//do something
});
Since clicks bubble, just listen up at the document level with one event instead of creating events on every element beneath. For the override part...you can add as many handlers as you want, they will just execute in the order they were bound.
The best way is to assign the event handler to document itself. The events bubble and document can catch them all, while still retaining the origin of the event.
Related
Let's say I have bunch of click events. Also one/few of them is for document object.
Which one is better for performance? Click event for each element or :
document.addEventListener('click', (e)=>{
if(e.target == firstObject){ firstFunction(e) }
if(e.target == secondObject){ secondFunction(e) }
if(e.target == ThirdObject){ thirdFunction(e) }
})
Neither is "better." They each have their place in your toolkit.
A single delegated handler is more complex in that you have to do the kind of dispatch you're doing in your example (often using closest or matches), but has the advantage that if you're adding/removing elements you want to act on, you don't have to juggle event handlers.
Directly-assigned handlers are simpler (at least on elements that aren't added/removed), can prevent propagation, and let you keep your code more modular, more in keeping with the single responsibility principle.
Use the one that makes the most sense in a given context.
I think event listener for each element is better if possible, and makes sense in terms of code quality. There are some cases though where a document event listener will be needed ( for example to emulate a click outside behaviour)
That being said here are some of reasons that makes event listener for each element a better solution
event propagation is handled for you by the browser, if you decide to have only one event handler for the whole document, and u want to have event listeners for elements that are contained in each other, then you will need to handle propagation your self. That is to say you need to handle the order in which functions run yourself, and then you will have some either complex generic solution, or a specific imperative verbose code with a lot of if else statements.
Easier to read code, this is even more true for recent frameworks for web like react, angular, etc..., so for example assume you want to have a listener for clicks on the document, where that code should reside, in which file, and which component should own the code.
Removal of event listeners is handled for you by the browser apis, the browser gives you a way to remove event listeners. If you decide to go with a global event listener then you should handle removing event listeners yourself.
Your code will be hard to refactor and easier to break later, because you are coupling your document (or container ) event listener to your components internals. That is if you decide to change the structure of these components later, your document based event listener will probably break. This will depend a lot on how you identify the target of clicks, for example if you were identifying them by class names or other attributes, then these attributes might change later for reasons like styling.
and if you depend on ids for example you might eventually have unexpected results. because what happens for example if you added a listener for an element that has id, removed that element, and then later added another element with same id.
You miss on the development tooling provided for you by browsers, browsers can show you attached listeners for elements, with a document based event listener you wont be able to do that
It's better if you add one by one, because then you can remove event whenever it finish. Moreover you have more control about this event.
I'm using an module-project from Github on my Angular project, that lets me resize my DOM elements, which are drawn on top of a div, that works as a draw-board.
To shape my first elements, who are simple rectangles, by the way, i am using a mouseDown - mouseMove - mouseUp combination Event Listener, and then when i decide to resize one i hover over the edges and resize it.
Problem is that on the resizing event, which is a combination of resizestart - resizing - resizeend, although i know that the module is using and mouseDown-Move-Up Event listener and emits the events mentioned before, i cannot get the MouseEvent created, and instead i get the ResizeEvent, which doesn't have a stopPropagation() method, so calling it as it is gives an error(that it's not a function).
I need to stop Propagation, because when i resize my Elements on my draw-board the click event gets bubbled to the immediate parent element, and as a consequence i resize an existing element and create a new rectangle at the same time.
On top of that, the ResizeEvent doesn't even include an "event.target"-like property which makes matters worse...
So, i was wondering how can i work around this one??
I was thinking using #HostListeners, but wouldn't the code executed in that directive get mixed up with the Resizable directive(the module is declared as a directive)??
And messing around with the Resizable-module files doesn't sound like a good idea, since if anyone wants to use my module will have to download my tampered files of the resizable project...
Answer to your question is :
event.preventDefault() will stop the default functionality.
I think this may solve your issue.
The event.preventDefault() method stops the default action of an element from happening.
For example:
Prevent a submit button from submitting a form
Prevent a link from following the URL
$(document).ready(function(){
$("a").click(function(event){
event.preventDefault();
});
});
I don't even know where to begin. I'm using Kendo Grid to list data sourced from a server. Everything is fine on first load including when I add additional functions and dom elements in the dataBound function. Calls to the server seemingly update (sync) the Grid just fine. BUT, it seems the dataBound function is called an additional time the second time round. Performing an on click function coded in the dataBound performs it a total of 4 times. How do I test for where the issue is and what do I need to destroy to stop this infuriating behaviour?
I don't even know what code to give you save for pasting in my whole website. What is the underlying theory behind this behaviour because there's obviously something I am fundamentally missing about how javascript, and therefore Kondo, works? How do I test for this, please. Thanks!
A quick solution might be to use off() then on() in the databound e.g.
$(".cell").off("click").on("click", function(e){ ... });
this will get rid of previously attached handlers and ensure you only have one.
Even better, use event delegation outside of the Grid generating code.
$(document).on("click", ".cell", function(e) { ... });
With event delegation, the target of the event does not have to exist at the time the event handler is setup. In the example above, the click is on the document object which already exists, but the handler will only fire if an element with the class 'cell' is actually clicked. You can define this handler once in the document.ready before the grid is even created.
After my previous question I heve this one, that might be better.
I need to add a lot of items on the page and I see that sometimes appendChild+fregment is faster than innerHTML. Anyway now I would need to know the fastest way to add elements and add event listeners too.
One way I see is to listen on the window object and then filter.
Pros:
Only add once, then never
No memory trap if you forget to remove events listeners before remove as the event is added on the window object
others?
Cons:
Maybe slower?
Slower as we need to filter the items and will listen for everything everyime... maybe too slow at this point, I don't know.
The other way I know is to listen on the created element.
But with innerHTML I think only works with the window object listener.
Any other oppinions?
thanks
Best practice to handle "multiple" event handlers for "many" elements is event delegation, which is basically what you described.
Create a listener on the closest shared parent (document.body will of course do it for any element, but maybe there is another parent node below that).
Performance should not be the issue there. It's far worse to create like 200 event handler functions instead of one.
I am in the process of creating a huge web application, with a JavaScript based UI, and many events generated continuously.
To avoid bad performance due to the huge amount of the event listeners needed, I of course opted to use a single event listener which will catch all the events generated from the children elements (event bubbling).
The problem is, this application is designed in such a way that one or more modules can be loaded into the main JavaScript library I'm coding (which is responsible for controlling the UI and every other aspect of the program). Of course every module should be completely independent from each other, so you can choose which methods to load, without affecting the general functionality of the library, only adding or removing features.
Since every module can operate in different DOM elements, I need to have at least a single event listener for each module, since two modules can listen for events generated by html elements placed in different DOM branches.
http://jsfiddle.net/YRejF/2/
In this fiddle for example, the first button will let the first paragraph trigger an event, and its parent will catch it. The second button will let the second paragraph fire the event, but the div listening for the same event won't catch it, because it's not fired from one of its sons.
So my question is: is it possible to have a single event listener, able to listen also to events triggered from elements that are not its sons (elements placed everywhere on the page)?
I was thinking about having a js object, or a dom node, which store the data of the element which triggered the event, and the event itself, then a general event will be fired on the global event listener (no matter where it's placed in the dom), and it will then read the data to discover which element generated which event, and act accordingly.
Any help or suggestion about better ways of achieving this?
jQuery has a special binder for this kind of cases: live(). It let's all events bubble to the document and then handles them accordingly. However, if you use div or other containers for different panels etc, maybe using delegate() makes more sense. Don't worry too much about the number of bound elements. Believe me, it will run as well with 50 binds or 10 delegates as it will with 1 live.