Components and concerns

We tend to like false dichotomies in the world of web design and web development. I’ve noticed one recently that keeps coming up in the realm of design systems and components.

It’s about separation of concerns. The web has a long history of separating structure, presentation, and behaviour through HTML, CSS, and JavaScript. It has served us very well. If you build in that order, ensuring that something works (to some extent) before adding the next layer, the result will be robust and resilient.

But in this age of components, many people are pointing out that it makes sense to separate things according to their function. Here’s the Diana Mounter in her excellent article about design systems at Github:

Rather than separating concerns by languages (such as HTML, CSS, and JavaScript), we’re are working towards a model of separating concerns at the component level.

This echoes a point made previously in a slidedeck by Cristiano Rastelli.

Separating interfaces according to the purpose of each component makes total sense …but that doesn’t mean we have to stop separating structure, presentation, and behaviour! Why not do both?

There’s nothing in the “traditonal” separation of concerns on the web (HTML/CSS/JavaScript) that restricts it only to pages. In fact, I would say it works best when it’s applied on smaller scales.

In her article, Pattern Library First: An Approach For Managing CSS, Rachel advises starting every component with good markup:

Your starting point should always be well-structured markup.

This ensures that your content is accessible at a very basic level, but it also means you can take advantage of normal flow.

That’s basically an application of starting with the rule of least power.

In chapter 6 of Resilient Web Design, I outline the three-step process I use to build on the web:

  1. Identify core functionality.
  2. Make that functionality available using the simplest possible technology.
  3. Enhance!

That chapter is filled with examples of applying those steps at the level of an entire site or product, but it doesn’t need to end there:

We can apply the three‐step process at the scale of individual components within a page. “What is the core functionality of this component? How can I make that functionality available using the simplest possible technology? Now how can I enhance it?”

There’s another shared benefit to separating concerns when building pages and building components. In the case of pages, asking “what is the core functionality?” will help you come up with a good URL. With components, asking “what is the core functionality?” will help you come up with a good name …something that’s at the heart of a good design system. In her brilliant Design Systems book, Alla advocates asking “what is its purpose?” in order to get a good shared language for components.

My point is this:

  • Separating structure, presentation, and behaviour is a good idea.
  • Separating an interface into components is a good idea.

Those two good ideas are not in conflict. Presenting them as though they were binary choices is like saying “I used to eat Italian food, but now I drink Italian wine.” They work best when they’re done in combination.

Have you published a response to this? :

Responses

Brad Frost

“Separating interfaces according to the purpose of each component makes total sense …but that doesn’t mean we have to stop separating structure, presentation, and behaviour! Why not do both?” - @adactio adactio.com/journal/14103

# Posted by Brad Frost on Tuesday, July 10th, 2018 at 1:38pm

Max Böck

the new function-based separation of concerns in the “component age” doesn’t mean we have to mix structure, presentation and behaviour. use the best of both worlds! 👌 via @adactio adactio.com/journal/14103

# Posted by Max Böck on Tuesday, July 10th, 2018 at 3:25pm

Sara Soueidan

“There’s nothing in [..] separation of concerns on the web (HTML/CSS/JavaScript) that restricts it only to pages [..] I would say it works best when it’s applied on smaller scales.”adactio.com/journal/14103 I always thought SOC makes the most sense on a component level.

James Nash

Totally agree with @adactio on this one: Seperating by concerns and by components are NOT mutually exclusive. Quite the opposite in fact. Or, to put it another way, developing modular UI components is NOT an excuse to avoid seperating concerns.adactio.com/journal/14103

# Posted by James Nash on Tuesday, July 10th, 2018 at 9:08pm

Gerardo Rodriguez

💯 “Separating interfaces according to the purpose of each component makes total sense …but that doesn’t mean we have to stop separating structure, presentation, and behaviour! Why not do both?” adactio.com/journal/14103

Micah Cambre

It’s funny how patterns and styles get recycled. We’ve seen clothing styles of the 60’s get reintroduced and reused decades later. The TV show Mad Men brought back mid century modern style into the 2000s. And we’ve seen it happen with coding patterns as well.

React Components

One of the first React things I learned is how to create React Components, Capital-C.

export default function NavButton() { return( <button type="button">Switch Step</button> ) }

To use this button, just import it into other files and apply it in the JSX. Straightforward.

Props == HTML Attributes

Buttons usually need to do things, so let’s give this some interactivity.

function NavButton(props) { const { transitionCallback, isDisabled } = props const handleClick = () => { transitionCallback() } return( <button onClick={handleClick} disabled={isDisabled} > Switch Step </button> ) }

