React.js im Praxischeck

Keine Kommentare

React.js ist eine JavaScript-Bibliothek, die auf Konferenzen, in den Sozialen Medien und nicht zuletzt bei der codecentric zunehmend ein Thema wird. Ich hatte es immer auf dem Schirm, bisher aber eher als Nischenthema abgetan. Spätestens jetzt ist es also überfällig, mich mit React.js genauer auseinanderzusetzen.

Spannend finde ich vor allem die Frage: Wann macht es für ein Projekt Sinn, React.js einzusetzen? Und daran anschließend:

  • Welches Problem löst React.js für mich?
  • Wie reif ist die Bibliothek?
  • Wie steht es um die Community, die Dokumentation etc.?
  • Ist der resultierende Code wartbar und gut testbar?
  • Wie sieht die Integration in bestehende Applikationen aus und wie gut kann ich 3rd-Party-Artefakte integrieren?
  • Welche Toolunterstützung steht dem Entwickler zur Verfügung?

Am Ende des Artikels hoffe ich, dass Du React.js etwas besser einordnen kannst und beurteilen kannst, unter welchen Umständen React was für Dich ist.

Um das Ganze noch ein wenig anschaulicher zu gestalten, habe ich eine kleine Beispielanwendung gebaut,an der ich einige Konzepte erläutern möchte.
Die Anwendung findet man unter http://soccerreact.herokuapp.com/ und den Sourcecode gibt es unter https://github.com/holgergp/soccerReact
In der Anwendung ist eine Bundesligatabelle nachgebaut, in der man selbst die Vereine hin und herschieben kann. Den ein oder anderen mag das vielleicht an die Beilage aus einem Fußballmagazin erinnern. Das ist reiner Zufall! 😉
screenshotSoccerReact
Als Bonus kann man die Vereinsnamen noch ändern, in dem man einfach auf den Namen klickt. So kann die Tabelle auch nächste Saison noch aktuell gehalten werden 😉
Richtige Persistenz würde den Scope dieses Artikels sprengen. Der Einfachheit halber werden die anfallenden Daten nur clientseitig im Local Storage gehalten.

Also steigen wir doch gleich mal ein:

Wie reif ist React.js?

React.js wurde 2013 von Facebook ins Leben gerufen. Die Bibliothek ist u.a. auch bei Facebook selber im Einsatz und steht unter einer BSD-Lizenz. Somit kann man React.js schon eine gewisse Produktionsreife unterstellen. Obwohl, wie der Schwenk von AngularJS 1.x auf AngularJS 2.x gezeigt hat, das Backing von einem großen Konzern leider nicht viel heißen muss.

Welches Problem löst React.js für mich?

React.js ist, ähnlich wie AngularJS, eine cllientseitige Javascript-Bibliothek.
Der Vergleich hinkt allerdings etwas. Wo AngularJS eine MVC-Struktur abbildet (ob das jetzt gut oder schlecht ist, möchte ich an dieser Stelle nicht diskutieren :)), unterstützt React.js den Entwickler „nur“ beim V (der View) seiner Applikation. Weiter treiben kann man es dann mit der so genannten FLUX-Architektur, in der Komponenten über einen unidirektionalen Kommunikationsfluss über Actions und Stores miteinander kommunizieren.. FLUX werde ich in diesem Artikel allerdings nicht beleuchten, dies würde schlicht zu weit führen.

Was macht React.js jetzt anders in der View-Schicht?
Aus der Sicht der React-Entwickler ist es schlecht, zu viele Stellen in seiner Anwendung zu haben, die den State einer Anwendung verändern können. Two-way-Databinding ist so ein Beispiel. In größeren Anwendungen ist es zuweilen schwierig zu erkennen, wo Datenänderungen ihren Ursprung haben. In einer React.js Applikation wird forciert, dass es nur eine (oder wenige) Stellen gibt, an der State gehalten und verändert werden kann. Der Inhalt dieses States kann dann immutable in der Anwendung weiter verarbeitet werden.
React.js hat den Ruf, schnell zu sein, besonders im Vergleich zu Angular, und auch mit größeren Datenmengen gut klarzukommen. Das liegt daran, dass im Kern alle State-Änderungen über eine Virtual DOM Implementierung vorgehalten werden und somit der Unterschied von zwei State-Änderungen effizient erkannt werden kann und nur das Ergebnis dieses Diffs in den DOM übertragen wird . Als Entwickler bekommt man hiervon allerdings nichts mit.

Des Weiteren besteht eine React-Applikation konsequenterweise aus „Komponenten“, also für sich eigenständige Applikationsteile. Hierfür verwendet React einen hierarchischen Ansatz, wobei der State oft in der Wurzel meines Komponentenbaums verortet ist.
Es bietet sich deshalb an, die Anwendung zuerst auf dem Papier in Bereiche (Komponenten) aufzuteilen und den Datefluss zu definieren bevor mit dem Coding begonnen wird. Wie das geht schauen wir uns später genauer an.

Holger Grosse-Plankermann

Holger Grosse-Plankermann ist seit 2015 für die codecentric als Senior Consultant und Senior Developer tätig. Gerne entwickelt und entwirft er gut testbare Software und bewegt sich dabei sowohl im Backend als auch im Frontend. Holger nutzt dabei oft den Java EE/Spring Stack und ist zudem ein Verfechter von JavaScript- und Web-Technologien.
Er hält immer Ausschau nach innovativen Lösungen für Kundenprobleme. Sein aktuelles Interesse gilt dem Bereich der funktionalen Programmierung, und er bleibt im Bereich JavaScript-Frameworks immer am Ball.

Share on FacebookGoogle+Share on LinkedInTweet about this on TwitterShare on RedditDigg thisShare on StumbleUpon

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.