React Best Practices

In dem Blogbeitrag “SharePoint Framework Client-Side Webparts mit React” wurden bereits einige Vorteile von React in der Entwicklung von SPFx Webparts aufgezeigt. Nun sollen hier ein paar Tipps und empfohlene Vorgehensweisen zusammengefasst werden.

1. Richtige Verwendung von Methoden und Konstruktor

Viele Komponenten gibt es bereits fertig und oft muss man nur kurz bei Google suchen, bis man genau die richtige Funktionalität fertig als Komponente findet. Hierbei sind mir zwei Dinge immer wieder aufgefallen: Sowohl im Konstruktor als auch in der render()-Methode wurden oft Datenabfragen ausgeführt und generell fand dort sehr viel Logik und Berechnung statt. Daher möchte ich auf die richtige Verwendung der React-Methoden und des Konstruktors hinweisen:

Im Konstruktor wird eine Instanz erzeugt. Auch die initialen Werte des State-Objekts können hier gesetzt werden. Wird ein Logger verwendet, kann dieser hier erstellt werden.

Die ComponentDidMount()-Methode wird ausgeführt, sobald die Komponente fertig erzeugt ist. Somit eignet sich diese Stelle zum Aufrufen einer Methode, welche Daten bereitstellt und verarbeitet, diese könnte z.B. “getDataAsync()” heißen. Die Verwendung dieser und anderer React-Methoden habe ich in meinem oben erwähnten Beitrag genauer erläutert.

In der render()-Methode sollte wirklich nur gerendert werden. Es spricht absolut nichts dagegen anhand von Abfragen zu entscheiden, was gerendert wird. Es können auch noch kleinere Berechnungen stattfinden, jedoch das Bereitstellen von Daten etc. hat hier nichts zu suchen.

2. Eigenständige Komponente und Ordnerstruktur

Im besten Fall können Komponenten wiederverwendet werden und müssen nicht immer neu geschrieben werden. Es gibt jedoch auch Komponenten, welche zu speziell sind und wirklich nur in einem Projekt benötigt werden. Dennoch empfiehlt es sich, die Komponenten sauber voneinander zu trennen. Es sollte pro Komponente einen Ordner mit demselben Namen geben. Ob man z.B. Komponenten in der Ordnerstruktur ineinander verschachtelt oder wie man diese genau benennt, ist jedem selbst überlassen. Dennoch sollte ein Ordner alle für die Komponente benötigten Dateien beinhalten.

Je nach Situation kann man hierbei die Interfaces für den State und die Properties in die Komponentendatei (.tsx) schreiben. Ich bevorzuge eigene Dateien für beide Interfaces. Wichtig ist jedoch, dass diese im selben Ordner liegen. Benötigt man weitere Interfaces, sollte man hierfür auch einen eigenen Unterordner (“interfaces”) erstellen. 

Wichtig ist auch eine einheitliche Benennung mit dem Namen der Komponente, so dass man sich im Code und auch beim Debuggen zurechtfindet. 

Hier ist ein Beispiel für eine Komponente mit ihrer Struktur. Es gibt Ordner für die Datei, welche die Daten bereitstellt, die Komponente, die Interfaces und die Lokalisierung. 


Ordnerstruktur einer Komponente

3. Die richtigen Komponenten verwenden

Es gibt verschiedene Arten von Komponenten. Die beiden am häufigsten verwendeten sind Class Components und Functional Components.

Der Unterschied besteht darin, dass Class Components einen State und einen Lifecycle besitzen. Sie erben von React.Component und es muss eine render()-Methode implementiert werden. Functional Components sind “stateless”, sie haben keinen State und keinen Lifecycle. Sie erhalten Properties und geben ein React Element zurück. 

Functional Component, welche ein React-Element zurückliefert
Class Component, welche einen State, zwei der Lifecycle-Methoden und einen Konstruktor besitzt. Sie implementiert die render()-Methode und gibt ein React-Element zurück.

Es wird empfohlen, so oft wie möglich statt einer Class Component eine Functional Component zu verwenden. Hierfür gibt es drei wesentliche Gründe: Es wird deutlich weniger Code benötigt, dies führt dazu, dass sie lesbarer sind, und laut React-Entwickler werden Functional Components in späteren React-Versionen deutlich performanter sein.

4. “Linting” verwenden

Unter “Linting” versteht man, seinen Code durch ein Programm oder eine Erweiterung auf Fehler bzw. selbst definierte Regeln zu überprüfen. Für TypeScript gibt es z.B. TSLint. Dies kann mit einem npm-Befehl installiert werden. 

Durch eine Konfigurationsdatei kann man selbst definieren, was im Code erlaubt ist und was nicht. Diese Definition könnte vom Software-Architekten vorgegeben werden.

Empfohlene Einstellungen sind zum Beispiel: 

  • Keine unnötigen Imports in einer Datei
  • Keine unnötigen Variablen
  • Keine unnötigen Leerzeilen bzw. Leerzeichen
  • Wenn TypeScript, dann keine Variablen ohne Typ-Bezeichnung

Mithilfe dessen wird der Code sauber gehalten und beispielsweise unnötige Zeilen Code müssen entfernt werden, da sonst – je nach Konfiguration – evtl. nicht mal kompiliert werden kann. Somit werden Entwickler gezwungen, sich an die Vorgaben zu halten.

5. Funktionen übergeben

Es gibt zwei Möglichkeiten, Funktionen an Komponenten zu übergeben. 
Entweder man übergibt die Funktion direkt in geschweiften Klammern:

onChange={(e) => {model.name = e.target.value;}}

Oder man erstellt eine eigene private Methode, welche die Logik beinhaltet und ruft diese dann nur noch auf:

onChange={this.handleChange}

Es muss je nach Situation entschieden werden, jedoch sollte man, wenn es möglich ist, gerade in React die zweite Variante wählen. Bei der ersten Möglichkeit ist das Problem, dass, wenn die äußere Komponente neu gerendert wird, zwangsläuft auch die innere Komponente, welcher die Funktion übergeben wird, neu gerendert wird, da die Funktion neu erstellt wird.

Wird allerdings die Funktion als private Methode erstellt und nur referenziert und die äußere Komponente wird neu gerendert, hat dies keine Auswirkung auf die innere, was Performance spart.

Fazit

Je nach Projekt und Anforderungen ist es nicht immer möglich, sich an die besten Vorgehensweisen zu halten, dennoch sollte man diese im Hinterkopf haben und versuchen, sich daran zu orientieren. 

By |2019-06-17T11:35:11+02:00June 17th, 2019|SharePoint|0 Comments

About the Author:

Technology Specialist

Leave a Reply

%d bloggers like this:

novaCapta verwendet Cookies, um die Funktionalität dieser Website zu verbessern. Durch die Nutzung dieser Seite stimmen Sie der Verwendung von Cookies zu. Weiterlesen

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close