Wróć do strony głównej
Angular

Angular extended diagnostics

Często natrafić można na statystyki przedstawiające wzrost kosztu wykrycia i naprawienia błędu programistycznego jako funkcję wykładniczą.  

Finding and fixing a software problem after delivery is often 100 times more expensive than finding and fixing it during the requirements and design phase.

Software Defect Reduction Top 10 List”, Barry Boehm, University of Southern California, Victor R. Basili, University of Maryland

Z tego też powodu tak istotne jest minimalizowanie ryzyka powstawania nowych błędów na jak najwcześniejszym etapie wytwarzania oprogramowania. Całe szczęście istnieje mnóstwo zautomatyzowanych technik, narzędzi i procesów wspierających nas w tej kwestii (począwszy od narzędzi wbudowanych w IDE, wszelkich pluginów, auto-formatterów, linterów, poprzez restrykcje w trakcie transpilacji/kompilacji, rozbudowaną statyczną analizę kodu, skanowanie bibliotek zewnętrznych w poszukiwaniu wykrytych podatności, kończąc na całej piramidzie testów automatycznych). Część z tych rzeczy zapewnia nam wsparcie out-of-the-box, część wymaga dodatkowych zasobów (czas na odpowiednią konfigurację narzędzi, zasoby do utrzymania procesu ciągłej integracji itd.).

Angular w wersji 13.2.0 dostarcza nam nową funkcjonalność nazwaną Extended diagnostics. Jest to narzędzie wbudowane w proces kompilacji szablonów widoków Angulara (stanowi część samego kompilatora), nie wymagające żadnej dodatkowej infrastruktury, żadnych dodatkowych skryptów – po prostu jest i działa (w trakcie transpilacji, również przy ng serve).

Jego zadaniem jest wykrywanie potencjalnych nieprawidłowości, które nie są błędami (w takim rozumieniu, że nie powodują błędu kompilacji, spełniają wszystkie wymogi składni), ale jednocześnie mogą budzić zastrzeżenia i niekoniecznie odzwierciedlać to, co programista miał na myśli. Pełni swego rodzaju rolę dodatkowego lintera angularowej składni szablonów widoków.

invalidBananaInBox

Do działania tej diagnostyki wymagane jest włączenie strictTemplates. W jej ramach wykrywane jest odwrotna składnia “banana-in-box” przy two-way-data-binding (a więc użycie “([…])” zamiast “[(…)]”).

W obu przypadkach składnia jest poprawna, jednak w pierwszym przypadku nie używamy two-way-data-bindingu, a jedynie podpinamy handler do eventu o nazwie “[foo]”.

nullishCoalescingNotNullable

Do działania tej diagnostyki wymagane jest włączenie strictTemplates oraz strictNullChecks. W ramach jej działania wykrywane są przypadki zbędnego użycia operatora non-nullish coalescing “??”.

W przypadku pola “foo” użycie operatora non-nullish coalescing jest zasadne (samo pole jest nullowalne), jednak w przypadku pola “bar” (przy włączonym strictTemplates i strictNullChecks) jest to bezcelowe.

Co dalej?

Twórcy Angulara planują dodawanie nowych diagnostyk w minor wersjach wydań frameworka. Wraz z podniesieniem wersji pojawiać się mogą nowe diagnostyki i nowe błędy, dlatego domyślnie wykryte nieprawidłowości zwracane są w formie warningów (można tym sterować za pomocą pola “angularCompilerOptions.extendedDiagnostics.defaultCategory” w pliku tsconfig). Pomysły na nowe diagnostyki można zgłaszać chociażby za pomocą githubowych feature requestów (https://github.com/angular/angular/issues/new?template=2-feature-request.yaml). Pełna dokumentacja Extended Diagnostics znajduje się tutaj: https://angular.io/extended-diagnostics.

 

źródła:

  • https://angular.io/extended-diagnostics
  • https://angular.io/extended-diagnostics/NG8101
  • https://angular.io/extended-diagnostics/NG8102
  • https://kevinkreuzer.medium.com/angular-extended-diagnostics-bee0400727ec
  • https://www.youtube.com/watch?v=vZox3z0bsQI

O autorze

Mateusz Dobrowolski

Sympatyk Typescripta mający kilkuletnie doświadczenie w tworzeniu Angularowych aplikacji.

Chcesz razem z nami tworzyć treści na bloga? Dołącz do nas i twórz wartościowe treści dla sympatyków Angulara z Angular.love!

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *