Nils Hartmann Selbstständig

React selbst macht kaum eine Aussage darüber, wie Anwendungen strukturiert sein sollten oder wie die Architektur auszusehen hat. Allerdings ist React überaus flexibel, sodass die Verwendung auf eigene Projektbedürfnisse abgestimmt werden kann. Durch die Verwendung eines statischen Typsystems wie TypeScript können viele Fehler bereits in der Entwicklung erkannt und vermieden werden.

Die Entwicklung von Komponenten und Anwendungen mit React ist nicht schwierig, da das API von React sehr schmal und deswegen schnell erlernbar ist. Für große Enterprise-Anwendungen kommen aber eine ganze Reihe von Fragen ins Spiel, für die React keine fertige Antwort mitbringt.

Enterprise-Anwendungen zeichnen sich in der Regel dadurch aus, dass sie eine große Codebasis haben, die von einer Vielzahl von Entwicklern und Teams über einen langen Zeitraum entwickelt und gewartet wird.

Dadurch ergeben sich auch im Bereich der Frontend-Entwicklung eine ganze Reihe von Fragestellungen. Wie kann der Code so strukturiert werden, dass möglichst mehrere Teams unabhängig voneinander damit arbeiten können? Wie kann sichergestellt werden, dass der Code auch nach mehreren Monaten oder gar Jahren noch verstanden und verändert werden kann? Und: Wie kann der Code überhaupt getestet werden? Im Folgenden wollen wir uns einige dieser Probleme ansehen und schauen, welche Möglichkeiten es gibt, sie mit React zu lösen.

Codestruktur

Um die Orientierung im Sourcecode einer großen Anwendung nicht zu verlieren, ist es wichtig, eine vernünftige Struktur dafür zu wählen. Im Gegensatz zu Java-Projekten – wo es mit Maven einen De-facto-Standard für Projektlayouts und mit der Java-Sprachspezifikation genaue Vorgaben gibt, wie Dateien für Klassen heißen und wo sie liegen müssen – können diese Entscheidungen in JavaScript- und React-Anwendungen nahezu nach Belieben getroffen werden.

Das ist einerseits sehr praktisch, da Strukturen je nach Vorlieben des Teams geschaffen werden können. Auf der anderen Seite ist das Team aber auf diese Weise auch verpflichtet, sich damit auseinanderzusetzen. Ähnlich wie beim Thema Tabs oder Spaces oder der Suche nach der „richtigen“ Codeformatierung kann auch das Thema Codestruktur intensiv diskutiert werden. In der Dokumentation von React findet sich diesbezüglich lediglich der Hinweis, dass Code, der in der Regel gemeinsam verändert wird, auch „nahe beieinander“ sein sollte (Colocation).

Dan Abramov, einer der React-Core-Entwickler, hat seine Meinung zum Thema so zusammengefasst: „Move files around until it feels right“, und weiter: „Start by putting everything in one file; when it feels like it’s annoying, start splitting them up; when that gets annoying, maybe add some folders“. Aus meiner Sicht ist das eine sehr gute und vor allem pragmatische Herangehensweise, insbesondere da je nach Projektgröße und -entwicklung andere Strukturen sinnvoll sein können. Zu Beginn eines Projekts, wenn vielleicht noch nicht hundertprozentig klar ist, wie genau die Anwendung aussehen und funktionieren soll, kann es sehr praktisch sein, möglichst viel Code in einer Datei zu haben. So lassen sich Änderungen schnell durchführen, ohne viel in der IDE oder dem Editor hin- und hernavigieren zu müssen. Wenn die Anforderungen im Lauf der Zeit klarer, die Anwendung entsprechend stabiler oder das Entwicklerteam größer wird, kann es sinnvoll sein, große Komponenten in kleinere aufzuteilen und auch auf mehrere Dateien zu verteilen. Diese lassen sich einfacher testen und außerdem können mehrere Entwickler parallel im Code arbeiten, ohne sich in die Quere zu kommen.

Den vollständigen Artikel lesen Sie in der Ausgabe:

Java Magazin 1.19 - "Das JavaScript-Ökosystem"

Alle Infos zum Heft
579868755Tipps für den erfolgreichen Einsatz von React
X
- Gib Deinen Standort ein -
- or -