DEV Community: Tomasz Kula

The Most Misunderstood Part of Styling Components 🚀

Tomasz Kula — Tue, 16 Feb 2021 13:17:33 +0000

The problem

Imagine you are tasked with rendering a list of articles. Seems easy enough, you've done this a lot. You quickly come up with this solution:

<div class="articles">
  <div *ngFor="let article of articles">
     {{ article.tittle }}
  </div>
</div>

.articles {
  display: flex;
  justify-content: space-between;
  align-items: center;
}

All is well in the world, the list is displayed correctly, and you move on with your life 💪

The Next Day

Next day, there is a new requirement. On a different page of the application you have to render the same articles, but now in a grid layout 🧱

We want to reuse the existing component, because the only difference is the layout of the list.

You might think of the following solutions:

create @Input which will drive the behaviour of dynamically styling the component to render either a list or a grid layout
create a <articles-grid> and <articles-list> components which will reuse the article card.

Both of this solutions will work, but they are needlessly complicated 😱
We either have to expand the component API to accommodate different layouts or create layout components that differ by just a couple lines of CSS.

The solution

What about a different approach? If we get rid of the wrapper .articles div and style the :host element directly, we will be able to override this layout styling as needed in the parent component.

Let's see it in action.

First, we remove the not needed wrapper div:

<div *ngFor="let article of articles" class="article">
   {{ article.tittle }}
</div>

Next, we update the CSS to target the :host element of the component:

:host {
  display: flex;
  justify-content: space-between;
  align-items: center;
}

And that's it! With this simple change, we open up lost of possibilities for different layouts, which we can achieve with just CSS.

That's because the :host selector is the only part of the component which can be styled in the parent component.

Now this will continue to render the default flex layout:

<app-articles></app-articles>

But this will override the flex layout with grid:

<app-articles class="grid"></app-articles>

.grid {
  display: grid;
  grid-template-columns: 1fr 1fr 1fr;
}

In the future if there is a new requirement to render the article list in a different layout, it's as easy as creating a new CSS class and styling it.

<app-articles class="two-column-grid"></app-articles>
<app-articles class="five-column-grid"></app-articles>
<app-articles class="responsive-grid"></app-articles>
...etc

The recommendation

❌ Avoid using top level container elements just to style them
✅ Style :host component when possible to make the component more reusable

Hope you're having a great one, and I'll see you for more web dev posts in the future 🥳

The Most Important Thing to Understand About Component Composition 🚀

Tomasz Kula — Fri, 12 Feb 2021 10:42:58 +0000

The problem

Say you are working on an e-commerce application and are tasked with creating a product page that renders a call to action button to buy awesome Nike shoes.

Right now, the app has a following component tree:

> product-page
>> card
>>> card-content
>>>> cta-button

You want to render "Buy Air Max" as a label of the call to action button.

The issue is the button component is deeply nested in the component tree, and the product model information is available in the top most component.

> product-page <-- Here we know the product name
>> card
>>> card-content
>>>> cta-button  <-- Here we want to render the product name

The Struggle

You might jump in and create the @Input() in each component and pass it down to the button component.

<!-- product-page.component -->
<card [productName]="productName"></card>

<!-- card.component -->
<card-content [productName]="productName"></card-content>

<!-- card-content.component -->
<cta-button [productName]="productName"></cta-button>

<!-- cta-button.component -->
Buy {{ productName }}

It works fine, but there are couple of issues:

We are adding @Inputs() to components which don't use them, only passing them down to the child components.

> product-page 
>> card <-- I don't care about the product name
>>> card-content <-- I don't care about the product name
>>>> cta-button

It makes adding additional @Inputs() painful. If button needs more data from the product page, you have to pass it through two other components. This process is sometimes referred to as prop drilling.

> product-page <- We know the product price
>> card <-- I have to add @Input() for price
>>> card-content <-- I have to add @Input() for price
>>>> cta-button <-- I have to add @Input() for price

