There are two problems with this:
- If I have another type of expander button somewhere else that needs to do something different (e.g. maybe somewhere I need to ajax content in first), then I need to clutter the code with more stuff in order to allows the different buttons to do different things
- I have no indication of what said button does by inspecting it w/ Firebug/dev tools, let alone by just looking at it. I have to slog through the code to figure out what code might get attached to this element
Stepping back for a moment
As it turns out, there's a third, minor issue: the href attribute of the element doesn't serve any purpose. It doesn't even tell the user where clicking on the element might go. It's just a clunky way of telling the browser to not do its default action when you click on the element. It's a code smell that can be refactored to something like the this:
As it also turns out, browsers as old as IE8 support document.querySelectorAll, so finding elements by href nowadays is not particularly slower than searching by class name. So why not repurpose that useless href back to identifying what a user should expect when clicking on the element?
There are many ways of returning undefined, the shortest of which is to simply... do nothing.
And we can target that via jQuery:
We can attach different behaviors to different ".expander" elements simply by using a different href: