Das Problem, wenn man aus der Javascript-Welt kommt
Ich persönlich arbeite schon einige Jahre mit javascript und hab auch einige AngularJS Projekte damit umgesetzt. Typescript ist mir zwar relativ (seit ca 1,5 Jahren) neu, aber durch meinen relativ guten Sinn für modulare bzw. objekt-orientierte Programmierung, fand ich mich dort ganz gut rein. Darum gebe ich euch heute eine Einsicht, wie ich den Code der mir unter die Nägel kommt einem Refactoring unterziehe.
Wo beginnt man genau das Refactoring?
Nicht Benutzung, der Quelle von Typescript
Typescript ist, wie der Name schon sagt, ein typisierter Ansatz javascript zu entwickeln. Wenn man sich also entscheidet, solch “Sprache” in einem Projekt zu verwenden, dann sollte man doch den größten Vorteil daraus ziehen. Durch die Typisierung der Variablen, Rückgabewerten und Feldern in den Klassen, funktioniert IntelliSense von VSCode einfach nur göttlich.
Vielleicht ist es an einigen Stelle auf Faulheit, die jeweilige Klasse noch anzulegen. Es ist doch viel praktischer, wenn schon die IDE / der Editor merkt, dass die Property, die ich gerade verwenden möchte, falsch geschrieben oder verwendet wird.
Mittlerweile gibt es ja sogar generatoren, die die Klasse erstellen, wenn sie fehlt.
// Don't !!
public your_var: any;
// Do !!
public your_var: YourClass;
Methodensortierung, -verschiebung oder -wie-auch-immer
Mir ist aufgefallen, dass gerade in Komponenten, Methoden geschrieben werden, deren Logik keine direkten Auswirkungen auf die Komponente selbst haben. Warum also nicht einfach die Logik verteilen und die Komponenten schlanker und auch wartungsfähiger machen. Wer hat schon Lust, sich in eine Komponente mit 900 Zeilen einzulesen?
So wäre zum Beispiel, eine Methode aus der Komponente zu nehmen, die Beispielsweise nur eine Property von sich selber manipuliert oder ausgibt.
// component.ts
@Component()
class WebbenSampleComponent {
// Dont
private webben_user;
public onInit(){
this.changeName("webben");
}
public changeName(foo: string): void{
this.webben_user.name = foo;
}
// Better do
private webben_user;
public onInit(){
this.webben_user = new WebbenUserClass();
this.webben_user.name = "webben";
}
}
//class ts
class WebbenUserClass{
// Dont
public name: string;
// Do
public _name: string;
public get name(): string{
return this._name;
}
public set name(name: string){
this._name = name
}
}
Hier bei ist drauf zu achten, dass nur durch ein Instanzierung mit dem new Keyword die getter und setter Methoden, der Klasse verfügbar werden.
Importiere alles was geht…
Nein, bitte nicht. Ich stolpere häufig über Zeilen wie folgende, aber was bedeutet das eigentlich für die Komponente?
import * as moment from "moment";
Im Prinzip wird durch das Asterix, alle Methoden des modules “moment” mit in die lokale variable Moment kopiert aber brauchen wir das? Brauchen wir jede der unzähligen Methoden? Klar, im besten Fall, fallen die Methoden bei Treeshaking durch Webpack oder SystemJS raus. Aber wir sind in der Lage, dies zu beeinflussen. So könnte ein import Statement aussehen, wenn wir nur die Methode “toISOString()” benötigen.
import {toISOString} from "moment";
Gar nicht so schwer, oder? Schaut einfach welche Methoden ihr verwendet und import diese direkt Anstelle von allem was geht. Dies ist gerade bei größeren Libaries sinvoll wie “moment” oder “lodash”;
Beim nächsten Mal
Geht es um manuelle For-Schleifen und ich stelle diese gegenüber den neuen ES Funktionen um über Array’s zu integrieren.