So I've been going through Head First JavaScript and I came to a section on Event Handling with Function Literals. The book explains that you can wire all your event handling in your 'script' tags. But I am confused on how I get multiple functions to fire off on one event. Here's my code:
//Event Handling with Function Literals
window.onload = function(evt) {
//THIS IS BROKEN
document.body.onresize = resizeImg();reportImgHeight();
//Onload: Functions to Execute -- THESE WORK
resizeImg();
reportImgHeight();
}
So specifically for this example, how do I get an "onresize" event to execute BOTH resizeImg and reportImgHeight (functions which I have defined elsewhere in my code). Thank you!
The cleanest solution is to use addEventListener :
window.addEventListener('resize', resizeImg);
window.addEventListener('resize', reportImgHeight);
This way you can decouple both bindings.
Note also that you should bind the resize event to the window, not to a document part.
You will have to do this
document.body.onresize = function(){
resizeImg();
reportImgHeight();
};
And if you want to call them like they would be if they were separate you could do something like this
document.body.onresize = function(){
resizeImg.apply(this, arguments);
reportImgHeight.apply(this, arguments);
};
This passes through the this that you would have had if it were one, and the arguments passes through all of the arguments that were passed to the event.
Related
Why can’t I bind a function () to the onload event and the resize event the same way?
I want to bind my own functions to javascript’s onresize and onload events.
This is test code in a .JS file.
I made it work by using two different ways to bind my functions to the events.
And it works well.
window.addEventListener('resize', function() {
alert (“Hi from resize”);
}
window.onload = function () {
alert (“Hi from onload”);
}
However, when I try to use the same way to bind them, one always fails. I.e. Neither of these work:
window.resize = function () {
alert (“Hi from resize”);
}
window.addEventListener('onload', function() {
alert (“Hi from onload”);
}
I’ve found endless posts on how to make specific examples work one way or the other.
But I can’t find anything that hints at why the same way won’t work for both.
Can anyone help me figure this out:
--- Someone wrote that addEventListener () is the preferred. And that direct assignment was not. Is that true?
--- Should direct assignment still work for both events?
--- Should addEventListener () work for both?
--- Am I missing something else that I should know?
I mean the code I have works fine. It’s just inconsistent, and that always seems to indicate I’ve screwed up somewhere.
And I guess if either way is "Supposed To" work for both events I can go back and search for typos. But it would help to know which way is preferred, if either. Or I'm missing something important.
Thank you.
You have it backwards in your second block. When you're assigning to the window property, the name is on<eventname>; when you're using addEventListener() you just use <eventname>. So it should be:
window.onresize = function() {
alert("Hi from resize");
};
window.addEventListener("load", function() {
alert("Hi from resize");
});
addEventListener is preferred these days for a few reasons:
You can have multiple listeners, which all execute when the event occurs. When you assign to a property, it replaces the previous value. If you want to remove an event listener, you can use removeEventListener selectively (this requires binding to a named function, because you need to pass the same function when removing).
It can be used with custom events defined by the application; onXXX properties can only be used with standard events.
addEventListener is preferred because if you assign you will override any other event that has been assigned to that event.
the event for onload when using addEventListener is just "load"
I want to add and event listener, I want the function the event listener calls to be bound to the calling scope and I want to be able to remove the listener at some arbitrary date in the future.
The obvious thing doesn't work:
function Thing(){
this.thingINeed = "important!"
}
// the function that does the thing.
Thing.prototype.handlerFunction = function(e){
console.log(this.thingINeed)
e.preventDefault;
}
// do the binding.
window.document.body.addEventListener('click', this.handlerFunction.bind());
// sometime later...this is my best guess. The event listener remains active.
window.removeEventListener('click', this.handlerFunction.bind());
// this also doesn't work:
window.removeEventListener('click', this.handlerFunction);
So I flogged together some code that does work:
function Thing(){
this.thingINeed = "important!"
}
Thing.prototype.handlerFunction = function(e){
console.log(this.thingINeed);
e.preventDefault;
}
// Where the 'magic' happens...
this.boundHandlerFunction = this.handlerFunction.bind(this);
window.document.body.addEventListener('click', this.boundHandlerFunction);
// sometime later...
window.removeEventListener('click', this.boundHandlerFunction);
MDN goes into some detail on matching event listeners with removal, but it doesn't mention .bind() and I can't find any examples of other people doing it this way. The code isn't exactly obvious without extensive commenting.
Is there a better way?
jQuery event listeners can be named, which makes them really easy to remove, but that isn't possible with vanilla?
Thanks.
The issue boils down to - Function.prototype.bind returns a new function. It works when you set the bound function to a variable and use it in both addEventListener and removeEventListener because both are referencing the same function. The first block of code does not work because they are referencing different functions. Here is a contrived example:
function foo () {}
// does not work because foo.bind() returns a new function each time
// these functions are not the same object
document.addEventListener('click', foo.bind())
document.removeEventListener('click', foo.bind())
//does work because both reference the same function
var boundFoo = foo.bind()
document.addEventListener('click', boundFoo)
document.removeEventListener('click', boundFoo)
I can't speak much to how jQuery handles events under the hood, but there is no getting around this behavior in vanilla JS.
Well, when I learned JavaScript, all the books and Internet articles I read showed code passing a parameter e to functions that handle JavaScript events, such as the code block below:
function myEvent(e) {
var evtType = e.type
alert(evtType)
// displays click, or whatever the event type was
}
I've always accepted that as being the way it is, but now I have some questions (this is very confusing to me):
Where does this e come from? When I look at the entire JavaScript file, e does not seem to exist at all.
Why pass this parameter e to functions? Will functions stop working if I do not pass e to them?
Consider the code block below. There is an event variable (e) passed to an anonymous inner function. Let's say I want to use an event object outside of the anonymous function (maybe in a line above/below the element.onkeypress line). How can I do this?
element.onkeypress = function(e) {
if(e.keyCode) {
element.keyCode = e.keyCode;
} else {
element.keyCode = e.charCode;
}
};
The e is short for event
The simplest way to create an event is to click somewhere on the page.
When you click, a click event is triggered. This event is actually an object containing information about the action that just happened. In this example's case, the event would have info such as the coordinates of the click (event.screenX for example), the element on which you clicked (event.target), and much more.
Now, events happen all the time, however you are not interested in all the events that happen. When you are interested in some event however, it's when you add an event listener to the element you know will create events[1]. For example you are interested in knowing when the user clicks on a 'Subscribe' button and you want to do something when this event happens.
In order to do something about this event you bind an event handler to the button you are interested in. The way to bind the handler to the element is by doing element.addEventListener(eventName, handler).
eventName is a string and it's the name of the event you are interested in, in this case that would be 'click' (for the "click" event).
The handler is simply a function which does something (it's executed) when the event happens. The handler function, by default, when executed is passed the event object (that was created when the event/action you are interested in happened) as an argument.
Defining the event as a parameter of your handler function is optional but, sometimes (most times), it is useful for the handler function to know about the event that happened. When you do define it this is the e you see in the functions like the ones you mentioned. Remember, the event is just a regular javascript object, with lots of properties on it.
Hope that helped.
For more info read Creating and Triggering Events
As for your 3rd question, now you should know you cannot do that, because e only exists when an event happens. You could have the handler function, which has access to the e object when it gets executed, to store it in some global variable and work on that.
[1] That is not exactly correct, but it's simpler to understand. The more correct thing to say there is "add an event listener to the element you know will have events flow through it". See this for more information
The parameter e that you are asking about is an Event object, and it
represents the event being fired which caused your function to be executed. It doesnt really have to be e, you can name it anything you want just like all other function parameters.
Where does this e come from? When I look at the entire javascript file, e
does not seem to exist at all.
You won't be able to find this e variable in your javascript file because
it's really not there at all, but comes from the javascript engine executing
your callback function.
When you give a callback function for some event
(e.g. element.onkeypress = function(e) { ... }), you are giving the
javascript engine a function to execute/call when that event fires, and when
it executes/calls your callback function it passes along an Event object
representing the event that just happened. Javascript could be doing something
like this to call your callback function:
var e = new Event();
callbackFunction(e);
and that's where the Event object e comes from.
Why pass this parameter e to functions? Will the function stop working if
I do not pass e to it?
The function will not stop working if you don't have the e parameter in it.
But if you need to access some details about the event that caused your
function to be executed, you are going to need the e parameter to get them.
Consider the code block below, there is an event variable(e) passed to an
anonymous inner function. Lets say I want to use event object outside of the
anonymous function(maybe in a line above/below the element.onkeypress line),
how can I do this?
I dont think you can do this, even if you store it in a variable outside the
scope of your callback function. This is because your function is not executed
right away when you declare it, but instead only when the event is fired
(e.g. a key is pressed, firing the 'keypress' event).
var event;
element.onkeypress = function(e) {
event = e;
...
};
console.log(event); // => undefined
The only way this could work is when the code that uses the event variable
also gets executed later, specifically after the anonymous function given to
onkeypress gets executed. So the code below could work:
var event;
element.onkeypress = function(e) {
event = e;
...
};
setTimeout(function() {
console.log(event); // => the event object, if the `keypress` event
// fired before `setTimeout` calls this function
}, 100000); // <= set to very large value so that it gets run way way later
I will try my best to explain in the most abstract way possible. The real implementation is probably a lot more complex. Therefore, the names that I am about to use are hypothetical but they do serve a good purpose for explaining things, I hope ;)
Every node in the browser is an implementation of EventEmitter class. This class maintains an object events that contains key:value pairs of eventType (the key) : an Array containing listener functions (the value).
The two functions defined in the EventEmitter class are addEventListener and fire.
class EventEmitter {
constructor(id) {
this.events = {};
this.id = id;
}
addEventListener(eventType, listener) {
if (!this.events[eventType]) {
this.events[eventType] = [];
}
this.events[eventType].push(listener);
}
fire(eventType, eventProperties) {
if (this.events[eventType]) {
this.events[eventType].forEach(listener => listener(eventProperties));
}
}
}
addEventListener is used by the programmer to register their desired listener functions to be fired upon the execution of their desired eventType.
Note that for each distinct eventType, there is a distinct array. This array can hold multiple listener functions for the same eventType.
fire is invoked by the browser in response to user interactions. The browser knows what kind of interaction has been performed and on what node it has been performed. It uses that knowledge to invoke fire on the appropriate node with the appropriate parameters which are eventType and eventProperties.
fire loops through the array associated with the specific eventType. Going through the array, it invokes every listener function inside the array while passing eventProperties to it.
This is how the listener functions, registered only with the particular eventType, are invoked once fire is called.
Following is a demonstration. There are 3 Actors in this demonstration. Programmer, Browser and the User.
let button = document.getElementById("myButton"); // Done by the Programmer
let button = new EventEmitter("myButton"); // Done by the Browser somewhere in the background.
button.addEventListener("click", () =>
console.log("This is one of the listeners for the click event. But it DOES NOT need the event details.")
); // Done By the Programmer
button.addEventListener("click", e => {
console.log(
"This is another listener for the click event! However this DOES need the event details."
);
console.log(e);
}); // Done By the Programmer
//User clicks the button
button.fire("click", {
type: "click",
clientX: 47,
clientY: 18,
bubbles: true,
manyOthers: "etc"
}); // Done By the Browser in the background
After the user clicks on button, Browser invokes fire on button passing "click" as an eventType and the object holding eventProperties. This causes all the registered listener functions under "click" eventType to be invoked.
As you can see, the Browser ALWAYS puts eventProperties on fire. As a programmer, you may or may not use those properties in your listener functions.
Some answers that I found helpful on stackoveflow:
Where is an event registered with addEventListener stored?
Where are Javascript event handlers stored?
When a listener is added using addEventListener, the first argument passed to the function is an Event object, so it will be assigned to the e parameter (or whatever name is given to the function's first parameter).
It's just how JS works, you get event object in every event callback. It contains a lot of info about the event.
Function will not stop working if you do not pass it, it is optional. Go on and console.log the event (e) and see the event object and its properties. It will be more clear when you see what it has.
You can use it outside of that anonymous function by storing it, example:
var myEvent;
element.onkeypress = function(e) {
myEvent = e;
if(e.keyCode) {
element.keyCode = e.keyCode;
} else {
element.keyCode = e.charCode;
}
};
console.log(myEvent);
but you should know that the event object is relative only to that specific event that happened, and considering that you should decide if you really need to do that.
How do I clear out anonymous functions that are set to trigger via a jQuery document.ready() call?
For example:
<script type="text/javascript">
//some code sets a doc ready callback
$(document).ready(function ()
{
alert('ready');
});
//my attempt to prevent the callback from happening
window.onload = null;
$(document).unbind("ready");
</script>
The alert happens regardless of my attempts to circumvent it. Is there any way to do this?
You'd probably get the most appropriate answer if you described what problem you're really trying to solve.
jQuery doesn't have a publicly documented way to undo or block document.ready() handlers. If you control the code, you can use a global variable and a conditional like this:
var skipReady = false;
$(document).ready(function ()
{
if (!skipReady) {
alert('ready');
}
});
// skip the document.ready code, if it hasn't already fired
skipReady = true;
Or, if you want to hack into jQuery a bit (beyond the documented interfaces), you can do this:
$(document).ready(function() {
alert("ready");
});
// stop the ready handler
$.isReady = true;
You can see this last one work here: http://jsfiddle.net/jfriend00/ZjH2k/. This works because jQuery uses the property: $.isReady to keep track of whether it has already fired the ready handlers or not. Setting it to true makes it think it has already fired them so it won't every do it again.
This works:
$(document).bind("ready", function () { alert("hey!"); });
$(document).unbind("ready");
Seems like a bug to me - all other events in jQuery are able to be unbound. Omitting this one is inconsistent.
Not a direct answer as to the omission, but here's some related info from jQuery docs:
All three of the following syntaxes are equivalent:
$(document).ready(handler)
$().ready(handler) (this is not recommended)
$(handler)
There is also $(document).bind("ready", handler). This behaves similarly to the ready method but with one exception: If the ready event has already fired and you try to .bind("ready") the bound handler will not be executed. Ready handlers bound this way are executed after any bound by the other three methods above.
$(document).ready() is dependent on the onLoad event which is triggered by the browser meaning you can not prevent it from happening. If the alert() is determined by some condition then I would use an if/else statement to decide whether it is called.
Super old question, but came across the need to do this recently to prevent document.ready code I didn't control from running in certain instances. This can be achieved by proxying jQuery's ready function, rather like a test spy. The following will work:
var ready = $.prototype.ready;
// proxy the ready function
$.prototype.ready = function ( fn, allowed ) {
allowed = allowed || false;
if ( allowed ) {
ready.call( this, fn );
}
};
All calls to $( document ).ready will now be ignored. You can override this behaviour by passing true as the second argument: $( document ).ready( fn, true )
I have a Javascript module the following Javascript:
EntryController = function$entry(args) {
MainView();
$('#target').click(function() {
alert('Handler called!');
});
}
MainView() has a callback that creates the #target button. Because of the callback the code will pick up and run through the rest of the code $('#target') ... before #target is created. If this is the case the event is never hooked up to the #target. If I put a breakpoint at $('#target') that'll give the callback enough time to return and build the #target, when I press play everything works as expected.
What's the best way to deal with this? I would like all events to take place in the controller so it can choose which view to send it to.
I was thinking about placing the entire $('#target').click ... inside MainView() and instead of alert('Handler called!'); I'd put a references to EntryController.TargetEventRaise(), but that started to look a bit like steady code. What's the best way to approach this?
You're looking for jQuery's live event handlers, which will handle an event on every element that matches the selector, no matter when the element was created.
For example:
$('#target').live('click', function() {
alert('Handler called!');
});
Alternatively, you could make the MainView function itself take a callback, and add the handler in the callback. You could then call the callback in MainView inside of its callback.