2

Mastering Presentation Components

 2 years ago
source link: https://medium.com/@jon.dewitt/mastering-presentation-components-614e847efbce
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
neoserver,ios ssh client

Mastering Presentation Components

A detailed guide to separating content from presentation

Presentation. “This happy little tree lives right here.”

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, <Card> may be used inside <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.

Content describes one component called artist, which uses a component called quote with text reading “This happy little tree lives right here.” Presentation layer describes two components: quote, and brush stroke. The quote component includes a Bob Ross painting with text in a stylish font. The brush stroke component includes an option for the color green, and it’s labelled as leaky. Brush stroke is used in quote, and quote is used in artist, but brush stroke is not used in artist.
Visualizing encapsulated presentation

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. Hypothetically, we can eliminate semantic tags from the presentation by limiting markup to strictly <div> and <span>, but thus far I have not seen this pattern implemented in a sane way. It would seem it’s better for presentation components to share semantic responsibility with the content layer; to serve as semantic components in the same way that all squares are rectangles, but not all rectangles are squares.

That being said, if a <div> or <span> is necessary, then it belongs in your presentation component exclusively. Semantic markup may be shared, but 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: content 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.


About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK