Container / Presentational

Das Pattern in der ursprünglichen Form

Dan Abramov hat 2015 zwei Kategorien definiert:

Container Components (smart):

• Beschäftigen sich mit wie Dinge funktionieren (Daten holen, Logik, State-Verwaltung)
• Selten eigenes Markup, eher Wrapping
• Bieten Daten und Verhalten zu Presentational-Komponenten an
• Sind oft mit Redux/State-Management verbunden
• Sind stateful (Klassen mit state in der Klassen-Komponenten-Ära)

Presentational Components (dumb):

• Beschäftigen sich mit wie Dinge aussehen
• Reines JSX, Styling und einfache UI-State (offen/zu, Hover)
• Bekommen alles über Props und rufen Callbacks auf
• Wissen nichts über Daten-Quellen, Redux, API-Endpunkte
• Sind stateless wenn möglich (functional components ohne State)

// Presentational — nur Darstellung, dumm
function UserList({ users, isLoading, onUserClick }) {
    if (isLoading) return <p>Lädt…</p>;
    return (
        <ul>
            {users.map(user => (
                <li key={user.id} onClick={() => onUserClick(user.id)}>
                    {user.name}
                </li>
            ))}
        </ul>
    );
}

// Container — Daten und Logik, schlau (Klassen-Komponente, da stateful)
class UserListContainer extends React.Component {
    state = { users: [], isLoading: true };

    componentDidMount() {
        fetch('/api/users')
            .then(r => r.json())
            .then(users => this.setState({ users, isLoading: false }));
    }

    handleUserClick = (id) => {
        this.props.history.push(`/users/${id}`);
    };

    render() {
        return (
            <UserList
                users={this.state.users}
                isLoading={this.state.isLoading}
                onUserClick={this.handleUserClick}
            />
        );
    }
}

Die Trennung war so beliebt, dass viele React-Projekte zwei Ordner hatten: containers/ und components/. In Redux-Projekten verstärkte die connect()-HOC-Konvention die Trennung — connect(mapStateToProps, mapDispatchToProps)(PresentationalComponent) war das archetypische Container-Pattern.

Warum das Pattern so wichtig war

Drei konkrete Probleme der frühen React-Welt löste das Pattern:

1. Wiederverwendbarkeit durch Entkopplung

Die UserList-Komponente kann von jedem Container gefüttert werden — vom Live-Container, einem Test-Container mit Mock-Daten, einem Storybook-Container für die Design-Dokumentation. Hätte die Daten-Logik in derselben Komponente gelebt, wäre Storybook und Testing mühsam gewesen.

2. Testing wurde einfach

Presentational-Komponenten sind reine Input→Output-Funktionen: gib Props rein, prüfe das Markup. Keine Mocks, keine Async-Tests, keine Fetch-Stubs. Container hatten den ganzen unangenehmen Stuff — wurden aber separat getestet.

3. Klare Architektur in großen Codebases

In Projekten mit zwanzig oder hundert Komponenten gab es eine klare Regel: „Wenn diese Komponente Daten holt oder State hat, ist sie ein Container; wenn sie nur Props nimmt, ist sie Presentational." Das hat Code-Reviews, Refactorings und Team-Onboarding deutlich vereinfacht.

Der Wandel — Custom Hooks ersetzen Container

Mit Hooks ist die Notwendigkeit des Patterns weggefallen. Ein Custom Hook kapselt dieselbe Daten- und Logik-Schicht, ohne dass dafür eine Wrapper-Komponente angelegt werden müsste:

// 1. Custom Hook ersetzt den Container
function useUserList() {
    const [users, setUsers] = useState([]);
    const [isLoading, setIsLoading] = useState(true);

    useEffect(() => {
        let cancelled = false;
        fetch('/api/users')
            .then(r => r.json())
            .then(data => {
                if (!cancelled) {
                    setUsers(data);
                    setIsLoading(false);
                }
            });
        return () => { cancelled = true; };
    }, []);

    return { users, isLoading };
}

// 2. Eine einzige Komponente, die beides nutzt — Logik via Hook, Darstellung inline
function UserListPage() {
    const navigate = useNavigate();
    const { users, isLoading } = useUserList();

    if (isLoading) return <p>Lädt…</p>;
    return (
        <ul>
            {users.map(user => (
                <li key={user.id} onClick={() => navigate(`/users/${user.id}`)}>
                    {user.name}
                </li>
            ))}
        </ul>
    );
}

Was sich hier verändert hat:

