Foundations: DOM Manipulation And Events: Emphasize the concept of Event Delegation

[ioakeimo]

Describe your suggestion

In:

Foundations: DOM Manipulation And Events
the second assignment video is in regards to event bubbling.
That inclusion is in my opinion not only necessary, but probably not adequate to highlight the importance of event delegation and/or the pitfalls of its absence.

Reason for this suggestion:

A common pattern noticeable during my efforts to offer assistance to the community through the relevant discord channels (javascript-help-1/2).
When there's a pattern, there's an issue.
I almost daily come across code implementations that end up having some sort of anonymous listener re-attachments (causing both logical errors and memory leaks).

Examples:

consider the following simplified example of a function as part of an Etch-A-Sketch project:

function calledOnColorChange() {
  for (const cell of gridCells) {
    cell.addEventListener('click', () => { 
      // draw on cell
    }
  }
}

For a a grid of 10x10, calling this function 10 times creates 1_000 anonymous eventListeners.
Furthermore, in order to also demonstrate logical errors, consider the effects of that same function when trying to implement drawing with alpha/opacity (previous event listeners will re-draw).

In a different instance, consider the following as part of the ToDoList project:

function calledOnAddNewToDo() {
  for (const todo of allTodosInProject) {
    todo.checkbox.addEventListener('click', () => { 
      // toggle ".done" class checkbox
    }
  }
}

Here one has to explain how re-attaching event listeners responsible for toggling a class/attribute (eg a checkbox) can result in it re-setting its state to its initial value, depending on if the number of attached eventListeners is even or odd. For example, for an initially checked checkbox with 2 event Listeners (2 todos created calling that function), the '.done' class state after a single click would transition:
'.done' (initial) -> ' ' -> (second listener) '.done'

Sugestion:

For me, it is clear that learners don't get the opportunity to understand and avoid such issues.
A quick search on the suggestion discord channel returned a suggestion of adding relevant additional material, which leads me to think others have maybe noticed that pattern too.

In order to understand and avoid this issue I would consider adding a new lesson (I honestly do not think a simple assignment is enough) that:

1. Demonstrates issues with re-attaching anonymous event listeners. Here, for example, is a very barebones codepen that I created in my effort to demonstrate such issues while explaining.
2. Demonstrate/Differentiate how the issue is resolved automatically (by the engine?) when the event listener becomes a named function (same codepen above includes a commented version).
3. Demonstrates (with some level of abstraction, eg maybe an image of) the memory leak pitfall. Maybe find an example that would exaggerate the memory footprint and/or cpu usage of this number of listeners on an EtchASketch with 1000+ cells.
4. Introduces the Event Delegation (through bubbling) solution. Demonstrate some key benefits (eg no need to add new listeners when adding ToDo's, the memory footprint with a single listener).
5. Forces/Requires a couple of small projects using Event Delegation.

Path

Foundations

Lesson Url

https://www.theodinproject.com/lessons/foundations-dom-manipulation-and-events

Checks

• I have thoroughly read and understand The Odin Project Contributing Guide
• Would you like to work on this issue?

(Optional) Discord Name

No response

(Optional) Additional Comments

No response

[KevinMulhern]

Thanks for the detailed write up @ioakeimo. This makes a lot of sense to me. We cover quite a bit in the dom lesson as indicated by the knowledge check links, breaking it up could improve that area of the curriculum quite a bit.

I would love to hear what @TheOdinProject/javascript members thinks about this.

[fortypercenttitanium]

I agree with this for the most part. However, we do need to be careful that we're not spoon feeding solutions to problems that we are not only allowing the learners to experience, but encouraging them to encounter.

A large part of what makes this curriculum beautiful is this struggle with problems we don't expect, or are 1-2 steps deeper than what the project is scoped to teach.

That said, this is an issue that could potentially get missed and we may do better to point it out explicitly. I do hope that the accepted solution is not to tell the learners how to get around it, but rather challenge them to figure it out by providing materials.

[wise-king-sullyman]

Yeah I agree that we could do a better job of making sure that learners understand this, and think that we should do so, but as was said above I'm not sure I would want us to just lead with "this is what you should do" in this instance.

I think it's extremely common for peoples etch-a-sketch to run into this problem as you've highlighted, but it doesn't really matter in my opinion since we suggest in the requirements to limit it to a 100x100 grid at max, and it's such an early project that it isn't likely to be a resume project regardless.

I also am generally hesitant for us to add additional content into foundations unless it is absolutely necessary at that stage, which I don't believe this is.

What would you all think about having this content instead placed somewhere early in the JavaScript course, potentially framing it as a revisit of etch-a-sketch? I think that framing would be great for a lot of people since they could look at the before and after of the revisit and see how much better the performance of their etch-a-sketch becomes as it scales after making the changes.

[github-actions[bot]]

This issue is stale because it has had no activity for the last 30 days.