Container vs. Presentational Components

Supposons que nous disposons dans notre composant app, d'une liste bookList contenant une liste d'instance d'une classe Book que nous souhaitons afficher.

book/book.ts

export class Book {

    title?: string;

    constructor(args: Book = {}) {
        this.title = args.title;
    }

}

app.component.ts

import { Book } from './book/book';

...
export class AppComponent {
    bookList = [
        new Book({
            title: 'eXtreme Programming Explained'
        }),
        new Book({
            title: 'ReWork'
        })
    ];
};

Laissez bien sûr l'IDE s'occuper des imports via l'auto-complete ou l'auto-import (Alt + Enter chez JetBrains).

IntelliJ Class Completion

IntelliJ Auto Import

Il serait intéressant de déléguer l'affichage de chaque book au composant book-preview que nous pourrons réutiliser plus tard dans d'autres contextes.

Dans ce cas, nous séparons les responsabilités entre le composant app et le composant book-preview.

app.component.html

<!-- Display one book-preview component for each book... -->
<!-- ...but we need to find some way to pass the book to each component. -->
<wt-book-preview
        *ngFor="let book of bookList"></wt-book-preview>

Container Component (ou Smart Component)

Le composant app s'occupe donc de la "business logic" et sélectionne les objets book à afficher via la propriété bookList. Il est donc un "Container Component" qui délègue l'affichage à des "Presentational Components".

Presentational Component (ou Dumb Component)

Le composant book-preview ne sait pas d'où provient le book à afficher mais il sait l'afficher. Il est donc un "Presentational Component" qui est débarrassé de la "business logic".

Article plus détaillé sur le sujet

The Guide to Building Quality Angular 2+ ComponentsWishtack

Interaction entre Composants

Il ne reste plus au composant app qu'à communiquer chaque book au composant book-preview associé. Cf. Interaction entre Composants.