• Keine Container-Wrapper-Komponente mehr. Die UserListContainer-Klasse ist weg — der Hook lebt in der eigentlichen UI-Komponente.
• Wiederverwendbarkeit bleibt erhalten. useUserList() kann in jeder Komponente aufgerufen werden — genauso wiederverwendbar wie der alte Container.
• Testing bleibt einfach. Hook lässt sich isoliert mit renderHook testen; die UI-Komponente kann man mit einem gemockten Hook-Return testen.
• Flacher Komponenten-Baum. Kein zusätzlicher Wrapper im DevTools-Tree.

Dan Abramov hat 2019 selbst seinen Original-Artikel mit folgendem Hinweis aktualisiert (sinngemäß übersetzt):

Ich habe diesen Pattern nicht mehr empfohlen seit einiger Zeit. Hooks lassen dich dasselbe machen, ohne arbiträre Trennung von Komponenten. Dieser Artikel bleibt aus historischen Gründen sichtbar.

Was vom Pattern bleibt — die Idee, nicht die Form

Auch wenn die mechanische Trennung in „Container-Ordner" und „Presentational-Ordner" heute überflüssig ist, ist das Prinzip dahinter weiter gültig: Trenne Logik von Darstellung. Wie das modern aussieht:

Wiederverwendbare UI-Komponenten bleiben „dumm"

Eine <Button>, ein <Card>, ein <Modal> — solche UI-Bausteine sollten weiterhin rein über Props funktionieren, keinen API-Call und keinen Routing-Zugriff machen, keinen globalen State lesen. Sie sind in einem Komponenten-System oder Storybook nutzbar; sie sind das moderne Äquivalent zu „Presentational".

Daten-Logik in Custom Hooks bündeln

Statt einer UserListContainer-Komponente schreibt man einen useUserList()-Hook. Mehrere Komponenten, die dieselbe Logik brauchen, importieren den Hook. Das ist der moderne „Container".

Page-Komponenten dürfen beides

Eine UserListPage (am Routing-Endpunkt) ist nicht „dumm" — sie verbindet Custom Hooks, Routing, Auth-Context und das fertige Layout. Genau hier lebt die „Verkabelung", und genau hier ist die Mischung erlaubt und sinnvoll.

Strikte Ordner-Trennung ist nicht mehr nötig

Frühere Projekte hatten containers/UserListContainer.jsx und components/UserList.jsx. Heute organisiert man eher nach Feature: features/users/UserListPage.jsx, features/users/useUsers.ts. Die alte Ordner-Hierarchie war ein Symptom der Mechanik — die Mechanik ist weg, also auch das Symptom.

Vergleichs-Tabelle: damals und heute

Wann eine Container-Schicht heute noch sinnvoll ist

Es gibt wenige, aber valide Stellen, an denen man auch heute eine separate „Container"-Komponente baut:

1. Verschiedene Daten-Quellen, gleicher View

Wenn dieselbe <UserList> einmal aus einem Live-API gefüttert wird und einmal aus einem WebSocket-Stream und einmal aus einer lokalen Mock-Datei — dann lohnt es sich, drei Container-Komponenten (oder drei Hooks und einen Hook-Switch) zu haben, die alle den gleichen Presentational-View nutzen.

2. Suspense-/Error-Boundary-Wrapping

Wenn eine Komponente einen Suspense-Boundary und einen ErrorBoundary drum herum braucht, lohnt sich oft ein „Container", der diese Wrapping-Schicht stellt — und intern erst die Datenkomponente rendert. Das ist eher „Wrapping-Compound" als klassischer Container, hat aber dieselbe Optik.

3. Storybook-/Test-Doubles

Wenn die Presentational-Komponente in Storybook isoliert demonstriert werden soll, lebt sie ohne Container — und ein eigener Container-Wrapper liefert die echten Daten in der Produktion. Diese Trennung ist heute oft schon durch den Custom-Hook erreicht — aber für Komponenten mit aufwendigem Datenkontext kann ein expliziter Container die Tests einfacher machen.

Verwandte Artikel

• Custom Hooks – Einführung — die moderne Container-Form
• Higher-Order Components (HOC) — die andere historische Wiederverwendungs-Achse
• Composition statt Inheritance — das übergeordnete Komposition-Prinzip
• Funktionale vs. Klassen-Komponenten — historische Klassen-Komponenten als Containers

Externe Quellen

• Dan Abramov: Presentational and Container Components (mit Disclaimer) — der historische Original-Artikel, heute mit dem Hinweis versehen, dass Hooks die mechanische Trennung obsolet machen.
• React Docs: Reusing Logic with Custom Hooks — die offizielle moderne Sicht auf Logik-Wiederverwendung.
• Redux: Style Guide – Use Hooks API — auch Redux selbst empfiehlt heute Hooks (useSelector, useDispatch) statt connect()-HOCs.