There are currently no frequently asked questions associated with this exercise – that’s where you come in! You can contribute to this section by offering your own questions, answers, or clarifications on this exercise. Ask or answer a question by clicking reply () below.
If you’ve had an “aha” moment about the concepts, formatting, syntax, or anything else with this exercise, consider sharing those insights! Teaching others and answering their questions is one of the best ways to learn and stay sharp.
Join the Discussion. Help a fellow learner on their journey.
Ask or answer a question about this exercise by clicking reply () below!
Agree with a comment or answer? Like () to up-vote the contribution!
It has to do with your placement of the event listener. It should not be inside the handler function.
function handler() {
//
}
element.onclick = handler;
handler in this case would be your function, by reference only. This is known as a callback. That should get you through the lesson.
Something of note, though not a key to this lesson is that the handler is scoped to the event object (element) and as a declared function inherits that context so has a this object.
Why the function call after element.onclick = does not need the () as in element.onclick = turnButtonRed(); why does this not work properly? and why do we write the function after the onclick without the ().?
We are registering the event and giving it a callback that will be invoked on the event object, when the node is clicked. What we pass to the listener is just a reference to the function, not the invocation of that function. It is up to the handler to invoke this when that time comes.
Last line (line 9) element.onclick = turnButtonRed;
I thought it must be element.onclick = turnButtonRed();
since it was a function declaration in the lines before that (and not a function expression, i.e turnButtonRed is not a variable name)
or am I forgetting something?
oh now that I’ve seen @mtf 's response…I’m still wrapping my head around it but thank you all
Can someone please tell me the difference between
element.onclick = function turnButtonRed (){
element.style.backgroundColor = ‘red’;
element.style.color = ‘white’;
element.innerHTML = “Red Button”;
}
which seemed to work based on the tasked given and this
function turnButtonRed (){
element.style.backgroundColor = ‘red’;
element.style.color = ‘white’;
element.innerHTML = “Red Button”;
}
element.onclick = turnButtonRed;
In both cases, the first worked but didn’t pass while the second worked and passed. What’s the misconception?
The turnButtonRed function is given as a callback, which references the physical function but does not invoke it. The function is invoked (triggered) by the event listener when a click event is detected.
Both forms are valid and work as expected, but the latter is more manageable since the listener doesn’t need to be maintained if the handler function is modified. It is the more typical usage we encounter in production code.
Were it the case of using ES5, your proposed approach would be alright, but in the manner of ES6 and arrow functions, we lose this as the execution context of the callback function. I’ll have to check, but was the onclick global event around in ES5?
Since we are using a global event, that would mean there is a global event object, so, for browsers that support this, we can access that, globally, without a parameter.
I agree with your statement, though I have found that more tightly scoped code to be more readable, and therefore I prefer having older style function to arrow functions. I feel it also helps in scanning large blocks of code and discerning what objects are which.
I would also think that using the more classic .addEventListener() solves my issue with the implicit event object, though this comes later in the lesson.
ES6 is more expressive/declarative. It doesn’t haunt any scope but fits the realm it is inserted into. That would be my take.
Events all bubble to the top of scope. That’s what I believe this new train of thought is leading to. Bring events to the most optimal point to pick up on. Then delegate and handle.
more expressive, in terms of clarity of intent than
const foo = () => {}
Perhaps philosophical. To each their own. And, in terms of hoisting, it leads to more flexibility to programming styles. If you like to stack your declarations at the bottom of your scope, you can.