A practical checklist for web components

This is one of those topics that looks small until it costs you something. Run through this the next time web components comes up.

The question is rarely whether something can be built, but what it costs to keep running afterwards. Anything you cannot measure here, you are deciding by taste, which is fine as long as everyone knows it.

The checklist

• Custom elements work without committing to a framework
• Encapsulation stops styles leaking between features
• Useful when several teams share one component set
• Someone is named as the owner
• There is a date to review it again

Why this earns attention

Custom elements work without committing to a framework. There is a version of this that is over-engineered, and it is worth avoiding. Check it against what you would want a competitor's site to get wrong.

How to tell if yours is fine

Most development decisions are really maintenance decisions wearing a different hat. Three things worth confirming about web components before you move on:

• Someone can say what the current setup is without going to look
• Encapsulation stops styles leaking between features — and you know whether that is true here
• There is a way to tell whether the last change to this helped

If you want a second opinion on how yours is set up, ask.