Atoms, Molecules, Patterns

I’ve just had a rather interesting dive into the world of components. At Coko we are breaking down the PubSweet components, essentially browser views, into smaller ‘sub-components’. So we looked at the language, best practices, and tools in this arena.

The outcomes are pretty simple but also interesting. We decided to use React-Styleguidist for the management of these sub-components.

But the discussion around what should constitute a component/pattern is in itself interesting. There is some interesting theory around it, probably the most compelling document I found was the Atomic Design article/thesis by Brad Frost. It is a compelling language / framework for understanding and discussing the creation and use of reusable components.

There are two questions that seem fundamental to a sub-components (patterns) approach:

1. at what level do you describe something as a (singular) ‘component’?
2. when should something become a component?

The first is very much the topic of the Atomic Design book linked to above. Brad Frost uses the metaphor of chemistry to describe the basic component types, the first being an atom. An atom is the most basic element that you will find on a web interface (his language is very much built around web interfaces and HTML elements).

atoms include basic HTML elements like form labels, inputs, buttons, and others that can’t be broken down any further without ceasing to be functional.

So, a button could be a component, and if so it would be the most basic type – an atom. That makes intuitive sense to me and its an interesting way to talk about things. We all know atoms are the most basic form of matter, so using the term to describe the most fundamental form of UI element is an easy translation. It is also a nice language to adopt because in the world of atomic theory atoms exist in isolation but they also exist in clusters and there is a language for that too. Two or more atoms that exist together form a molecule.

molecules are relatively simple groups of UI elements functioning together as a unit. For example, a form label, search input, and button can join together to create a search form molecule.

That also translates pretty easily. There are other layers after this. The ‘next layer up’ (so to speak) Brad Frost calls an ‘organism’:

Organisms are relatively complex UI components composed of groups of molecules and/or atoms and/or other organisms. These organisms form distinct sections of an interface.

I can almost buy the ‘organism’ terminology but not quite. I would prefer something like ‘compound’. This makes more intuitive sense to me. As the Free Dictionary states:

Consisting of two or more substances, ingredients, elements, or parts.

So, I would prefer – Atoms, Molecules, and Compounds. I’m not going to nit pick Brad Frosts essays, it’s a brilliant piece of work. I guess I’m just pondering about the consistency and intuitiveness of his chosen lexicon. Atoms and molecules work for me, compound feels easier than organism…anyways, I got into the weeds,

The point is, each of these is a component but this gives us the language to talk about different types of components – which is very important.

Incidentally, Brad Frost defines two more layers – Templates, and Pages. I’m still pondering these. I’m, for now, mostly interested in atoms, molecules and organisms/compounds.

So, this is nice. I felt this framework made immediate sense when I first came across the idea (recommended by Paul Shannon from eLife) and, further, I felt the stress disappear caused by the struggle of talking about ‘different types of components’ without being able to name them.

Which leads me to the second question I asked above – when does something become a component. In other words, when do you spend the time to make the component a component, whether it would be an atom, molecule or compound component. For this, I am very grateful for an insightful and brief chat I had with Brian Muenzenmeyer who maintains the node version of PatternLab (Brad Frost is also part of the PatternLab team).

Brian made this very nice point:

I recall a friend explaining to me to start worrying about making something a pattern at all only after you use it three times. First time, it’s a one off. second time, you have a convenient template to copy/paste from. third time, it becomes a maintainability issue

It is a very salient point as it also points out, implicitly, that patterns are emergent and it doesn’t pay to be over zealous when breaking something down into an individual component/pattern. I think that is smart. Having said that, we possibly occupy a smaller % of software spectrum where re-use is more fundamental to our work than, say, someone building a company website. This is because we are building for reuse. Coko produces systems so that others can inherent or build their own publishing platforms. So, to support the later (build your own publishing platform) I think it is important for us to build reusable components from the get go to make it easier for developers to roll their own platform ie. we should create reusable components whenever possible as a matter of course.

Lastly, while PatternLab has Brad Frost’s logic built into it, there is no need to use PatternLab to make atoms, molecules and compound ‘stores’ for components. These can be established in the naming and categorization by convention in other tools eg React-Stylguidist (our choice of tool). This is not to say PatternLab is a bad tool, it is a great tool, but if you subscribe to Brad Frost’s ideas, or some version of them, you don’t need PattenLab to achieve this. You can choose the tool you want based on other requirements.

Anyways…that is my thinking on it so far. Pretty interesting topic. I am grateful for the language and clarity that Brad Frost provides and a few sage words on when to think about making something into a component from Brian Muenzenmeyer. Still pondering all this. It’s a very interesting area.