Checkliste zur Vermeidung von Anti-Patterns

Verwenden Sie diese Checkliste, um Ihren RxJS-Code auf Anti-Patterns zu überprüfen. Klicken Sie auf jeden Punkt, um eine detaillierte Erklärung und Beispielcode zu erhalten.

Checkliste

🔴 Kritische Probleme vermeiden

Check	Punkt	Hinweis
	Subject über asObservable() veröffentlichen	Subject nicht direkt exportieren, sondern als Observable über asObservable() bereitstellen Zustandsänderungen nur über dedizierte Methoden ermöglichen
	Verschachtelte subscribe vermeiden	Kein weiteres subscribe innerhalb eines subscribe aufrufen Mit switchMap, mergeMap, concatMap etc. flach machen
	Unendliche Streams immer abbestellen	Unendliche Streams wie Event-Listener immer abbestellen takeUntil-Muster oder Subscription-Verwaltung
	shareReplay-Einstellungen explizit angeben	Format shareReplay({ bufferSize: 1, refCount: true }) verwenden Referenzzählung aktivieren um Memory-Leaks zu verhindern
	Verschachtelte if-Anweisungen in subscribe vermeiden	Komplexe Verzweigungen (3+ Verschachtelungen) in subscribe vermeiden Deklarativ mit filter, iif, partition etc. schreiben

🟡 Probleme die Aufmerksamkeit erfordern

Check	Punkt	Hinweis
	map ist reine Funktion, Seiteneffekte in tap	In map keine Zustandsänderungen oder Log-Ausgaben Seiteneffekte explizit mit tap-Operator trennen
	Cold/Hot richtig unterscheiden	HTTP-Requests etc. mit shareReplay in Hot umwandeln Entscheiden ob pro Subscription oder geteilt ausführen
	Promise mit from konvertieren	Promise und Observable nicht mischen Mit from() in Observable konvertieren und einheitlich verarbeiten
	Hochfrequente Events kontrollieren	Sucheingabe mit debounceTime, Scrollen mit throttleTime kontrollieren Duplikate mit distinctUntilChanged ausschließen

🔵 Verbesserung der Codequalität

Check	Punkt	Hinweis
	Fehler richtig behandeln	Fehler mit catchError abfangen und richtig verarbeiten Benutzerfreundliche Fehlermeldungen anzeigen Bei Bedarf mit retry / retryWhen wiederholen
	DOM-Events richtig freigeben	fromEvent-Subscriptions immer beenden Bei Komponenten-Zerstörung automatisch mit takeUntil abbestellen
	Typsicherheit gewährleisten	Interfaces und Type-Aliase definieren Typparameter für Observable<T> explizit angeben TypeScript-Typinferenz nutzen
	Passende Operatoren wählen	Suche: switchMap, parallel: mergeMap Sequentiell: concatMap, Doppelklick-Schutz: exhaustMap
	Einfache Verarbeitung braucht kein RxJS	Array-Verarbeitung etc. reicht normales JavaScript RxJS für asynchrone Verarbeitung und Event-Streams verwenden
	Zustand reaktiv verwalten	Zustand mit BehaviorSubject oder scan verwalten subscribe als finalen Trigger verwenden
	Tests schreiben	Marble-Tests mit TestScheduler durchführen Asynchrone Verarbeitung synchron testbar machen

Verwendung

1. Bei Code-Reviews

Nach dem Schreiben von neuem Code diese Checkliste für Selbst-Reviews nutzen.

2. Bei Pull Requests

Diese Checkliste in Pull-Request-Vorlagen einbinden für gemeinsame Überprüfungskriterien.

3. Regelmäßige Überprüfung

Diese Checkliste regelmäßig auf bestehende Codebasen anwenden um Anti-Pattern-Einschleichung zu erkennen.

4. Team-Sharing

Mit Teammitgliedern teilen um RxJS Best Practices zu vereinheitlichen.

Verwandte Ressourcen

• Häufige Fehler und Lösungen - Detaillierte Erklärungen und Codebeispiele für jedes Anti-Pattern
• Anti-Pattern-Sammlung Übersicht - Anti-Pattern-Liste und Lernpfad
• Fehlerbehandlung - Best Practices für Fehlerbehandlung
• Testmethoden - Wie man RxJS-Code testet

Tipps zur Checklisten-Nutzung

1. Nicht alle Punkte auf einmal perfekt machen wollen

   • Zuerst kritische Probleme (🔴) priorisieren
   • Schrittweise verbessern

2. Prioritäten im Team festlegen

   • Wichtigkeit je nach Projekteigenschaften anpassen
   • Angepasste Checklisten erstellen

3. Automatisierung erwägen

   • Automatische Checks mit statischen Analysetools wie ESLint
   • In CI/CD-Pipeline integrieren

4. Regelmäßig aktualisieren

   • Bei RxJS-Versions-Upgrades aktualisieren
   • Team-Erfahrungswissen einarbeiten

---

Wichtig: Diese Checkliste dient nicht dem Schreiben von perfektem Code, sondern der Vermeidung häufiger Probleme. Bitte je nach Projektkontext flexibel einsetzen.