React im Enterprise-Umfeld -- Erfahrungen aus großen Projekten

Angular 1 hat uns gelehrt, was wir nicht wollen. jQuery-Spaghetti hat uns gelehrt, warum wir ein Framework brauchen. React 15 hat uns gelehrt, dass eine UI-Komponentenbibliothek die Grundlage einer Enterprise-Anwendung sein kann – wenn man das richtige Ökosystem darum aufbaut.

Warum React und nicht Angular 2?¶

Anfang 2017 stehen wir vor der Wahl: Angular 2 (frisch umbenannt in Angular 4), React oder Vue.js. Angular bietet “Batteries Included” – Routing, Forms, HTTP-Client, Dependency Injection. React ist “nur die View-Schicht” – den Rest stellen Sie selbst zusammen.

Für unser Enterprise-Projekt haben wir React gewählt. Gründe: Flexibilität (wir wählen eigene Lösungen für Routing, State, Forms), Ökosystem (es gibt um Größenordnungen mehr npm-Pakete für React), Recruiting (es gibt mehr React-Entwickler auf dem Markt als Angular) und inkrementelle Adoption (man kann React Stück für Stück in eine bestehende Anwendung einbauen).

Architektur eines großen Projekts¶

Unser Projekt: internes System für eine Bank, 15 Entwickler, 200+ Komponenten, 40+ Screens. Die Struktur, die wir gewählt haben:

src/
├── components/          # Shared UI components
│   ├── Button/
│   │   ├── Button.jsx
│   │   ├── Button.test.js
│   │   └── Button.css
│   └── DataTable/
├── features/            # Business features (modular)
│   ├── accounts/
│   │   ├── components/
│   │   ├── containers/
│   │   ├── actions.js
│   │   ├── reducer.js
│   │   └── selectors.js
│   └── transactions/
├── services/            # API clients, utilities
├── store/               # Redux store configuration
└── routes/              # React Router definitions

Zentrale Entscheidung: Feature-basierte Struktur statt typ-basiert (alle Reducer in einem Ordner, alle Actions in einem anderen). Wenn ein Entwickler an “accounts” arbeitet, hat er alles beisammen.

State Management – Redux¶

Redux ist 2017 der De-facto-Standard für React State Management. Unidirektionaler Datenfluss, immutables State, reine Reducer-Funktionen. Für eine Enterprise-Anwendung mit komplexem Zustand ist das die Rettung – vorhersagbares State, Time-Travel Debugging, Middleware für Side Effects.

Aber Redux hat seinen Preis: Boilerplate. Action Types, Action Creators, Reducer, Selektoren – für ein Feature schreiben Sie 4 Dateien, bevor Sie zur UI kommen. Wir lösen das mit Generatoren (Plop.js) und Konventionen.

Für asynchrone Operationen verwenden wir redux-saga. Generatoren sind komplexer als Thunks, aber Testbarkeit und Kontrolle über Side Effects sind im Enterprise-Umfeld kritisch. Saga kann Cancel, Retry und Race Conditions handhaben – Dinge, die man in Thunks manuell löst.

Komponentenbibliothek¶

Mit 15 Entwicklern brauchen Sie eine gemeinsame Komponentenbibliothek. Sonst haben Sie 8 verschiedene Button-Implementierungen. Wir haben eine interne Bibliothek auf Basis von React + CSS Modules gebaut. Storybook als Dokumentation und Playground.

Regeln: Jede Komponente hat PropTypes (TypeScript hatten wir 2017 noch nicht eingeführt – das bedauern wir im Nachhinein), Unit Test und Story im Storybook. Code Review wird ohne alle drei nicht freigegeben.

Testing¶

Jest für Unit Tests (schnell, Snapshot Testing, Mocking). Enzyme für Komponenten-Tests (Shallow Rendering, Mount, Event-Simulation). Snapshot-Tests für UI-Regression – ändern Sie eine Komponente, Jest zeigt den Diff.

Ziel: 80 % Code Coverage bei Business-Logik (Reducer, Selektoren, Utilities). UI-Komponenten testen wir auf Verhalten, nicht auf Implementierung. “Klick den Button, prüfe ob der Callback aufgerufen wurde” – nicht “prüfe ob das div die Klasse active hat”.

Performance und Code Splitting¶

200+ Komponenten = großes Bundle. Lösung: React Router Code Splitting mit Webpack 2 Dynamic Imports. Jede Route lädt lazy – initialer Load unter 200 KB gzipped. Webpack Bundle Analyzer enthüllte, dass moment.js 60 KB an Locale-Dateien belegte, die niemand verwendete.

React Perf Tools (React DevTools Profiler existierte 2017 noch nicht) zur Identifizierung unnötiger Re-Renders. Reselect für memoized Selektoren. PureComponent statt Component, wo es Sinn macht.

Was wir anders machen würden¶

• TypeScript von Anfang an – PropTypes reichen nicht, Refactoring von 200 Komponenten ohne Typen ist schmerzhaft
• CSS-in-JS statt CSS Modules – styled-components würden Theming eleganter lösen
• Weniger Redux – nicht jeder State gehört in den Store, lokaler State ist OK für Formulare und UI
• Monorepo – Komponentenbibliothek in einem separaten Repo erzeugt Reibung, Lerna Monorepo wäre besser

React funktioniert im Enterprise – mit Disziplin¶

React gibt Ihnen keine Struktur – Sie müssen sie selbst schaffen. Konventionen, Code Review, gemeinsame Komponentenbibliothek, Teststrategie. Die Flexibilität von React ist Stärke und Schwäche zugleich. Für ein kleines Team ist es Freiheit, für ein großes Team ohne Regeln ist es Chaos.