I am learning Angular5. And I am reading the official documentation about Attribute Directeve
In particular, I read that in the section Respond to user-initiated events:
Of course you could reach into the DOM with standard JavaScript and attach event listeners manually. There are at least three problems with that approach:
1. You have to write the listeners correctly.
2. The code must detach the listener when the directive is destroyed to avoid memory leaks.
3. Talking to DOM API directly isn't a best practice.
Can you give me an example of this in javascript in order to compare the two approaches?
Angular
// html
<button (click)="onClick()">Click Me</button>
// ts
onClick(){
// run some code on click
}
Native js
<button id="my-button">Click Me</button>
// js
// attach click event
document.getElementById('my-button').addEventListener('click', onClick);
// remove click event on component destroy
document.getElementById('my-button').removeEventListener('click', onClick);
As the docs are saying
In native js, you have to grab the element you want to bind the event to then attach the click listener. You can see angular binds the click event to the element for you since you use the attribute directive.
In native js, when the component is destroyed you would have to detach/remove the event listener manually to avoid any memory leaks. Angular does this for you automatically.
Talking to DOM API directly isn't best practice. This is because angular is set up to run in other environments. For example using angular universal you can pre-render your code on the server. In this case the server does not have a window object. So talking to the DOM API directly would cause things to break in universal.
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 am little confused,
I am using bootstrap theme in angular. Some one has written tab implementation as provided by bootstrap. But there is problem, it is in JavaScript. so events such as bs.tab.show are not captured by using observables. Observable.fromEvent does not run on subscription. The method used to trigger DOM event in bootstrap library is $(element).trigger('bs.tab.show', ...)
My basic understanding is whenever any event such as click, hover or in my case bs.tab.show is triggered from DOM, event goes in event stack, and observables is using same event stack to read events.
Could anyone point out difference?
It appears you may have the name of the events wrong.
If I use fromEvent with show.bs.tab instead, the event is triggered.
fromEvent(elem, 'show.bs.tab').subscribe(() => {
console.log("Heard")
})
Here is a StackBlitz demo
Hi I'm developing my view in JS and I'm stuck in binding a click handler for my horizontal layout element. I've tried using Jquery
$("#myHorizontalLayout").bind("click",function(){window.alert()});
Which didn't work then I tried using attachPress with the element which obviously didn't exist. Please help.
Update:
The JS view is the default view of the application.
When on/bind does not work, it could be that the HTML of the control has actually not been created yet at this point in time. But even if you delay the binding, the re-rendering (re-creation of the HTML after changes) would remove your listener, at least when bound on the control itself.
A proper way of doing this is using the generic attachBrowserEvent function available on every control (here: on the layout) which internally handles all the rendering/rerendering stuff, see this example:
http://jsbin.com/hijutunefi/1/edit?html,output
attachBrowserEvent works for any browser event, as it attaches a new browser event listener to the root node of the control. For the most common browser events UI5 does event delegation, so for the "click" event and several others addEventDelegate can also be used, as pointed out by aborjinik.
Alternatively, listening on the <body> level with normal jQuery mechanisms should in general also work.
Which didn't work then I tried using attachPress with the element which obviously didn't exist. Please help.
Does this means that the element on which you are attaching event handler doesn't exists at this point? If this is the case you can hook the handler to some container, upper in the DOM hierarchy which you are sure that exists and filter the click events.
Example:
$("body").on("click", "#myHorizontalLayout", function(){
alert("Hey, you!");
});
As of jQuery 1.7, the .on() method is the preferred method for
attaching event handlers to a document. For earlier versions, the
.bind() method is used for attaching an event handler directly to
elements. Handlers are attached to the currently selected elements in
the jQuery object, so those elements must exist at the point the call
to .bind() occurs.
Reference here
So try replacing bind with on and let me know if it works or not.
Assuming I have this code, button with inline onclick event:
<button onclick='..js stuff..'>mybutton</button>
I have this button created multiple times because of server-side loop.
Or I would be better giving a class to these buttons, and just do (using jQuery):
$(".button-class").on('click',function(){..});
What is better in terms of performance?
My questions are-
In the inline onclick, does it creates a handler for each button?
In jQuery event binding, does the handler is created only once, and is binded for each button, or, here as well, the handler is created multiple times?
I guess that these are the factors which affect any performance difference. Perhaps the only downside for .on(..) is that I have to do DOM search by class name. (?)
The answer is: it doesn't matter.
Use the latter (jQuery binding) because it moves the code away from the DOM and makes it easier to work with.
With the inline attribute a different handler is theoretically added for each event; each attribute implicitly creates a new callback/function1 that wraps the supplied code. This handler will be replaced if the attribute (or corresponding DOM property) is assigned a different value later. In the case when all the event handlers have been created this is the "worst" approach in terms of book-keeping.
With the jQuery (addEventListener) version the same function callback is added for all the matching elements. Multiple event handlers for the same element/event may be added; care may be required to avoid unintentional repeated-binding.
Furthermore, with delegated events jQuery could avoid binding to each element separately (ie. it only binds one event handler further up the propagation chain). Depending on how many elements are to have events "attached", this could result in a significant decrease of actual events listened to while still only using a single event handler function.
The chance of their being an actual real-world performance difference between the approaches is slim-to-none, degenerate cases aside. Use the form that is most clear/extensible/maintainable which, IMOHO, is rarely the event properties; especially when embedded directly into HTML attributes. (One issue with the inline attribute form is that it cannot bind to an appropriate closure context and so it must use - ick! - global context in many cases.)
1 Browsers first only had inline events (almost exclusively specified in HTML attributes) and are well-optimized for this case. The actual event handler function is only created on demand. Consider the case of <button onclick="alert(">Hi!</button>, where the "onclick" contains a syntax error in the inline JavaScript. A modern browser will only parse the JS (and thus only create the actual handler function) when the the button is clicked or the .onclick property is read.
Using onclick is frowned upon and considered bad form, you should instead be using element.on('click') with jQuery or ng-click in Angular.js.
They both result in the same number of listeners, and basically the same performance.
The counter part using on.event is: if you reload Or rerender the objects using akax you need to instanciate the on.event again, it creates more code and thats more complicated.
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.