It feels like I'm facing the same thing the same problems writing the API of these components. In particular:
- A component might have several distinct modes. As in, an
<x-gif speed="1.0">
has a very different playback mode from<x-gif bpm="120">
, so you shouldn't be allowed to have bothspeed
andbpm
. But it doesn't seem right to break them into separate components, so either one takes precedence or having both present causes an explosion. - A component might require more than one attribute to be valid. As in,
<x-beat midi channel="0" note="65">
. Until you have both thechannel
andnote
you can't make connection to the midi signal. But if you're driving the component with a framework like angular, it will first render incompletely (as<x-beat midi channel="{{ channel }}" note="{{ note }}">
), then after a$digest
will insert the right values. So a component may need to permit being in an invalid state temporarily, then when all attributes are set go and get set up.
The first bit feels like command-line options-parsing, but the second one is trickier. You have this stateful lifecycle of these components and tracking all the potential changes is really hard. Thoughts?
Feels like we need a declarative way of describing a component API that understands the different kinds of attributes, to reduce some of this complexity. Unless... some work like this has already been done. Like within x-tag or something?
Newbie at this stuff, and googling-as-I-go. If any of the following is impossible and/or dumb. I'd love to learn why. :)
With speed vs bpm, I'd give precedence to whichever value makes your code cleaner further down the line and document that it overrides the other. In a perfect world, I'd use pattern matching. But I don't know of any good pattern matching libraries for JavaScript or dealing with custom HTML tags.
If you don't want an 80s Hollywood representation of computer sounds, you will need to to wait until every tag is populated before any of them can be processed. Otherwise, delayed or out-of-order population of any elements will totally screw with the output. So the components will definitely be in an invalid state at some stage. Can something like MutationObservers help here? https://dvcs.w3.org/hg/domcore/raw-file/tip/Overview.html#mutation-observers