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?
Should these components explode, as you say?? The tradition of HTML and the DOM is all about failing gracefully.
In the mutual exclusion case above, if
speed
andbpm
are a mutual exclusion, picking one to always 'win' seems more humane than having neither work.In the case of insufficient attributes to be valid, the tradition is to fail silently. Then, the moment all the right attributes are in place, the machine can spin to life. This will very comfortably allow for lazy initialization.
My procedure would be (and has been) something kind-of like state machine:
speed
tobpm
, or going from invalid to working and back again.I'm very inclined to avoid some meta-layer around attribute relationships.