Uswds: Implement interactive components as HTML custom elements

[shawnbot]

This is a fork of #1423 to address the specific question of whether we should refactor our interactive (JavaScript-driven) components as custom elements. The scope of that issue is being narrowed to focus on event delegation.

The current component + initializer setup is kind of a pain to maintain, and has a pretty significant flaw: if you add a new component to the DOM (or remove one from it) at runtime, it won't work unless you call the initializer(s) again—which will, in turn, add duplicate event listeners to the previously initialized elements. I have some suggestions for how to improve this situation:

Custom elements encapsulate behaviors at the element level, so they don't require separate "initializer" code: each one gets initialized independently when it's created, attached to the document, and can be acted upon when detached (for instance, to have event listeners removed automatically).

[shawnbot]

cc @joshbruce for visibility

[joshbruce]

Thanks @shawnbot - gonna tag some of the crew. They might have some thoughts and lessons learned. Wish we could make our code more open - getting there - just taking a moment.

[toolness]

I really like this idea--we used custom elements extensively in CALC for precisely this benefit. The one trade-off is that if you need different kinds of custom elements to work together, it can be a bit of a chore, because you have to account for race conditions in custom element upgrading.

I think this could also help make our code a bit more understandable, too. At least by people who already understand how custom elements work, I suppose.

[timwis]

We're passively thinking about this in Philly (standards.phila.gov) and would be happy to partake in brainstorming and prototyping!

[thisisdano]

Thanks for contributing to USWDS. Unfortunately, this issue is not on our current product roadmap.