N.B. Several months after initially asking this question (and not coming up with any satisfactory answers) I am now learning to use HTML Custom Elements / WebComponents. It seems the same question comes up again:
I know I can turn everything in my HTML into a
Custom Element... so what do / what don't I turn into aCustom Element?
This is a question about best practice in data architecture when it comes to component-based systems. There are a number of "component" technologies in vanilla javascript, not least:
- Web Workers
- ES6 Modules
- Optional External JS files
Self-evidently, whenever a document can be architected as a single block or built up dynamically from separate components, there is a spectrum of architecture possibilities, ranging from:
- The single document imports no components
- The single dynamic document imports some components
- The single dynamic document imports many components
- Every part of the dynamic document is an imported component
Most system architectures will represent a position somewhere between the two poles.
But is there a sensible rule of thumb or principle which can help an information architect decide whether something should be a separate, self-contained, importable component or not?
How might I decide sensibly what UI elements ought (and ought not) be written as components to import?
What indicators suggest that a UI element ought to be written as a separate, importable component?
Example:
<h1>My Weather Page</h1>
<nav>Navigation Here</nav>
<p>Introductory Paragraph Here</p>
<!-- Dynamic Weather Module Here -->
<p>Paragraph explaining how to navigate / use the weather module</p>
<footer>Footer Links and Notices Here</footer>
Given the page architecture above, I would be most inclined to nominate the following two as components (handled by Web Workers, ES6 Modules etc.) to be imported into the page template:
<nav>Navigation Here</nav><!-- Dynamic Weather Module Here -->
and the following four as non-imported sections of the page-template:
<h1>My Weather Page</h1><p>Introductory Paragraph Here</p><p>Paragraph explaining how to navigate / use the weather module</p><footer>Footer Links and Notices Here</footer>
But that feels to me like an arbitrary decision. I can imagine others proposing that any of the sections immediately above (especially the <footer> if it were, to some degree, a custom, dynamic <footer>) might feasibly be written as separate components imported into the page template, too.
Eventually, I'm left scratching my head and wondering if there is anything on the page which shouldn't be a component. That said, turning everything into a component feels like going completely overboard.
Clearly the degree of componentization is a choice ultimately made by each architect...
... but are there any sensible guidelines / rules of thumb etc. which can help an information architect decide what ought to be an imported component and what ought not to be an imported component in an architecture which allows for componentization?
I can think of the following example questions:
- Does the section appear on every page? If not, probably make it an importable component.
- Is the section dynamic and does it appear differently on every page? If so, probably make it an importable component.
I imagine there will be other questions similar to those above, the collected answers to which may assist in deciding whether to turn a piece of code into a separate, importable component or to leave it as a non-imported section within the main template.
Added:
Having thought about this on and off for 5 days and finding myself unable to imagine a UI element for which there could not be at least a halfway-reasonable argument to turn it into an importable component, I am starting to wonder if the question isn't better, reversed:
"What guiding indicators suggest that a UI element ought not be written as a separate, self-contained, importable component?"
