Jedną z głównych myśli przewodnich Typescripta jest to, by wyłapywać część błędów już na etapie samego pisania kodu (i/lub jego transpilacji). TS nie jest w tej kwestii zero-jedynkowy. W zależności od obranego podejścia może on być dość liberalny (w szczególności traktować każdy czysty JSowy kod jako prawidłowy TSowy kod), ale też, modyfikując w odpowiedni sposób konfigurację kompilatora, dostępne mamy szerokie spektrum poziomu restrykcyjności dla transpilowanego kodu. Podobnymi zasadami kieruje się również proces kompilacji Angularowych widoków (a właściwie szablonów widoków).
Motywacją do powstania niniejszego artykułu jest chęć zebrania informacji na temat wszystkich najważniejszych możliwych ustawień restrykcji kompilacji dla angularowego projektu w jednym miejscu. W szczególności dla każdej opcji z osobna przedstawiony będzie zwięzły opis restrykcji oraz przykładowy fragment kodu, na który dana restrykcja ma wpływ. Informacje zebrane poniżej są w ogólności dostępne w dokumentacjach Angulara i Typescripta, jednak w sporej części przypadków nie są one klarownie zaprezentowane i brak im przykładów (no i nie są też dostępne w języku polskim).
W obecnie najnowszej wersji Angulara (v12) strict mode stał się opcją domyślnie włączoną przy generowaniu nowego projektu za pomocą CLI (dla starszych wersji wymagana była dodatkowa flaga strict), więc to kolejny dobry powód, by pochylić się na chwilę nad dostępnymi dla nas opcjami.
W tym artykule pojęcia kompilacji i transpilacji będą stosowane zamiennie i oznaczać będą to samo (w kontekście omawianych treści).
Spis treści
- Czym jest Angular strict mode?
- Jaki jest cel Angular strict mode?
- Elementy składowe strict mode w Typescript’cie
- Dodatkowe restrykcje TS nie wchodzące w skład strict mode
- Restrykcje dla kompilacji szablonów widoków Angularowych
- Tryb podstawowy (basic)
- Tryb pełnej weryfikacji (full mode)
- Tryb restrykcyjnej weryfikacji (strict mode)
- strictInputTypes
- strictInputAccessModifiers
- strictNullInputTypes
- strictAttributeTypes
- strictSafeNavigationTypes
- strictDomLocalRefTypes
- strictOutputEventTypes
- strictDomEventTypes
- strictContextGenerics
- strictLiteralTypes
- Podsumowanie
- Automatyzacja
Czym jest Angular strict mode?
Angular strict mode to tryb uruchamiający zaostrzone restrykcje w czasie developmentu aplikacji. Składają się na to:
- strict mode w Typescript’cie (szczegóły), a więc włączenie szeregu dostępnych restrykcji dla kompilatora TSa,
- włączenie szeregu restrykcji dla szablonów angularowych widoków (restrykcje dla Angular View Engine Compilator),
- obniżenie wartości “bundle size budgets” w porównaniu do domyślnych ustawień Angulara.
Jaki jest cel Angular strict mode?
Kod spełniający dodatkowe restrykcje jest podatny na dokładniejszą statyczną analizę kodu (a więc jesteśmy w stanie wyłapać więcej błędów jeszcze w trakcie pisania kodu). W ogólności projekt staje się łatwiejszy do rozwoju i utrzymania. Ograniczamy też liczbę błędów, które pojawić mogłyby się dopiero w trakcie działania aplikacji.
W dokumentacji Angulara znajdziemy również informację, że dla projektów rozwijanych w strict mode skorzystanie z ng update do automatycznego aktualizowania wersji frameworka jest bardziej precyzyjne i bezpieczniejsze.
Elementy składowe strict mode w Typescript’cie
Konfiguracja kompilatora języka Typescript zawiera opcję “strict”, której włączenie równoważne jest z włączeniem szeregu flag odpowiadających za dodanie dodatkowych restrykcji w trakcie transpilacji kodu. Możemy zarówno włączyć pełen strict mode, jak i uruchamiać tylko pojedyncze flagi (wedle potrzeby). W skład flag strict mode wchodzą:
strictBindCallApply
Włączenie tej flagi powoduje, że weryfikowana będzie zgodność typów argumentów przy użyciu wbudowanych w Javascript funkcji:
Przykład bez włączonej flagi (transpilacja przechodzi):
|
1 2 3 4 5 6 7 8 9 10 |
fetchProduct(productId: number): void { this.httpClient.get<Product>(`/products/${productId}`).subscribe({ next: this.fetchProductSuccessHandler.bind(this), error: this.fetchProductFailHandler.bind(this) }) } fetchProductSuccessHandler(product: number /** invalid product type **/): void { // foo } |
Rezultat z włączoną flagą (błąd transpilacji):
|
1 2 3 |
Type '(product: number) => void' is not assignable to type '(value: Product) => void'. Types of parameters 'product' and 'value' are incompatible. Type 'Product' is not assignable to type 'number'. |
Rekomendacja: zawsze korzystać z flagi strictBindCallApply.
strictFunctionTypes
Dokumentacja dotycząca tej flagi jest mocno nieprecyzyjna i mówi jedynie o dokładniejszej weryfikacji typów argumentów funkcji. Dokładniejsze wyjaśnienie możemy znaleźć m.in. w książce “Typescript na poważnie” Michała Miszczyszyna, w której napisane zostało, że po włączeniu flagi argumenty funkcji nie mogą być biwariantne.
Czym są typy biwariantne? To również temat, który jest szeroko wyjaśniony we wspomnianej książce, a jego podsumowanie zawiera się w cytacie:
Biwariancja: w miejscu typu X można użyć zarówno typu pochodnego, jak i nadrzędnego
Przykład bez włączonej flagi (transpilacja przechodzi):
|
1 2 3 4 5 6 7 |
function printStringLowercase(value: string): void { console.log(value.toLowerCase()); } type printSomething = (value: string | number) => void; const printSomethingFn: printSomething = printStringLowercase; printSomethingFn(12); // runtime error |
Rezultat z włączoną flagą (błąd transpilacji):
|
1 2 |
Type 'string | number' is not assignable to type 'string'. Type 'number' is not assignable to type 'string'. |
Inny przykład (bez flagi):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
interface Vehicle { numberOfWheels: number; } interface Car extends Vehicle { brand: string; } const vehicle: Vehicle = { numberOfWheels: 2}; const car: Car = {numberOfWheels: 4, brand: 'bmw'}; type driveFnType = (car: Vehicle | Car) => void; function drive(car: Car): void { console.log(car.brand.toUpperCase()) } const typedDriveFn: driveFnType = drive; typedDriveFn(vehicle); typedDriveFn(car); |
Rezultat z włączoną flagą (błąd transpilacji):
|
1 2 3 |
Type '(car: Car) => void' is not assignable to type 'driveFnType'. Types of parameters 'car' and 'car' are incompatible. Type 'Vehicle | Car' is not assignable to type 'Car'. |
Więcej informacji o typowaniu funkcji w Typescript’cie znajduje się tutaj. Więcej informacji o biwariancji (i wielu innych interesujących rzeczach) znajduje się w tej książce.
Rekomendacja: zawsze korzystać z flagi <strong>strictFunctionTypes.
strictNullChecks
Jest to prawdopodobnie jedna z flag wnoszących najwięcej zmian w pisanym na co dzień kodzie. Jak tłumaczy dokumentacja:
- przy wyłączonej fladze typy null oraz undefined są ignorowane przez interpreter,
- przy włączonej fladze typy null oraz undefined są rozróżnialne, dzięki czemu Typescript rozpozna wszystkie przypadki, w których te wartości mogą się pojawić.
Przykład bez włączonej flagi (kompilacja przechodzi):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
interface Product { id: number; model: string | undefined; brand: string | null; colors: string[]; } const product: Product = { id: 1, model: undefined, brand: null, colors: ['red', 'green', 'blue'] } const modelLength = product.model.length; // runtime error const brandLength = product.brand.length; // runtime error const yellowColorLength = product.colors.find(color => color ==='yellow').length; // runtime error |
Rezultat z włączoną flagą (błąd transpilacji dla wszystkich 3 zadeklarowanych stałych):
|
1 2 3 |
[...] Object is possibly 'undefined'. [...] Object is possibly 'null'. [...] Object is possibly 'undefined'. |
Innym korzystnym skutkiem ubocznym jest również wykrywanie wartości, które mogły nie zostać jeszcze zainicjalizowane. Przykład:
|
1 2 |
let productName: string; console.log(productName.toLowerCase()); // runtime error |
Rezultat z włączoną flagą (błąd transpilacji):
|
1 |
Variable 'productName' is used before being assigned. |
Innymi słowy flaga ta wprowadza wsparcie interpretera Typescripta dla wartości null’owalnych (ang. nullish, tj. mogące przyjąć wartość null lub undefined). Nowsze wersje języka zawierają dodatkową składnie, która służy właśnie do obchodzenia się z tego typu wartościami:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 |
const colors = ['RED', 'GREEN', 'BLUE']; const myFavouriteColor = colors.find(color => color.toLowerCase() === 'yellow'); // myFavouriteColor has 'string | undefined' type if(myFavouriteColor) { // typescript inherited that in that scope // myFavouriteColor is defined console.log(myFavouriteColor.toUpperCase()); } // unsafe property access, runtime exception possible console.log(myFavouriteColor!.toLowerCase()); // safe property access // (method will be called only if myFavouriteColor is defined) console.log(myFavouriteColor?.toLowerCase()) |
Więcej informacji o sposobach na obchodzenie się z wartościami null’owalnymi można znaleźć tutaj:
Więcej informacji o samym nullish znajduje się tutaj.
Rekomendacja: W razie możliwości (a w szczególności przy tworzeniu nowego projektu) gorąco zachęcamy do korzystania z tej flagi.
strictPropertyInitialization
Włączenie tej flagi wymaga uprzedniego włączenia “strictNullChecks”. W przeciwnym przypadku otrzymamy błąd:
|
1 |
Error: error TS5052: Option 'strictPropertyInitialization' cannot be specified without specifying option 'strictNullChecks'. |
Włączenie tej flagi stwarza konieczność inicjalizowania (przypisywania wartości) wszystkim atrybutom klasy w miejscu ich deklaracji lub w konstruktorze (nie jest możliwe inicjalizowanie tych wartości w metodzie wywołanej bezpośrednio w konstruktorze).
Spójrzmy na poniższy przykład (bez włączonej flagi):
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
@Component({ selector: 'app-product', template: ` <p #productName [class.collapsed]="collapsed" > {{ product?.name }}</p> `, changeDetection: ChangeDetectionStrategy.OnPush, }) export class ProductComponent implements AfterViewInit { @Input() product: ProductDetails; @ViewChild('productName') productNameRef: ElementRef<HTMLParagraphElement>; collapsed: boolean; ngAfterViewInit(): void { console.log(this.product.name); // ok if product has been passed via input console.log(this.productNameRef.nativeElement); // ok if html element with given angular selector exists this.collapsed = false; // expand element } } |
Transpilacja takiego kodu odbędzie się pomyślnie. Zakładając, że za pomocą angularowego Input’a produkt jest przekazany do tego komponentu wszystkie console logi wykonają się poprawnie (nie nastąpi żaden błąd).
Jest to typowy przykład z życia Angularowego komponentu, gdzie wartości ustawiane za pomocą @Input, @ViewChild i tym podobnych nie są dostępne w momencie tworzenia instancji klasy komponentu, natomiast stają się dostępne na pewnym etapie życia komponentu (np. AfterViewInit dla @ViewChild). Więcej o cyklu życia Angularowego komponentu znajduje się tutaj.
Co się stanie, gdy włączymy flagę ’strictPropertyInitialization’?
|
1 2 3 |
Property 'product' has no initializer and is not definitely assigned in the constructor. Property 'productNameRef' has no initializer and is not definitely assigned in the constructor. Property 'collapsed' has no initializer and is not definitely assigned in the constructor. |
Zgodnie z przypuszczeniami kod nie przechodzi pomyślnie przez proces kompilacji. W przypadku, w którym nie ma możliwości inicjalizacji wartości w momencie tworzenia instancji klasy istnieją dwa rozwiązania:
- zmiana typów pól na nullowalne,
- wykorzystanie non-null assertion operator,
W przypadku opcji pierwszej (nullish)
|
1 2 3 |
@Input() product?: ProductDetails; @ViewChild('productName') productNameRef?: ElementRef<HTMLParagraphElement>; collapsed?: boolean; |
powstaje konieczność obchodzenia się z tymi wartościami jak z nullowalnymi w każdym miejscu, w jakim z nich korzystamy (np. za pomocą optional chaining). Jest to opcja bezpieczna, ale zwiększająca potrzebny nakład pracy.
W przypadku opcji drugiej (non-null assertion)
|
1 2 3 |
@Input() product!: ProductDetails; @ViewChild('productName') productNameRef!: ElementRef<HTMLParagraphElement>; collapsed!: boolean; |
programista bierze odpowiedzialność za to, że te wartości zostaną w odpowiednim momencie zainicjalizowane, a do tego czasu nie nastąpi próba odwołania się do ich wartości.
Rozwiązania te można połączyć, tj. typy ustawić na nullowalne, a w przypadku odwoływania się do wartości (i pewności, że są one już ustawione!) skorzystać z non-null assertion.
Rekomendacja: W przypadku skorzystania z tej flagi zalecamy stosowanie podejścia z nullowalnymi typami i unikanie korzystania z non-null assertion.
useUnknownInCatchVariables
Ta flaga dostępna jest w Typescripcie od wersji 4.4. W momencie pisania tego artykułu najnowsza wersja Angulara (12.1.1) nie wspiera jeszcze TS 4.4+.
Przed włączeniem tej flagi w bloku try-catch error był typowany jako ‘any’ i nie było możliwości zmiany tego (ponieważ sam JS pozwala rzucać dowolne wartości jako wyjątki).
|
1 2 3 4 5 6 7 8 9 10 11 |
function parseJsonToUser(json: string): User | undefined { try { const { id, name }: { id: number, name: string} = JSON.parse(json); return new User({ id, name }); } catch (error) { // 'error' variable has 'any' type here console.error(error.message.details.property.foo); // accessing properties of error might cause another runtime exception } } |
Po włączeniu flagi ta sama zmienna ‘error’ otypowana jest jako ‘unknown’, przez co dostajemy błąd transpilacji:
|
1 |
Property 'message' does not exist on type 'unknown'. |
Niezależnie od ustawienia flagi, od TS 4.4 error będziemy mogli otypować jawnie jako “any” lub “unknown”. Flaga wpływa wyłącznie na domyślny typ.
Więcej informacji o tym jak radzić sobie z typem unknown znajduje się tutaj.
Rekomendacja: Polecamy korzystać z tej flagi gdy tylko zaczniesz korzystać z Typescripta w wersji 4.4+.
Dodatkowe restrykcje TS nie wchodzące w skład strict mode
Konfiguracja kompilatora języka Typescript zawiera też szereg innych interesujących reguł implementujących dodatkowe restrykcje:
allowUnreachableCode
Jest to jedna z flag, która dla wartości false, nakłada większe restrykcje, niż przy wartości true. W zależności od wartości tej flagi:
- dla wartości true nadmiarowy kod, który nigdy nie zostanie wykonany, jest ignorowany,
- dla undefined (wartość domyślna) interpreter Typescripta w taki sam sposób (jak w przypadku true) ignoruje ten kod, ale zapewnia wsparcie przy wyświetlaniu warningów w edytorze kodu. Popularne IDE generują warningi również przy fladze ustawionej na true,
- dla wartości false kod, który nigdy nie zostanie wykonany powoduje błąd kompilacji.
Przykład (z flagą ustawioną na true kompilacja się powiedzie):
|
1 2 3 4 5 6 7 8 9 |
function getArrayLength(array: Array<any> | null | undefined): number { if (Array.isArray(array)) { return array.length; } else { return 0; } // unreachable code return 5; } |
Z flagą ustawioną na false:
|
1 |
Unreachable code detected. |
Rekomendacja: Flagę ustawić na false, o ile nie mamy do czynienia z legacy kodem, przy którym jest to kłopotliwe.
allowUnusedLabels
Etykiety (labels) to rzadko spotykany i używany element składni Javascriptu (a więc i Typescriptu) współpracujący z poleceniami break i continue, pozwalający identyfikować pętle za pomocą nadanych im nazw (etykiet) i przerywać/kontynuować ich wykonywanie (odwołując się do konkretnej pętli, nawet w przypadku zagnieżdżenia pętli w pętli).
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
function isInMatrix(matrix: string[][], term: string): boolean { loopOverX: for (let x = 0; x < matrix.length; x++) { // loop labeled as loopOverX const rowLength = matrix[x].length; loopOverY: for(let y = 0; y < rowLength; y++) { // loop labeled as loopOverY if(matrix[x][y] === 'foo') { break loopOverX; } if(matrix[x][y] === 'bar') { continue loopOverY; } if(matrix[x][y] === term) { return true; } } } return false; } |
Javascript/Typescript pozwala nam zdefiniować etykietę w niemalże dowolnym miejscu (co oczywiście z reguły nie ma sensu i powinno być automatycznie uznane za błąd):
|
1 2 3 4 5 6 |
function printUser(user: User): void { label1: label2: label3: console.log(`hello ${user.firstName} ${user.lastName}`); } |
Przy włączonej restrykcji (wartość flagi ustawiona na false) przy każdej nadmiarowo zdefiniowanej etykiecie otrzymujemy błąd:
|
1 |
Unused label. |
Ciekawostka: wracając do powyższego przykładu funkcji isInMatrix – etykieta (loopOverY) jest opcjonalna, poniewaz jej pominięcie przy komendach break/continue i tak skutkować będzie przerwaniem/kontynuowaniem wykonywania najbardziej zagnieżdżonej pętli. W tym jednak przypadku Typescript pozwala zachować nam tę etykietę (co naszym zdaniem poprawia czytelność, gdy już decydujemy się skorzystać z etykiet w zagnieżdżonych pętlach.
Rekomendacja: Flagę ustawić na false. Z etykiet korzystać wyłącznie w przypadku zagnieżdżonych pętli i potrzeby przerywania/kontynuowania wykonywania ich kolejnych iteracji.
alwaysStrict
Ta flaga nie ma bezpośredniego wpływu na kod pisany w Typescripcie, natomiast sprawia ona, że wszystkie pliki kompilowane są do Javascriptu z wykorzystaniem Ecmascript strict mode. Sam Ecmascript strict mode jest materiałem na osobny artykuł, jednak w wielkim skrócie:
- do każdego pliku *.js dodawany jest prefix “use strict”
- większość silników Javascriptowych (tj. wszystkie kompatybilne z tym trybem) interpretują kod JS w sposób bardziej restrykcyjny (w trakcie runtime), m.in. część błędów, które w trybie “normalnym” zostałyby zignorowane w tym przypadku zostają rzucone
exactOptionalPropertyTypes
Ta flaga dostępna jest w Typescripcie od wersji 4.4. W momencie pisania tego artykułu najnowsza wersja Angulara (12.1.1) nie wspiera jeszcze TS 4.4+.
Aby wyjaśnić zasadność tej flagi nakreślmy pewien kontekst:
|
1 2 3 4 5 6 |
type ApplicationSettings { theme?: 'Dark' | 'Light' } const settingsA: ApplicationSettings = {}; const settingsB: ApplicationSettings = { theme: undefined } |
Obiekt ustawień aplikacji (typu ApplicationSettings) posiada pole theme, które może przyjmować wartości: ‘Dark’, ‘Light’ lub undefined. Na dwa różne sposoby definiujemy obiekty settingsA i settingsB. W pierwszym przypadku pomijamy klucz ‘theme’, natomiast w drugim jawnie nadajemy mu wartość undefined. W znakomitej większości przypadków pole theme obu obiektów będzie interpretowane w ten sam sposób:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 |
function applySettings(settings: ApplicationSettings): void { if(settings.theme) { // same result for both } if(!settings.theme) { // same result for both } if(settings.theme === undefined) { // same result for both } if(typeof settings.theme === "undefined") { // same result for both } if(settings.theme == null) { // same result for both } const theme = settings.theme; // same result for both } |
Są jednak przypadki, w których oba obiekty będą interpretowane w odmienny sposób:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
function applySettings(settings: ApplicationSettings): void { if("theme" in settings) { // different behavior } if(Object.keys(settings).includes("theme")) { // different behavior } if(settings.hasOwnProperty("theme")) { // different behavior } } |
Sam console.log w jasny sposób pokazuje nam różnice:
|
1 2 |
"settingsA": {} "settingsB": { "theme": undefined } |
W celu uniknięcia tego typu rozbieżności w Typescripcie 4.4 wprowadzono flagę 'exactOptionalPropertyTypes’. Jej zadaniem jest uniemożliwienie jawnego definiowania pól opcjonalnych wartością undefined (tak aby w przypadku braku wartości w polu opcjonalnym w obiekcie wynikowym nie było zdefiniowanego klucza dla tej wartości).
Przed włączeniem flagi (kompilacja przechodzi pomyślnie):
|
1 2 3 4 5 6 |
type ApplicationSettings { theme?: 'Dark' | 'Light' } const settingsA: ApplicationSettings = {}; const settingsB: ApplicationSettings = { theme: undefined } |
Po włączeniu flagi (mimo wciąż opcjonalnego pola theme):
|
1 |
Type 'undefined' is not assignable to type '"Dark" | "Light"'. |
Rekomendacja: Polecamy korzystać z tej flagi gdy tylko zaczniesz korzystać z Typescripta w wersji 4.4+.
noFallthroughCasesInSwitch
Włączenie tej flagi powoduje, że każdy przypadek (case) w switch/case, który posiada jakiekolwiek instrukcje do wykonania (grupowanie kilku przypadków jeden po drugim jest nadal dopuszczalne) musi kończyć się słowem kluczowym break lub return (w przypadku, gdy switch/case znajduje się wewnątrz funkcji).
Przykład bez włączonej flagi (kompilacja przechodzi):
|
1 2 3 4 5 6 7 8 9 10 |
type Color = 'red' | 'green' | 'yellow'; function applyColor(color: Color): void { switch(color) { case 'yellow': console.log(color); // missing 'break' statement case 'green': return; } } |
W przypadku włączenia flagi 'noFallthroughCasesInSwitch’ otrzymujemy następujący błąd:
|
1 |
Fallthrough case in switch. |
Flaga ta ma pomagać uniknąć przypadkowego pominięcia słów kluczowych break i/lub return.
Rekomendacja: Włączyć flagę noFallthroughCasesInSwitch.
noImplicitAny
W języku Typescript, gdy nie zdefiniujemy typu jawnie, interpreter usiłuje wywnioskować go z kontekstu. W przypadku, w którym nie uda się w żaden sposób zawęzić możliwego typu przyjmuje on wartość any.
Włączona flaga noImplicitAny powoduje, że niemożność wywnioskowania typu z kontekstu i brak jawnego zdefiniowania typu przez programistę skutkuje błędem kompilacji.
Przykład bez włączonej flagi:
|
1 2 3 4 |
function print(value): void { // "value" argument has "any" type here console.log(value); } |
Włączenie flagi powoduje w tym miejscu błąd:
|
1 |
Parameter 'value' implicitly has an 'any' type. |
Rekomendacja: Zalecamy korzystać z tej flagi w każdym projekcie. Należy zwrócić uwagę na konieczność zdefiniowania typów dla bibliotek zewnętrznych, które nie posiadają typowania.
noImplicitOverride
Jest to flaga, która wraz z nowym słowem kluczowym override pojawiła się w Typescript’cie 4.3+. W przypadku jej włączenia każde nadpisanie metody lub pola w klasie dziedziczącej musi zostać jawnie poprzedzone słówkiem override. Dzięki temu możemy uniknąć sytuacji, w której np. zmienimy nazwę metody w klasie macierzystej bez zmiany nazwy w klasach po niej dziedziczących.
Przykład bez włączonej flagi:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
class Car { honk(): void {} } class SportsCar extends Car { override honk(): void {} } class DeliveryCar extends Car { // missing override keyword honk(): void {} } |
Błąd po włączeniu flagi:
|
1 |
This member must have an 'override' modifier because it overrides a member in the base class 'Car'. |
Rekomendacja: Włączyć flagę i zawsze korzystać ze słówka override.
noImplicitReturns
Po włączeniu tej flagi dla każdej funkcji weryfikowane są wszystkie możliwe ścieżki kodu. Jeśli któraś ze ścieżek nie zwraca zadeklarowanego typu (lub w przypadku braku zadeklarowania zwracanego typu część ścieżek zwraca “coś”, a część nie) rzucany jest błąd.
Przykład bez włączonej flagi:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 |
function getDateLabel(date: Date | null): string { if(date) { return date.toLocaleDateString('en-US') } // missing return statement when date is null } function getPageTitle(platform: 'android' | 'ios' | 'web'): string { switch(platform) { case 'android': return 'Hello android!' case 'ios': return 'Hello ios!' // missing 'web' case and/or default case } } function isAdult(age: number): boolean { if (age >= 18) { return true; } false; // missing 'return' statement } |
Po włączeniu flagi dla każdej z powyższych funkcji otrzymy błąd:
|
1 |
Not all code paths return a value |
Taki sam błąd powstaje w przypadku, w którym nie definiujemy jawnie zwracanego typu i pozwalamy zrobić to Typescriptowi, ale jednocześnie nie wszystkie ścieżki zwracają jakąkolwiek wartość.
Rekomendacja: Zawsze korzystać z flagi noImplicitReturns.
noImplicitThis
Przy włączonej fladze błąd zostaje rzucony, gdy nie zdefiniujemy jawnie typu dla “this”, a Typescript nie jest w stanie wywnioskować jego typu z kontekstu.
Rzućmy okiem na błędny przykład:
|
1 2 3 4 5 6 7 8 9 10 |
class ComplexValidator { private static DEFAULT_MINIMUM_ARRAY_LENGTH = 10; static minimumArrayLengthValidator(minimumArrayLength?: number): ValidatorFn { return function(control: AbstractControl): ValidationErrors | null { const controlValue = control.value; const minValue = minimumArrayLength ?? this.DEFAULT_MINIMUM_ARRAY_LENGTH; return (Array.isArray(controlValue) && controlValue.length < minValue) ? { minArrayLength: true } : null; } } } |
Mamy tutaj metodę, która zawiera w sobie zdefiniowaną nową funkcję (klasyczną, nie “arrow-function”, a więc wartość “this” zmienia się w zależności od kontekstu/sposobu wywołania tej funkcji).
Po włączeniu flagi słusznie otrzymamy błąd:
|
1 |
'this' implicitly has type 'any' because it does not have a type annotation. |
Dla przypomnienia parametr “this” możemy typować jawnie, dzięki czemu np. otypowane w taki sposób funkcje można wywołać tylko w konkretnym kontekście. Dorzućmy flagę “strictBindCallApply”, która pozwoli nam swobodnie podmieniać typy wraz z restrykcyjną weryfikacją tychże.
|
1 2 3 4 5 6 7 8 9 10 11 12 |
class Car { honk(): void { console.log('honk honk'); } } function withTypedThis(this: Car, name: string): void {} // ok withTypedThis.call(new Car(), 'foo'); // Argument of type 'Date' is not assignable to parameter of type 'Car' withTypedThis.call(new Date(), 'bar'); |
Rekomendacja: Zawsze korzystać z flagi noImplicitThis.
noPropertyAccessFromIndexSignature
Jeżeli część pól otypujemy za pomocą “index signature” to wówczas, bez włączonej flagi, możemy odwoływać się za pomocą kropki (np. “foo.bar”) do dowolnych pól, nawet, jeśli nie są one zdefiniowane:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 |
interface HeaderStyles { // two most important style properties that have to be set height: string; display: 'block' | 'none'; // other styles [key: string]: string; } const styles: HeaderStyles = { height: '60px', display: 'block', padding: '10px' } const display = styles.display; const display2 = styles['display']; const padding = styles.padding; const padding2 = styles['padding']; const margin = styles.margin; const margin2 = styles['margin']; |
Po włączeniu flagi “noPropertyAccessFromIndexSignature” do atrybutów zdefiniowanych za pomocą “index signature” możemy uzyskać dostęp wyłącznie za pomocą “index signature”. Dzięki temu za pomocą “kropki” nigdy nie odwołamy się do pól, które mogą być niezdefiniowane.
Błędy kompilacji po włączeniu flagi:
|
1 2 |
Property 'padding' comes from an index signature, so it must be accessed with ['padding']. Property 'margin' comes from an index signature, so it must be accessed with ['margin']. |
Rekomendacja: Zawsze korzystać z flagi noPropertyAccessFromIndexSignature.
noUncheckedIndexedAccess
Ta flaga współpracuje w połączeniu z flagą “strictNullChecks” i powoduje, że do pól, które otypowane są za pomocą “index signature” jako typ “X” zwracany jest typ “X | undefined”.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
interface HeaderStyles { // two most important style properties that have to be set height: string; display: 'block' | 'none'; // other styles [key: string]: string; } const styles: HeaderStyles = { height: '60px', display: 'block', padding: '10px' } styles.padding.toUpperCase(); |
Błąd kompilacji po włączeniu flagi:
|
1 |
Object is possibly 'undefined'. |
Rekomendacja: Zawsze korzystać z flagi noUncheckedIndexedAccess.
noUnusedLocals
Zasada działania jest dość prosta – nieużyte zadeklarowane zmienne lokalne wywołują błąd. Warto zwrócić uwagę, że tyczy się to również nieużytych zaimportowanych do pliku modułów.
Przykład pliku z nieużytymi zadeklarowanymi zmiennymi:
|
1 2 3 4 5 6 |
import { Input } from '@angular/core'; function sayHello(): void { const applicationName = 'Foo'; console.log(`Hello Foo`); } |
Błędy kompilacji po włączeniu flagi:
|
1 2 |
'Input' is declared but its value is never read. 'applicationName' is declared but its value is never read. |
Rekomendacja: Zachęcamy do spróbowania. Bardzo przydatne okazują się narzędzia do usuwania nieużytych importów (np. domyślnie Ctrl+Alt+O w Webstormie).
noUnusedParameters
Podobnie jak w przypadku “noUnusedLocals” niedozwolone stają się zadeklarowane, ale nieużyte argumenty funkcji.
Przykład funkcji z nieużytym argumentem:
|
1 2 3 |
function sayHello(applicationName: string): void { console.log(`Hello Foo`); } |
Błąd kompilacji po włączeniu flagi:
|
1 |
'applicationName' is declared but its value is never read. |
Rekomendacja: Zawsze korzystać z tej flagi, ponieważ pozbywamy się zbędnych argumentów, co m.in. w wyraźny sposób poprawia czytelność kodu.
Restrykcje dla kompilacji szablonów widoków Angularowych
Zacznijmy od tego, że w ramach opcji kompilatora szablonów widoków Angularowych dostępne są aż 3 tryby weryfikacji typów zmiennych użytych w szablonach. Prezentują się one następująco:
Tryb podstawowy (basic):
w takim trybie pracujemy przy następującym ustawieniu flag (fragment tsconfig.json):
|
1 2 3 4 5 |
"angularCompilerOptions": { "fullTemplateTypeCheck": false, "strictTemplates": false, ... } |
Odwołując się do zmiennych sprawdzane jest jedynie to, czy te zmienne istnieją (są polami klasy komponentu) oraz czy posiadają pola, do których się odwołujemy. Przykładowo:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
@Component({ selector: 'app-child', template: '<div> {{ street.houseNumbers.length }}</div>', }) export class ChildComponent { @Input() street: { houseNumbers: number[], length: number} } @Component({ selector: 'app-root', template: ` <app-child [street]="user.address.city"></app-child>` }) export class AppComponent { user = { address: { city: 'foo' } } } |
Weryfikowane są następujące rzeczy:
- czy “user” jest polem w klasie komponentu,
- czy “user” jest obiektem z polem “address”,
- czy “address” jest obiektem z polem “city”.
Nie weryfikowane jest czy typ “user.address.city” jest zgodny z typem inputa “street” w komponencie “app-child” (nie jest). Kompilacja się powiedzie, ale w trakcie runtime wystąpi błąd:
|
1 |
Cannot read property 'length' of undefined |
Rzeczy, które dodatkowo nie są weryfikowane na etapie kompilacji w tym trybie:
- zmienne w widokach “embedded” (np. zmienne użyte w *ngIf, *ngFor, <ng-template> mają zawsze typ “any”). Poniższy przykład przechodzi przez proces kompilacji, zmienne “fruit” oraz “user” mają typ “any”.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
@Component({ selector: 'app-root', template: ` <div *ngFor="let fruit of fruits"> {{ fruit.foo.bar.baz }} {{ user.foo.bar.baz }} </div> ` }) export class AppComponent { fruits = ['apple', 'banana'] user = { firstName: 'foo' } } |
- typy referencji (#refs), wartości zwracanych przez pipes, typy wartości $event emitowane przez wszelkie outputy mają zawsze typ “any”.
Tryb pełnej weryfikacji (full mode):
w takim trybie pracujemy przy następującym ustawieniu flag (fragment tsconfig.json):
|
1 2 3 4 5 |
"angularCompilerOptions": { "fullTemplateTypeCheck": true, "strictTemplates": false, ... } |
W porównaniu do trybu podstawowego zmieniają się następujące rzeczy:
- zmienne w widokach “embedded” (np. zmienne wewnątrz bloków *ngIf, *ngFor, <ng-template>) mają poprawnie wykrywany i weryfikowany typ,
- wykrywany i weryfikowany jest typ wartości zwracanych z pipes,
- lokalne referencje (#refs) do dyrektyw i pipes mają poprawnie wykrywany i weryfikowany typ (z wyjątkiem, gdy parametry te są generyczne).
W poniższym przykładzie zmienna lokalna “fruit” jest wciąż typu “any”, ale “user” ma już poprawnie wywnioskowany typ.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
@Component({ selector: 'app-root', template: ` <div *ngFor="let fruit of fruits"> {{ fruit.foo.bar.baz }} {{ user.foo }} </div> ` }) export class AppComponent { fruits = ['apple', 'banana'] user = { firstName: 'foo' } } |
W tym trybie w trakcie kompilacji pojawi się błąd:
|
1 |
Property 'foo' does not exist on type '{ firstName: string; }' |
Tryb restrykcyjnej weryfikacji (strict mode):
w takim trybie pracujemy przy następującym ustawieniu flag (fragment tsconfig.json):
|
1 2 3 4 5 |
"angularCompilerOptions": { "fullTemplateTypeCheck": true, "strictTemplates": true, ... } |
Ustawienie flagi “strictTemplates” na “true” zawsze nadpisuje wartość “fullTemplateTypeCheck” (tak więc flagę “fullTemplateTypeCheck” można w takim przypadku pominąć).
W tym trybie kompilator oferuje nam wszystko to, co w trybie pełnej weryfikacji, a ponadto:
- dla komponentów i dyrektyw weryfikowane są zgodności typów inputów z przypisywanymi do nich zmiennymi w szablonie (wspomniana w sekcji o Typescript’cie flaga strictNullChecks jest również brana przy tej weryfikacji pod uwagę),
- wnioskuje typy dla zmiennych lokalnych wewnątrz widoków “embedded” (np. zmienna lokalna zadeklarowana wewnątrz dyrektywy strukturalnej *ngFor),
- wnioskuje typ wartości $event dla outputów z komponentów, eventów DOM oraz angularowych animacji,
- wnioskuje typ referencji (#refs) również dla elementów DOM na podstawie nazwy tagu (np. <span #spanRef> zostanie poprawnie otypowane jako HTMLSpanElement).
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
@Component({ selector: 'app-child', template: `My name is {{ name }}`, }) export class ChildComponent { @Input() name: string; } @Component({ selector: 'app-root', template: ` <app-child [name]="applicationName"></app-child> <div *ngFor="let fruit of fruits"> {{ fruit.foo.bar }} </div> ` }) export class AppComponent { applicationName: string | undefined = 'foo'; fruits = ['apple', 'banana']; } |
Przy włączonej dodatkowo fladze strictNullChecks otrzymamy następujący błąd dotyczący przypisania wartości “applicationName” do inputa “name”:
|
1 |
Type 'string | undefined' is not assignable to type 'string' |
W tym trybie również lokalna zmienna “fruit” będzie mieć poprawnie wywnioskowany typ (string), a więc:
|
1 |
Property 'foo' does not exist on type 'string'. |
Przy kombinacji flag strictNullChecks oraz strictTemplates warto też zwrócić uwagę na wykorzystywany często async pipe. Typ metody “transform” tego pipe’a otypowany jest następująco (z wykorzystaniem overload):
|
1 2 3 |
transform<T>(obj: Observable<T> | Subscribable<T> | Promise<T>): T | null; transform<T>(obj: null | undefined): null; transform<T>(obj: Observable<T> | Subscribable<T> | Promise<T> | null | undefined): T | null; |
Oznacza to, że dla następującego kodu:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
@Component({ selector: 'app-child', template: `My name is {{ name }}`, }) export class ChildComponent { @Input() name: string; } @Component({ selector: 'app-root', template: ` <app-child [name]="applicationName$ | async"></app-child> ` }) export class AppComponent { applicationName$ = of('foo'); } |
otrzymamy błąd kompilacji:
|
1 |
Type 'string | null' is not assignable to type 'string'. |
gdyż wyrażenie “applicationName$ | async” zwraca nam wartość typu “string | null”. Oznacza to konieczność typowania wszystkich inputów (do których wartość przypisywana jest za pomocą async pipe) jako nullable.
Uwaga: wpływ flagi strictNullChecks na weryfikację typów inputów można ustawić za pomocą flagi strictNullInputTypes, o której mowa będzie w dalszej części artykułu.
Rekomendacja: Stanowczo odradzamy korzystanie z trybu basic, mocno zachęcamy do korzystania z trybu scrict, który pozwoli uniknąć wielu błędów.
strictInputTypes
Jest to flaga odpowiadająca za weryfikację typów inputów. Jeśli nie ustawimy tej flagi ręcznie, to jej domyślna wartość odpowiada wartości flagi “strictTemplates”.
Przy wartości “true” weryfikowane są typy zmiennych przypisywanych do inputów, tak jak pokazano to w przykładzie dla trybu restrykcyjnej weryfikacji, a dla wartości false ta weryfikacja jest całkowicie pomijana (nawet przy równocześnie włączonej fladze strictTemplates).
Dla przypomnienia – restrykcyjność tej weryfikacji (tj. branie pod uwagę wartości nullable) zależy również od wartości flagi strictNullChecks (oraz flagi strictNullInputTypes, o której mowa będzie w dalszej części artykułu).
Rekomendacja: Zawsze korzystać z tej weryfikacji (ustawiając bezpośrednio tę flagę na true, lub za pośrednictwem flagi strictTemplates).
strictInputAccessModifiers
Ta flaga jest odpowiedzialna za weryfikację modyfikatorów dostępu do pól (private/protected/readonly) przy przypisywaniu zmiennych do inputów.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 |
@Component({ selector: 'app-child', template: `` }) export class ChildComponent { @Input() readonly age: number; @Input() private firstName: string; @Input() protected lastName: string; } @Component({ selector: 'app-root', template: ` <app-child [age]="18" [firstName]="'foo'" [lastName]="'bar'"></app-child> ` }) export class AppComponent {} |
Dla powyższego przykładu, bez włączonej flagi strictInputAccessModifiers kompilacja się powiedzie (w trakcie runtime nie wystąpi żaden błąd). Dla włączonej flagi otrzymamy odpowiednio:
|
1 2 3 |
Cannot assign to 'age' because it is a read-only property. Property 'firstName' is private and only accessible within class 'ChildComponent'. Property 'lastName' is protected and only accessible within class 'ChildComponent' and its subclasses. |
Nałożenie dekoratora @Input na pole z modyfikatorami dostępu readonly/private/protected wydaje się programistycznym błędem w każdym przypadku (gdyż umożliwia to modyfikację tych wartości z zewnątrz, w dowolnej chwili, na co żaden z tych modyfikatorów teoretycznie nie zezwala), jednak dopiero ta dodatkowa flaga zapobiega tego typu błędom.
Rekomendacja: Ta flaga nie zawiera się w strictTemplates, dlatego należy włączyć ją osobno! Zalecamy korzystać z niej (i nie nakładać wspomnianych modyfikatorów dostępu na pola oznaczone dekoratorem @Input).
strictNullInputTypes
Ta flaga decyduje o tym, czy flaga strictNullChecks jest brana pod uwagę przy weryfikacji typów zmiennych przypisywanych do Inputów. Jeśli nie ustawimy tej flagi ręcznie, to jej domyślna wartość odpowiada wartości flagi “strictTemplates”.
Wróćmy ponownie do przykładu z async pipe:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
@Component({ selector: 'app-child', template: `My name is {{ name }}`, }) export class ChildComponent { @Input() name: string; } @Component({ selector: 'app-root', template: ` <app-child [name]="applicationName$ | async"></app-child> ` }) export class AppComponent { applicationName$ = of('foo'); } |
Dla włączonej flagi “strictNullChecks” i domyślnych wartości flag “strictInputTypes” oraz “strictNullInputTypes” (które można by pominąć, a wówczas ich wartość wynikałaby z wartości “strictTemplates”):
|
1 2 3 4 5 6 7 8 9 10 11 12 |
{ ... "compilerOptions": { ... "strictNullChecks": true, }, "angularCompilerOptions": { "strictTemplates": true, "strictInputTypes": true, "strictNullInputTypes": true } } |
otrzymamy przytoczony już wcześniej błąd (ponieważ zwracany typ z async pipe jest nullable):
|
1 |
Type 'string | null' is not assignable to type 'string'. |
Jeśli jednak ustawimy tę flagę na “false” przy jednocześnie włączonych flagach “strictNullChecks”, “strictTemplates” oraz “strictInputTypes”:
|
1 2 3 4 5 6 7 8 9 10 11 12 |
{ ... "compilerOptions": { ... "strictNullChecks": true, }, "angularCompilerOptions": { "strictTemplates": true, "strictInputTypes": true, "strictNullInputTypes": false } } |
to wówczas kompilacja się powiedzie (ponieważ string pasuje do string’a, a nullowalność jest ignorowana).
Rekomendacja: Zalecamy nie wyłączać tej flagi, chociaż w przypadku już istniejących projektów (w którym inputy nie są nullowalne) oraz korzystania z bibliotek, w których komponenty nie są napisane z myślą o wspieraniu wartości nullowalnych może okazać się to konieczne.
strictAttributeTypes
Jest to flaga odpowiadająca za weryfikację przypisywania wartości do inputów za pomocą “text attributes” (zamiast klasycznego bindingu). Jeśli nie ustawimy tej flagi ręcznie, to jej domyślna wartość odpowiada wartości flagi “strictTemplates”.
Zwykle dokonujemy wiązania atrybutów (w tym inputów dla komponentów i dyrektyw) za pomocą kwadratowych nawiasów “[]” (informując tym samym kompilator angulara, że wyrażenie po prawej stronie jest ‘dynamiczne’, a więc zawiera w sobie jakieś wyrażenie, które wymaga obliczenia (może być to w najprostszym przypadku referencja na jakąś zmienną).
Istnieje też drugi sposób na ustawienie wartości inputa – jako zwykły HTMLowy atrybut (pamiętając, że wszystkie takie atrybuty są stringami). Jeśli nazwa atrybutu pokrywa się z nazwą inputa to wartość inputa jest odpowiednio ustawiana.
Przy wyłączonej fladze strictAttributeTypes poniższy przykład przejdzie kompilacje:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
@Component({ selector: 'app-child', template: `<span *ngIf="weight">{{ weight.toFixed(2) }}</span>`, }) export class ChildComponent { @Input() firstName: string; @Input() lastName: string; @Input() weight: number; } @Component({ selector: 'app-root', template: ` <app-child [firstName]="'foo'" lastName="bar" weight="18"></app-child> ` }) export class AppComponent {} |
doprowadzi to do ustawienia wartości “weight” jako “18” (string, nie number), co w efekcie doprowadzi do runtime exception:
|
1 |
weight.toFixed is not a function |
Przy włączonej fladze kompilator wyłapie taki błąd:
|
1 |
Type 'string' is not assignable to type 'number'. |
Przypisywania wartości do inputów z pominięciem kwadratowych nawiasów możemy używać wyłącznie dla Inputów otypowanych jako string (i enum, którego wartości są również stringami).
Rekomendacja: Korzystać z tej flagi (przy korzystaniu ze strictTemplates nie wyłączać jej).
strictSafeNavigationTypes
Czym są operacje “safe navigations”? Jest to dobrze nam znany odpowiednik Optional Chaining z Typescripta, ale występujący po stronie angularowego szablonu. Przykładowo:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
@Component({ selector: 'app-root', template: ` <p> {{ user?.address?.street }} </p> ` }) export class AppComponent { user: User = { address: { street: 'Sesame' } }; } |
Przy wyłączonej fladze każde użycie safe navigation operatora spowoduje, że jego rezultat będzie traktowany jako “any”. Przy włączonej fladze typ będzie prawidłowo wnioskowany. Jeśli nie ustawimy tej flagi ręcznie, to jej domyślna wartość odpowiada wartości flagi “strictTemplates”.
Bez włączonej flagi safe navigation operator weryfikuje jedynie, czy “address” jest polem w obiekcie “user”, ale w dalszej kolejności traktuje tę wartość jako “any”, tak więc możliwe jest odwołanie się do nieistniejących pól (“bar.baz”).
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
@Component({ selector: 'app-root', template: ` <p> {{ user?.address.bar.baz }} </p> ` }) export class AppComponent { user: User = { address: { street: 'Sesame' } }; } |
O błędzie dowiemy się dopiero w trakcie runtime (“Cannot read property 'baz’ of undefined”). Jeśli flaga jest włączona, wówczas wartość zwracana przez operator safe navigation jest poprawnie wnioskowana, a błąd zostanie wykryty już na etapie kompilacji:
|
1 |
Property 'bar' does not exist on type '{ street: string; }'. |
Rekomendacja: Korzystać z tej flagi (przy korzystaniu ze strictTemplates nie wyłączać jej).
strictDomLocalRefTypes
Ta flaga odpowiada za wyłączenie/włączenie wnioskowania typów angularowych referencji nałożonych na elementy DOM. Jeśli nie ustawimy tej flagi ręcznie, to jej domyślna wartość odpowiada wartości flagi “strictTemplates”. Z naszych testów wynika również, że bez włączonej flagi “strictTemplates” typy referencji nie są wnioskowane niezależnie od ustawienia flagi strictDomLocalRefTypes.
Przykład z wyłączoną flagą strictDomLocalRefTypes (przy włączonej fladze strictTemplates):
|
1 2 3 4 5 6 7 8 9 10 11 |
@Component({ selector: 'app-root', template: ` <input type="number" #inputRef> <span> Input type: {{ inputRef.type.toUpperCase() }} Invalid prop: {{ inputRef.foo.bar.baz }} </span> ` }) export class AppComponent {} |
Kompilacja przechodzi, błąd pojawia się dopiero w runtime:
|
1 |
Cannot read property 'bar' of undefined |
Przy włączonych obu flagach (wywnioskowany typ referencji dla tagu “input” to “HTMLInputElement”) następuje błąd kompilacji:
|
1 |
Property 'foo' does not exist on type 'HTMLInputElement'. |
Rekomendacja: Korzystać z tej flagi (przy korzystaniu ze strictTemplates nie wyłączać jej).
strictOutputEventTypes
Ta flaga odpowiada za wyłączenie/włączenie wnioskowania typów dla wartości $event występującej przy outputach z komponentów/dyrektyw oraz angularowych animacjach. Jeśli nie ustawimy tej flagi ręcznie, to jej domyślna wartość odpowiada wartości flagi “strictTemplates”.
Przykład z wyłączoną flagą:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 |
@Component({ selector: 'app-child', template: ``, }) export class ChildComponent { @Output() numberOutput = new EventEmitter<number>(); } @Component({ selector: 'app-root', template: `<app-child (numberOutput)="onNumberOutput($event.foo.bar.baz)"></app-child>` }) export class AppComponent { onNumberOutput(value: number): void {} } |
Kompilacja przechodzi, błąd pojawia się dopiero w runtime, po pierwszym wyemitowaniu eventu:
|
1 |
Cannot read property 'bar' of undefined |
Przy włączonej fladze typ $event jest poprawnie wywnioskowany (jako “number”) i następuje błąd kompilacji:
|
1 |
Property 'foo' does not exist on type 'number'. |
Rekomendacja: Korzystać z tej flagi (przy korzystaniu ze strictTemplates nie wyłączać jej).
strictDomEventTypes
Ta flaga, podobnie jak flaga strictOutputEventTypes, odpowiada za wnioskowanie typu $event, ale tym razem dla natywnych eventów z DOM. Jeśli nie ustawimy tej flagi ręcznie, to jej domyślna wartość odpowiada wartości flagi “strictTemplates”.
Przykład z wyłączoną flagą:
|
1 2 3 4 5 |
@Component({ selector: 'app-root', template: `<input type="text" (mouseenter)="$event.foo.bar">` }) export class AppComponent {} |
Kompilacja przechodzi, błąd pojawia się dopiero w runtime, po pierwszym wyemitowaniu eventu:
|
1 |
“Cannot read property 'bar' of undefined” |
Przy włączonej fladze typ $event jest poprawnie wywnioskowany (jako “MouseEvent”) i następuje błąd kompilacji:
|
1 |
Property 'foo' does not exist on type 'MouseEvent'. |
Rekomendacja: Korzystać z tej flagi (przy korzystaniu ze strictTemplates nie wyłączać jej).
strictContextGenerics
Ta flaga dotyczy typów generycznych dla komponentów. Jeżeli jest wyłączona, wówczas w trakcie wnioskowania typów w angularowym szablonie każde wystąpienie typu generycznego komponentu jest interpretowane jako “any”. Przy włączonej fladze generyczne typy komponentu są poprawnie uwzględniane przy wnioskowaniu typów. Jeśli nie ustawimy tej flagi ręcznie, to jej domyślna wartość odpowiada wartości flagi “strictTemplates”.
Rozważmy następujący przykład:
|
1 2 3 4 5 6 7 8 9 10 |
@Component({ selector: 'app-child', template: ` {{ value.length }} <!-- OK --> {{ value.foo.bar.baz }} <!-- ERROR --> ` }) export class ChildComponent<T extends Array<any>> { @Input() value: T; } |
Zmienna “value” jest typu “T”, a więc wiemy na pewno, że jest tablicą jakichś elementów. Przy wyłączonej fladze “value” jest jednak interpretowane po stronie szablonu jako “any”, przez co możemy łatwo doprowadzić do runtime exception.
Przy włączonej fladze otrzymamy słuszny błąd kompilacji:
|
1 |
Property 'foo' does not exist on type 'T'. |
Kompilator nie ma zastrzeżeń do skorzystania z pola “length’, gdyż każda tablica posiada te pole.
Rekomendacja: Korzystać z tej flagi (przy korzystaniu ze strictTemplates nie wyłączać jej).
strictLiteralTypes
Ta flaga decyduje o tym, czy zmienne (konkretnie obiekty i tablice), które deklarujemy bezpośrednio w szablonie mają wnioskowany typ (w przypadku wyłączenia flagi ich wartość to “any”). Jeśli nie ustawimy tej flagi ręcznie, to jej domyślna wartość odpowiada wartości flagi “strictTemplates”.
Przykład z wyłączoną flagą:
|
1 2 3 4 5 6 7 8 |
@Component({ selector: 'app-root', template: ` {{ { firstName: 'foo '}.foo.bar.baz }} {{ ['foo', 'bar'].foo.bar.baz }} ` }) export class AppComponent {} |
W szablonie deklarujemy dwie zmienne (obiekt z polem ‘firstName’ oraz tablicę z dwoma stringami). Oba postrzegane są jako “any”, więc możemy odnosić się do nieistniejących pól (co skutkować będzie błędami w runtime).
Przy włączonej fladze otrzymamy następujące błędy kompilacji:
|
1 2 |
Property 'foo' does not exist on type '{ firstName: string; }'. Property 'foo' does not exist on type 'string[]'. |
Rekomendacja: Korzystać z tej flagi (przy korzyrstaniu ze strictTemplates nie wyłączać jej).
Podsumowanie
Brawo! Przebrnęliśmy przez długą listę możliwych do ustawienia restrykcji. Teraz dokładnie wiemy co i w jaki sposób możemy ustawić, aby dopasować proces kompilacji do własnych potrzeb. Każda z flag została (celowo) przedstawiona w sposób możliwie niezależny od pozostałych. To nie zmienia jednak faktu, że wszystkie te restrykcje współistnieją, częściowo wpływają na siebie i się wzajemnie uzupełniają.
Znalezienie idealnych ustawień dla Twojego projektu (czy zespołu, bo ostatecznie sama konfiguracja jest reużywalna) może być procesem pełnym prób i eksperymentów. W ogólności sugeruję kierować się zawsze w stronę bardziej restrykcyjnych konfiguracji.
Automatyzacja
Aby “uszczelnić” proces weryfikacji kodu (w tym weryfikacji możliwości kompilacji) zachęcamy do włączenia do procesu ciągłej integracji etapu próbnej kompilacji projektu, aby faktycznie (tak jak wspomniano to na samym początku artykułu) jak najszybciej wyłapać wszelkie błędy.
Restrykcyjne zasady kompilacji stanowią dobre uzupełnienie pozostałych technik weryfikacji poprawności kodu (takich jak zaawansowana statyczna analiza kodu czy wszelkiego rodzaju testy automatyczne). Każdy błąd wyłapany przez automatyczny mechanizm stanowi ostatecznie sporą oszczędność czasu i pieniędzy (w porównaniu do znalezienia tych samych błędów w trakcie testów manualnych, lub co gorsza po udostępnieniu aplikacji użytkownikom końcowym).
Dodaj komentarz