Quiz

1. Why is adding click handlers not at top-level a subpar practice?

   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.

   
       function updatePage() { const zodiac = ...; }
       $("#myButton").click(updatePage);
   
       // versus
   
       function updatePage() {
          const zodiac = ...;
          $("#myButton").click(updatePage);
       }
   
   

2. Can you talk more about event.target?

   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.

3. Could you explain what this if statement if (order.flavor) means? I don't quite understand this condition: if (order.flavor) { description += order.flavor + ' '; }

   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...)

4. in the example "Check here if you like cats" with the <input type="checkbox" value="likes_cats">, would you be able to save the input that the user likes cats if you wanted to then use that information later?

   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:

   • The purpose of this example is to explain the CoffeeRun checkboxes, which also don't have 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.)
   • We could determine whether the checkbox has been checked or not. There is a .checked boolean property that we could look at, after getting the checkbox via some kind of selection/find operation.
   • But if this input were part of a form that would be submitted or processed, we would almost certainly add a name attribute.

   Honestly, I never noticed that before, so your question helped me learn something!

5. No particular questions at this time. / No questions! / Currently no, thanks