(Web/View) Components: Should everything be a component?

Recently I was reviewing a merge request of some front-end code, and a simple div, that changed a bit of the custom appearance of a block of text through a few custom classes, was changed in a call to a view component that then applied the same classes, passed onto the component through a more deeply nested hash.

> -
> + ’itis ](https://en.wiktionary.org/wiki/divitis) you get ‘TextComponent’-itis.. we don’t add better semantic or structural information to the page layout

Instead?

Keep the code as is. And perhaps create a ticket (or annotate it with TODO:) that you perhaps want to extract this ‘custom-class’ call into a true reusable component. While I don’t think there is something inherently bad with offering the option to override or add some custom classes to a component, a component should only be used if it adds structural meaning either from the developer's side of things or (better) from the consumer’s side of things (e.g. semantic output that can be p…

Design Systems and the source of truth

Some excerpts I created from the transcript of the Design System Podcast, hosted by Chris Strahl, which in Episode 11 featured Brad Frost and Evan Lovely.

Hand-over of comps

The traditional process starts with the design of comps, comps, non-interactive previews, which are generated by the design team and undergo a rigid design review process up to a design director or VP, and is only then passed on to the developers who need to implement that initially static comp pixel perfect. But Evan Lovely notes that while there is nothing wrong with comps, there is something wrong with mistaking it for the final product. That’s why he likes tools like pattern lab, storybook or knapsack, because they really allow someone to quickly mock up a comp that actually works within the final environment.

To some companies this is a problem; because the formal approva…

Highlights from the Atomic Design book by Brad Frost

Since his talk at Fronteers I was interested in the thinking of Brad Frost, his blog posts, etc., but never actually read his book Atomic design until recently, as it got more and more relevant to an internal discussion at an organization I was working for. A few notes:

• Most importantly, what it is not: Atomic Design is not about being a practical guide for implementing design systems (although it has some examples in Pattern Lab, which was originally built by him). I was also hoping it would also give guidance on naming things / structuring CSS when building atomic design based design systems, but it does not. But don’t mind, plenty of good content(!)
• Atomic design sounds like an too obvious idea and while I didn’t dismiss it because of that, I realized I also didn’t try to understand it thoroughly enough. Reading the book helped me to better understand it and especially thinking about the intermediate forms (molecules) was actually despite its o…