6 React-Anti-Pattern, die Ihren Code verschlechtern

In der React-Entwicklung schleichen sich oft unbemerkt Probleme ein. In diesem Beitrag zeige ich die 6 React-Anti-Pattern, die Sie kennen und vermeiden sollten, um Ihre Anwendungen langfristig sauber, wartbar und skalierbar zu halten.

Anti-Patterns sind wie hinterhältige Fallstricke: Sie scheinen auf den ersten Blick harmlos zu sein, verursachen aber Probleme, wenn Ihre Codebasis wächst. Mit Pattern meine ich hier hauptsächlich den Code, den ich ziemlich oft in vielen Codebasen sehe, geschrieben von Entwicklern unterschiedlicher Erfahrungsstufen – nicht unbedingt Pattern im Sinne von formalen Designpattern. Ich teile einige der häufigsten Anti-Patterns, auf die ich in der React-Entwicklung gestoßen bin, in der Hoffnung, dass das Erkennen dieser Muster Ihnen hilft, Ihren Code sauber, skalierbar und wartungsfreundlich zu halten.

1. Bohren von Stützen

Das Problem: Das Bohren von Stützen findet statt, wenn Sie Stützen von einer Komponente der obersten Ebene durch mehrere Schichten von Zwischenkomponenten nach unten führen, bis sie schließlich die Komponente erreichen, die sie tatsächlich benötigt. Dies kann besonders problematisch sein, wenn Ihr Komponentenbaum tief ist und die Requisite nur von einer Komponente am Ende dieser Kette verwendet wird.

Warum es schlecht ist: Dies führt zu eng gekoppelten Komponenten, die schwer zu refaktorieren sind. Wenn sich eine Requisitenanforderung ändert, müssen Sie möglicherweise alle Komponenten aktualisieren, die zwischen oben und unten liegen. Das gesamte System wird anfällig und schwer zu warten.

Stellen Sie sich eine Komponente vor, die eine Funktion nach unten durch und dann an übergibt. Jede Zwischenkomponente muss mit den Requisiten umgehen, auch wenn sie sie eigentlich nicht benötigt. Dies fügt eine Menge Komplexität für sehr wenig Gewinn hinzu.

Codebeispiel – Schlechter Ansatz:

function SearchableList({ items, onItemClick }) {
  return (
    <div className="searchable-list">
      <List items={items} onItemClick={onItemClick} />
    </div>
  );
}


function List({ items, onItemClick }) {
  return (
    <ul className="list">
      {items.map((item) => (
        <ListItem key={item.id} data={item} onItemClick={onItemClick} />
      ))}
    </ul>
  );
}

function ListItem({ data, onItemClick }) {
  return (
    <li className="list-item" onClick={() => onItemClick(data.id)}>
      {data.name}
    </li>
  );
}

Sie müssen den ganzen Weg von bis nach unten gehen, alle Komponenten dazwischen müssen die Requisite kennen, den Typ der Funktion, aber tun Sie nichts damit.

Das ist ziemlich häufig, wenn Menschen nur versuchen, das Problem an der Oberfläche zu „beheben“, oder keine Zeit haben, darüber nachzudenken, wie groß die Auswirkungen sein könnten.

2. Komponenteninterne Datentransformation

Das Problem: Das Transformieren von Daten direkt in der Renderfunktion einer Komponente oder in der Renderfunktion selbst scheint oft der einfachste Ansatz zu sein. Sie rufen die Daten ab, transformieren sie nach Bedarf und legen dann den Status fest – alles an einem Ort.

Warum es schlecht ist: Dies vermischt die Belange Ihrer Komponente und bläht sie mit mehreren Aufgaben auf – Abrufen, Transformieren und Rendern. Es erschwert auch das Testen und schränkt die Wiederverwendbarkeit der Transformationslogik ein. Wenn die Transformationen komplexer werden, wird es viel schwieriger, die Komponente zu verstehen und zu verwalten.

Stellen Sie sich eine Komponente UserProfile vor, die Benutzerdaten abruft und transformiert, indem sie den Vor- und Nachnamen kombiniert oder die Adresse formatiert. Wenn Sie all diese Logik darin platzieren, bedeutet dies, dass jede Änderung einen tiefen Einblick in das Abrufen und die Transformation erfordert – nicht sehr effizient.

Codebeispiel – In-Component-Transformation:

function UserProfile({ userId }) {
  const [user, setUser] = useState(null);
  useEffect(() => {
    fetch(`/api/users/${userId}`)
      .then(response => response.json())
      .then(data => {
        // Transforming data right inside the component
        const transformedUser = {
          name: `${data.firstName} ${data.lastName}`,
          age: data.age,
          address: `${data.addressLine1}, ${data.city}, ${data.country}`
        };
        setUser(transformedUser);
      });
  }, [userId]);

  return (
    <div>
      {user && (
        <>
          <p>Name: {user.name}</p>
          <p>Age: {user.age}</p>
          <p>Address: {user.address}</p>
        </>
      )}
    </div>
  );
}

Dieses Beispiel zeigt, wie das Abrufen und Transformieren von Daten direkt in use Effect kombiniert werden, was zu einer eng gekoppelten Komponente führt und die Wiederverwendung oder das Testen erschwert.

3. Komplizierte Logik in Ansichten

