Web Component design thoughts

gistfile1.md

Web Component design thoughts

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 both speed and bpm. 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 the channel and note 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?

hiii~

So the way I've done it before is, each time some attribute "that changes everything" changes its value, I just call the internal init function again to make sure everything is in order.

This is slightly inefficient if you change some attributes that trigger this init function several times, and it's also prone to infinite loops if you're not careful with what triggers what--sometimes you might want to change the internal value and not via the attribute so that the changed event does not trigger a full update event, if you know what I mean.

Also, I always try to make sure the elements start in a consistent initial state. That means giving their attributes sensible values to start with and calling init immediately after that.

Maybe there are better ways of doing this. I'm totally open to improving this workflow!

Re: attribute precedence. Pick one and use it? It might feel weird to be specifying two opposite things in a custom element but imagine something like this:

<p style="color: green;" class="red">aaaah</p>