(Event) Delegation, Separation (of Concerns)

delegation-separation.md

(Event) Delegation, Separation (of Concerns)

Event delegation is awesome. And that seems to be the concensus amongst the JavaScript community. Use it. Love it.

But what is the best way to use it? How do we identify (HINT HINT) which elements should have event handlers, and which elements we should be looking for when those event handlers are triggered? Here's my usual approach:

var elem = document.getElementById('parent');

elem.addEventListener('click', function(e) {
    switch (e.target.className)
    {
        case 'close':
            // do stuff
            break;
        case 'open':
            // do other stuff
            break;
        case 'something-else':
            // do other stuff
            break;
    }
});

Simple, and effective. It's certainly Good Enough, but I think there's some Bad to it as well? I've been thinking, lately, that it's not the best way to separate my concerns. There is more to worry about than just functionality. There's semantics and CSS as well, and all of the best practices that encompass and take advantage of those concepts.

Let's take a deeper look at the above approach.

Classes are for CSS

Checking e.target.className causes a problem. Ideally, we're using IDs for JavaScript, and classes for CSS. This, of course, has been up for debate for a while, and there's been a lot of push back about keeping IDs out of CSS.

I think, though, that it's correct in concept at the very least, mostly due to the fact that IDs are simply the fastest way for JavaScript to access an eleemnt, and changing an ID for the sake of JavaScript (or CSS) shouldn't affect the other (not to mention other reasons). Using classes in your JavaScript (for non-presentational reasons) causes a similar issue; changing, adding, and removing classes can break the display of an element, and changing the display of an element can cause functional (JavaScript) bugs. Exactly the kind of tight coupling we'd like to avoid.

Semantics

Semantic class names are useful. They tell you what an element represents, and thus how to think about that element. Often, I'll determine my HTML structure and class names before I ever touch a line of CSS. This forces me to think about what my elements are, rather than how they look.

But what does that mean for how they function?

This is an interesting question to me. I'm not sure I know the answer, and I'm not sure I know how it interacts with the separation of concerns listed above. But my thoughts on the subject go as follows:

On one level, I think what an element is has a lot to do with how it functions.

Here is where my brain broke

Data Attributes

Possible solution!