Das Problem: Waren Sie jemals versucht, eine gewisse Geschäftslogik direkt in Ihre Komponente zu integrieren, weil „es nur ein kleines Stück ist“? So fängt es an, aber schon bald ist die Komponente mit bedingten Anweisungen, Mapping-Logik und Berechnungen gefüllt.

Warum es schlecht ist: Komponenten sollen sich auf die Darstellung der Benutzeroberfläche und nicht auf die Implementierung von Geschäftsregeln konzentrieren. Je mehr Logik Sie in Ihre Komponenten stecken, desto schwieriger ist es, sie wiederzuverwenden oder die Regeln zu ändern, ohne das Rendering zu beeinflussen. Es führt zu sperrigen Komponenten, die schwer zu testen und zu verstehen sind.

Stellen Sie sich eine Komponente vor, die nicht nur Bestelldetails anzeigt, sondern auch Rabatte, Versandkosten und geschätzte Steuern berechnet – die Art von Logik, die viel wiederverwendbarer wäre, wenn sie in separaten Servicefunktionen oder Hooks leben würde.

4. Fehlende Tests

Das Problem: Das Überspringen von Tests kann sich wie eine Zeitersparnis anfühlen, insbesondere wenn Sie gegen eine Deadline arbeiten. Da React-Komponenten jedoch häufig komplexe Funktionen verarbeiten – wie die Verwaltung des Formularstatus oder die Koordination von API-Aufrufen – kann dies zu schwer zu diagnostizierenden Fehlern führen.

Warum es schlecht ist: Ohne geeignete Komponenten- oder Integrationstests gibt es kein Sicherheitsnetz, um Fehler beim Refactoring oder Hinzufügen von Features zu erkennen. Jede Änderung wird zu einem riskanten Unterfangen, und Sie müssen viele manuelle Tests durchführen, die immer noch nicht alle Szenarien abdecken können.

Ich erinnere mich, dass ich eine Funktion ausgeliefert habe, bei der ein Warenkorb in bestimmten Grenzfällen nicht aktualisiert werden konnte. Geeignete Komponententests hätten die Probleme erkannt, bevor sie die Produktion erreichten.

5. Duplizierter Code

Das Problem: Das Kopieren und Einfügen eines Codestücks ist oft die einfachste Lösung – Sie haben es bereits geschrieben, warum also nicht direkt wiederverwenden? Das Problem ist, dass jedes Duplikat eine Wartungsbelastung darstellt. Deshalb nehmen wir es als Punkt 5 von den 6 React-Anti-Pattern.

Warum es schlecht ist: Wenn sich die Anforderungen ändern, müssen Sie jede duplizierte Instanz aktualisieren, und wenn nur eine davon fehlt, kann dies zu Fehlern und Inkonsistenzen führen. Hier geht es nicht nur um Faulheit; Es geht darum, sicherzustellen, dass Ihre Logik zentralisiert und einfach zu ändern bleibt.

Stellen Sie sich eine Funktion vor, die in mehreren Komponenten angezeigt wird, weil Sie sie jedes Mal eingefügt haben, wenn Sie sie benötigen. Wenn sich die Formatanforderung ändert, wird es zu einer Aufgabe, bei der Sie alle suchen und hoffen, dass Sie sie alle gefunden haben.formatDate()

Codebeispiel – duplizierter Code:

function AdminList(props) {
  const filteredUsers = props.users.filter(user => user.isAdmin);
  return <List items={filteredUsers} />;
}

function ActiveList(props) {
  const filteredUsers = props.users.filter(user => user.isActive);
  return <List items={filteredUsers} />;
}

Dieses Beispiel zeigt, wie wiederholte Logik – das Filtern von Benutzern – in verschiedenen Komponenten vorhanden ist, was zu Code-Duplizierung und Wartbarkeitsproblemen führt.

6. Lange Komponenten mit zu vielen Verantwortlichkeiten

Das Problem: Sie denken vielleicht an eine solche Komponente, die alles verwaltet, was mit einer Bestellung zu tun hat – Validierung, Fehlerbehandlung, Abrufen von Daten und Rendern der Benutzeroberfläche. Es scheint bequem, bis es zu einer „Gotteskomponente“ heranwächst.OrderContainer

Warum es schlecht ist: Die Komponenten sollten dem Prinzip der einheitlichen Verantwortung (Single Responsibility Principle, SRP) folgen. Wenn sie zu viele Verantwortlichkeiten haben, werden sie komplex und schwer zu debuggen, zu verstehen oder zu erweitern. Sie sind auch sehr schwer zu testen, insbesondere wenn ein Teil der Logik von einem anderen abhängt.

In einem Projekt hatte ich eine Formularkomponente, die die Validierung, Übermittlung, Fehleranzeige und sogar die Verwaltung des globalen Status übernahm. Das Aufteilen in kleinere Komponenten und das Extrahieren von Hooks für verschiedene Aufgaben erleichterte die Arbeit mit dem Code erheblich.

Fazit

Dies sind nur einige der Anti-Muster, die ich im Laufe meiner Arbeit mit React zu erkennen und zu vermeiden gelernt habe. Der Schlüssel zu wartbaren, skalierbaren React-Anwendungen liegt darin, zu wissen, wann Sie in diese Fallen tappen, und entsprechend umzugestalten. Achten Sie bei ihrer täglichen Arbeit mal auf die 6 React-Anti-Pattern.

Weiterer lesenswerter Beitrag: PHP im Jahr 2025 meistern: Fortgeschrittene Techniken, Profi-Tipps und Best Practices