It makes unit testing more difficult as you have to test passing the @Inputs() in each component.

The Solution

You can solve this problem using a different approach. How about we use content projection instead of drilling props with @Inputs()?

Compare the previous solution, with the following:

<!-- product-page.component -->
<card> 
  <card-content>
    <cta-button>Buy {{ productName }}</cta-button>
  </card-content>
</card>

<!-- card.component -->
<ng-content></ng-content>

<!-- card-content.component -->
<ng-content></ng-content>

<!-- cta-button.component -->
<ng-content></ng-content>

This approach has the following benefits:

We no longer add @Inputs() to components that don't need them so we avoid prop drilling.
Components become more extensible. You can pass as much information to the button component as you'd like, without touching the card components.
Because of the previous points, unit testing becomes much easier.

The Benefits

Let's see how we might benefit from this approach.

Say you are now tasked with extending the call to action button with a price tag - "Buy Air Max at $199".

With content projection approach, we only need to make a small change in the product page component:

<!-- product-page.component -->
<card> 
  <card-content>
    <cta-button>Buy {{ productName }} at {{ productPrice }}</cta-button>
  </card-content>
</card>

That's it! See how easy it is? No props drilling, no test changes for the child components, no problem :)

Hope you're having a great one, and I'll see you for more web dev posts in the future 🥳

Streaming the Angular @Output()

Tomasz Kula — Mon, 08 Feb 2021 08:23:46 +0000

We all know and love the @Output() decorator. If you are working with Angular I'm sure you've done this before:

@Output()
change = new EventEmitter<ChangeEvent>();

However, the lesser known fact is, that the property decorated by the @Output does not have to be an EventEmitter.

In fact, it can be an RxJS Observable. It opens up a lot of possibilities, because we can wield the full power of RxJS operators 😱

For example, you can have an Output() decorating your reactive form control's valueChanges stream.

control = new FormControl('');

@Output()
valueChages$ = this.control.valueChanges
  .pipe(
     distinctUntilChanged()
  );

Here you can see I'm limiting the emitted values to only the distinct ones, but other operators such as debounceTime could be used as well.

Hope you're having a great one, and I'll see you for more 60 Seconds of Angular posts in the future 🥳

Live demo

How distinct is distinctUntilChanged?

Tomasz Kula — Mon, 08 Feb 2021 08:23:15 +0000

If you have been working with RxJS, you might have heard about distinctUntilChanged() operator 🔥

Let's have a quick peek into the official docs to see how it works:

Returns an Observable that emits all items emitted by the source Observable that are distinct by comparison from the previous item.

So in short, if the source stream emits:

a-a-b

You get just

a---b

There is a catch, though. By default, the operator will compare values using the === operator.

This will work fine for primitive values like strings or numbers which are compared by value, but will not work for stuff like arrays or objects which are compared by reference.

'a' === 'a' // true
1 === 1     // true
{} === {}   // false
[] === []   // false

So any time you are working with objects streams, you should strongly consider providing your own compare function to the distinctUntilChanged() operator.

const source = of({ id: 1 }, { id: 1 }, { id: 2 });

// ❌ does not work, because values are compared with ===
source.pipe(
  distinctUntilChanged()
).subscribe(console.log);
// logs { id: 1 } { id: 1 } { id: 2 }

// 🔥 it works, because we provide a custom compare function
source.pipe(
  distinctUntilChanged((prev, next) => prev.id === next.id)
).subscribe(console.log);
// logs { id: 1 } { id: 2 }

Live demo

Hope you're having a great one, and I'll see you for more 60 Seconds posts in the future 🥳

DEV Community: Tomasz Kula

The Most Misunderstood Part of Styling Components 🚀

The problem

The Next Day

The solution

The recommendation

In Case You Missed it

The Most Important Thing to Understand About Component Composition 🚀

The problem

The Struggle

The Solution

The Benefits

In Case You Missed it

Streaming the Angular @Output()

How distinct is distinctUntilChanged?