1

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 a Custom 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?"

4
  • 1
    I may not have time for an answer. But, maybe start with considering why you want "separate, self contained, importable components" to begin with. How does component-izing some stuff on a page make your team's job easier? – svidgen Mar 9 '20 at 18:23
  • Thanks, @svidgen. I am building a Content Development Environment so, in a wider context, a component here represents a user-generated "plug-in" which may (or may not) be reused on different pages by the same site, or by other sites. The most immediately apparent benefits of such component-ization are plug-and-play reuse across different documents, sites & web-apps and component-level scoping, such that an individual developer might work on a given component without needing to know anything else about the overarching site(s) the component will be "plugging into". – Rounin Mar 9 '20 at 18:38
  • 1
    A good place to start your guidelines, IMO, is just be to restate that as guidelines. Maybe, "If what you're developing may be re-used or benefit from it's own scoping, component-ize it." ... Bear in mind, it still requires experience to recognize when things are likely reusable, benefit from internal scoping, or whatever other guiding quality you come up with. Maybe also consider what the with problems with "over-componentization" are and state as counterbalancing guidance. – svidgen Mar 10 '20 at 16:30
  • Yes, you are absolutely correct, I am seeking to avoid over-componentizing my setup. This is the main thrust of my question above: while I know I can turn every last nut and bolt into a component, I feel this is going overboard and I want to establish if there are any rules of thumb I can refer to, to help me decide when to turn something into a component and when not to. – Rounin Mar 10 '20 at 17:28
0

The best approach to thinking about this I have come up with is to ask the following two questions:

1) Does the UI Element represent an enhancement to the document? (ie. would the document remain functional and convey a sense of "being complete" even without the component?)

2) Even where the UI Element is a core part of the document (and not an enhancement), is the component, nevertheless, editorially highly dynamic, displaying different (sometimes substantially different) content from one document to the next? (Like a section-specific contextual menu etc.)

Where either condition above is TRUE, it is probably a better architectural decision to write the UI Element as an importable component.

I recognise that this isn't perfect, but it's the best I have been able to come up with so far.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.