Where do you hear that? I don't recall ever saying it.
I do find that students get confused about adding a click handler and handling a click. If you add the click handler at top-level, rather than within a function, the confusion is less likely, because the click handler is necessarily a function.
For sure! The event.target is the DOM element that
dispatched or "started" the event. To be concrete, it's the thing you
clicked on.
But events also bubble up, so if I click on an LI, I have also
clicked on the UL that contains it (and the DIV that contains the UL
and so forth). Event handlers attached to the UL or the DIV can find
out which LI was clicked on by looking at event.target.
In the context of CoffeeRun, it's the checkbox that we clicked on.
Glad to; because that's not obvious. Let's look at coffeerun.
The flavor shot is a dropdown menu
(select), with a default (user) value of "None" but the
internal value is the empty string.
In JS, the empty string counts as false, so the if (order.flavor) is equivalent to if (order.flavor != '') .
So that code adds the flavor to the description if it's not the empty string.
(I suppose we could skip the conditional and just add the empty string...)
What an interesting question! In our previous work on form inputs,
I emphasized that they all need to have name attributes,
because the form submission (whether to a back-end server or to
front-end processing) consists of name-value pairs. And this
input doesn't have a name!
So, you're right to ask about this. Some responses:
name
attributes, because CoffeeRun doesn't care. The only
purpose of those checkboxes is to allow pending orders to
be removed when they are fulfilled. (Indeed, there's no
surrounding form element, so there's no form
to submit or serialize.)
.checked boolean
property that we could look at, after getting the checkbox via
some kind of selection/find operation.
name attribute.
Honestly, I never noticed that before, so your question helped me learn something!