Mastering Presentation Components
A detailed guide to separating content from presentation
Assuming you’re familiar with both traditional and modern definitions for “separation of concerns,” you may have found it difficult or confusing to place certain things in the bucket of “presentation” versus other abstractions.
Let’s start by actually defining exactly what presentation means. Presentation is the way in which your content is presented to users (or machines, even.) Primarily, that involves visual appearance, but it can be applied to audio or accessibility features as well. Consequently, that means the UI plays the role of presentation in your website or application.
A presentation component earns its name by isolating design concerns from the rest of your project. It doesn’t care about the content or handlers provided to it; those just get passed through. This approach makes the component flexible enough to be reused without duplication, while also decoupling the presentation from the content.
Internal vs External
The idea is that all presentation details should be confined internally, and never exposed externally. As long as all design decisions are sheltered from the rest of your application, you’ll be more prepared for rebranding, additional themes, or even minor design updates.
Properties like position=”left” or color="#5d5d68" create a leaky abstraction, which cross-cuts concerns by allowing design decisions to be made from the component’s consumer. Similarly, these components should be named in a semantic way. For example, <Row> and <Card> exist purely for presentation, whereas <Book> and <Author> take full responsibility for the design. A parent component can safely hand off the data for each book and author without caring about how it’s displayed.
Potentially, such leaky components are still valid if their usage is limited to other presentation components. This can be especially helpful for utilizing component composition. In other words, that leaky <Card> may be used by <Author>, but only <Author> may be used by non-presentation parents.
It might be easier to compare these guidelines to the analogy of paint on canvas, with an overlapping quote.
The quote itself is considered content, while the <Quote> component is in charge of presenting that particular kind of content. Since “quote” implies nothing visual, it can safely be used outside the presentation layer. <BrushStroke>, however, is visually descriptive, and therefore it cannot be used in <Artist> as part of the content. Instead, it’s used inside <Quote>, which serves as an abstraction to prevent presentation details from leaking across layers.
Native Semantics
Structural content is often described in part by HTML semantics. Semantic HTML tags could be compared to presentation components in a way, because they are semantic on the surface level while hiding their presentation details, (often accessibility, in this case.)
Since presentation components often compose other presentation components, (leaky or not,) it’s perfectly valid to add semantic markup inside your presentation layer.
That being said, if a <div> or <span> is necessary, then it belongs in your presentation component exclusively. Purely presentational markup certainly has no place outside the presentation layer.
Component Structure
It gets tricky to consider what remains valuable to separate at the component scale. Intuitively, it’s very human to think of everything in a visual way, especially HTML. That’s why it’s so common to find several nested <div> tags, or the dreaded <h5> used specifically for its font size. But in the age of component-driven development, you may think it’s more acceptable to use presentational markup to get the job done, right?
Well, within reason, yes. It’s certainly true that HTML inevitably concerns presentation to some degree, and strict separation from CSS may be less significant in the context of components. Of course, everything is better in moderation. We don’t want to swing to extremes, like inline CSS, heavy abuse of presentational markup, or too many visually descriptive class names.
A lot of the time, when we turn to <div> tags, it indicates some kind of code smell. For example, grid layouts.
<section>
<div class="row">
<div class="col">
<p>one</p>
</div>
<div class="col">
<p>two</p>
</div>
<div class="col">
<p>three</p>
</div>
</div>
</section>The above markup depends a little too heavily on presentation, even for a presentation component. There’s a lot of excess structure and class names that aren’t useful as content markers, which might confuse and frustrate your SEO specialist or future developers new to the project.
Using CSS grid or flexbox, it can be simplified so there is less to maintain and more freedom to potentially style the same template in different ways.
(HTML)
<section class="count">
<p>one</p>
<p>two</p>
<p>three</p>
</section>(CSS)
.count {
display: grid;
}
@media (min-width: 50em) {
.count {
grid-template-columns: repeat(3, 1fr);
}
}
That’s much easier to digest, and with a template like this, it’s easier to visualize on mobile devices where columns are not a factor.
Note: markup structure doesn’t always match the layout. In cases like that, it can be very helpful to be aware of display: contents;.
In short, presentation components may use some combination of HTML and CSS to achieve a certain look, yet still, there is value in the idea that CSS should be the primary source of style.
What About JavaScript?
Indeed, even today, there’s a lot of presentation that can’t be achieved without some scripting. This could involve parallax scrolling effects, class toggles, canvas, etc. Most often, you’ll probably just want to handle expanding menus, carousel controls, and accessible keyboard navigation. These are considered presentation, because after all, if the user can’t effectively navigate the website to reveal more content, then that content would never be presented.
It should be noted, however, that this scope should be aggressively limited. JavaScript has a lot more going on than HTML or CSS, and as such there are more opportunities to abuse it.
Ultimately, mastering presentation is something that comes with time spent adhering to these principles. Understanding it conceptually is easy enough, but the hardest part in my own journey has been retraining my brain to describe content as though it can’t be seen. It’s challenging for sure, but a major “level-up” once you get the hang of it.
