Dieser Beitrag ist Teil 2 von 5 in the series WPS @ Angular

WPS loves Angular visual

This is Part 2 of Best Practices for Not Getting Lost When Building Real-World Applications

by Richard Voß @richard_voss

Since last year we find ourselves developing web applications for our customers using Angular 4, 5, 6 und now 7. Angular is a popular framework (some call it a platform) for developing web-based front-end applications using Typescript, HTML and CSS. It is open-source and primarily driven by Google.

The framework makes it easier and more fun to structure complex user interfaces, promotes re-use of components and — most valuable — allows test-driven development in the front-end.

Despite all of the greatness of Angular, even with the framework there are lots of mistakes left to make. We have identified a few good patterns and pitfalls that we collected.

This article is part of a series that offers a glimpse into our “Angular Pattern Library”. We started with the generic advice to 👍 Factor Out Components, but we hadn’t talked about the CSS part of components…

👍 Manage Component Layout Boundaries

A component’s interface is not just inputs, outputs and services.

In the beginning we under-estimated the headache that resulted from re-using a component that was built to “look good” in a certain place and simply would break everything when added somewhere else.

That is because the layout behaviour of a component is also part of it’s interface. And sadly, there is no well-defined standard method to make that part of the interface obvious.

When using another component, the following questions often arise:

  • I have a bootstrap grid here, will the component behave like a column on it’s own?
  • Can I use the component like inline text?
  • Why does this component not use the available space of my flex container?

Our recommendations for making that part of the interface obvious

That’s why we absolutely recommend to take care of this part of the component’s interface by three means:

  1. Define a layout behaviour for any component, don’t just rely on the context you build the component for. That means take a moment to think.
  2. Document that behaviour in an easy-to-find fashion. For instance, a comment in the component’s CSS or SCSS file is a good start, because that’s where other’s will try to find out. Teams may even find naming conventions appropriate.
  3. Limit the amount of variations in your application. It should not be necessary to think about details for every component you use. Therefore, you should have a few standard patterns in your team like the following examples:
    • TileComponent creates a block element with fixed width/height
    • ContainerComponent uses available horizontal space and grows vertically with it’s content
    • BarComponent is like a container, but does not grow vertically, often toolbars are like that
    • SymbolComponent can be dropped anywhere like text, good for icons.
    • ExpanseComponent fills the entire available space and governs its content overflow itself (often top-level app components are like this)
    • … define your own conventions and use them
    • It’s worthwhile to be consistent concerning the use of flex in an application, because mixing flex and non-flex approaches adds complexity.

Treat components like other HTML elements

One issue here is that an Angular component always requires a non-HTML element in your DOM. Such an “unknown” element is treated by browsers roughly like a “display:content” element. That causes the browser to almost ignore the custom element and lay out it’s contents like it wasn’t there in between. But when it comes to CSS selectors, the element is there and counts for parent-child and sibling-oriented selections.

We heave found that it can bee a good idea to rather embrace the custom element in the DOM and make its layout behaviour explicit. To achieve this, you can use the :host pseudo-selector provided by Angular.

:host {
  display: block;
}

Such a statement satisfies recommendations 1 and 2 from above and will make your life easier. As a result, very often you can avoid to wrap all of a component’s template in a <div> (a quite common pattern…), by effectively turning your component into a <div>-like element.

Likewise, with display: inline you can create full-blown components that are visually as subtle as a single letter in text.

up next

Properly isolated components have huge advantages when it comes to testing. Read about how to 👍 Mock Components in the next article.

Seriennavigation<< Angular @ WPS: Best Practices for Not Getting Lost When Building Real-World ApplicationsAngular @ WPS Part 3: Focused Component Testing >>