2000s me looked at this increasingly used React pattern curiously, because I see onClick={handleClick} attached to the button element. For so many years, often from jQuery or Javascript, I avoided applying event handlers to elements. But here React made that a pattern and my mind goes back in time.

My concerns are separate

I spent the 2000s and into the 2010s learning about, what I eventually started reading from industry folks and books, a computer science term called Separation of Concerns. The idea makes sense on the front-end for many reasons and I became fairly dogmatic about it.

With Separation of Concerns, these three concepts stand on their own:

  • structure (HTML)
  • presentation (CSS)
  • behavior (JS)

By the middle of the 2010s, I wasn’t mixing JS and CSS into HTML, CSS into JS or HTML into JS. We keep them separate, .html, .css, and .js.

By contrast and in practice, however, having worked with WordPress all that time, it was often a losing battle to decouple these languages, quick jQuery or CSS fixes were little inline sprinkles here and there.

<?php function ratio_calculator() { $html = '<style> .form-inline .form-group { display:block; margin-bottom: 10px} </style> <form id="form" name="form" method="GET" action="#" role="form" class="form-inline"> <div class="form-group"> <label for="RT3" class="t3">RT3</label> <input class="form-control" type="text" name="RT3" id="RT3"> </div> <input type="button" class="btn btn-primary" name="button" id="Submit" value="Get Ratio"> </form> <div id="ratio" style="color:blue;font-weight:bold;font-size:120%"></div>'; return $html; } add_shortcode('calculator','calculator_form');

Yuck! I had to grit my teeth and move on.

Then came modern JS frameworks, cemented by React, slowly blowing this concept up. React’s raw JSX syntax requires to cross the decoupling line by adding HTML-like attributes called props containing Javascript and often CSS. A different and controversial method called CSS-in-JS is not only accepted but widely adopted by many React developers. And then there’s the other CSS direction of using utility first libraries like Tailwinds polluting HTML classes, but don’t get me started on that concept!

Separation of Concerns Remixed

In this new paradigm of component-first development, the abstraction for separation of concerns takes on a different look. The separation of concerns is loosely defined within the components themselves. Let’s take a look at what this means.

Here’s my first iteration of the navigation button control component to go from the initial state to the timer state.

function NavButton(props) { const { transitionCallback, isDisabled } = props const handleClick = () => { transitionCallback() } return( <button style={{padding:'1rem', backgroundColor:'white'}} onClick={handleClick} disabled={isDisabled} > <span className="visuallyhidden">Switch Step</span> test </button> ) }

This code shows a clear mix of all three languages within a Javascript function, with an HTML-like syntax inside of a Javascript return statement, inline CSS in a button element, and an inline onClick event handler calling a function.

Before I started learning how to make websites, the source code of the web documents used similar syntax that kind of looked like the above.

<head> <script type="javascript"> function handleClick() { var transitionCallback = props; transitionCallback(); } </script> </head> <body> <input align="left" clear="left" bgcolor="white" type="submit" onClick="handleClick();" disabled="disabled" value="test" > </body>

When I first saw React’s syntax, you can imagine how alarmed I was by its seemingly reversion back to the 1990s styling of code. My mental model is so conditioned that this bothered me for a long time, still does to some degree.

Two what end?

As I see modern libraries continue these practices, it appears the pattern of everything inside of JS will continue into the foreseeable future, one way or another. Discussions around native Web Components in the document brings a more dogmatic potential back, but not in its current iteration.

I’m always excited for the future, but I think there will always be a part of me looking of ways to scale back the abstractions and packages needed to build the modern web. Part of that will be my outdated mental model for separation of concerns. Let’s hope browser makers can find better ways to manipulate the DOM and CSSOM without breaking the clients and mixing our concerns!

2 Likes

# Liked by Dominik Schwind on Tuesday, July 10th, 2018 at 2:09pm

# Liked by Gabor Lenard on Tuesday, July 10th, 2018 at 3:20pm

Previously on this day

3 years ago I wrote Words

When I hear the phrase “I reach for my revolver”, I reach for my red pen.

6 years ago I wrote Chloe

.

13 years ago I wrote Grab your place at dConstruct

Tickets are about to go on sale.

16 years ago I wrote Home again, home again

I’m back from the west of Ireland. I was sorry to leave. I had a wonderful, music-filled time.

17 years ago I wrote I, for one, welcome our new CSS overlords

Everyone’s been talking about the new design over at Adaptive Path. It sure is a beauty; a crisp, clean, elegant design wrapped up in yummy XHTML and CSS.

17 years ago I wrote What decade is your personality living in?

My personality is, apparently, living in the 1990s:

17 years ago I wrote Mirror, mirror

I’ve got a new picture, taken on my trip to Dublin, up at The Mirror Project.