You will often come across statistics presented as an exponential function that show the increasing costs of detection and fixing of software bugs.
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
This is why it’s so important to minimize the risk of new bugs at the earliest possible stage of software development. Fortunately, there are a lot of automated techniques, tools and processes supporting us in this matter (starting with tools integrated in the IDE, all plugins, auto-formatters, linters, through restrictions during transpilation/compilation, extensive static code analysis, scanning external libraries for vulnerabilities, ending with a pyramid of automated tests). Some of these provide us with out-of-the-box support, some require additional resources (time for proper tools configuration, resources to maintain the continuous integration process, etc.).
Angular 13.2.0 version gives us a new functionality called Extended Diagnostics. It’s a tool built into the compilation process of Angular view templates (it’s a part of the compiler itself), it doesn’t require any additional infrastructure, any additional scripts – it’s present and it simply works (also with ng serve during transpilation).
Its task is to detect potential anomalies which are not bugs (in the sense that they don’t cause a compilation error and meet all syntax requirements), but at the same time objections might occur and they might not necessarily reflect what the programmer had in mind. It serves as a kind of additional linter for angular view template syntax.
invalidBananaInBox
|
1 2 3 4 5 6 7 8 9 10 |
{ "angularCompilerOptions": { "strictTemplates": true, "extendedDiagnostics": { "checks": { "invalidBananaInBox": "error" }, "defaultCategory": "error" } } |
This diagnostic requires enabling strictTemplates. It detects reverse “banana-in-box” syntax at two-way-data-binding (so the use of “([…])” instead of “[(…)]”).
|
1 2 3 4 |
// invalid <component ([foo])="bar"></component> // valid <component [(foo)]="bar"></component> |
In both cases the syntax is correct, but in the first case we don’t use two-way-data-binding, we only attach a handler to the event named “[foo]”.
nullishCoalescingNotNullable
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
{ "compilerOptions": { "strictNullChecks": true, "angularCompilerOptions": { "strictTemplates": true, "extendedDiagnostics": { "checks": { "nullishCoalescingNotNullable": "error" }, "defaultCategory": "error" } } } |
This diagnostic requires strictTemplates and strictNullChecks to be enabled. It detects the redundant use of the non-nullish coalescing operator “??”.
|
1 2 3 4 5 6 7 8 9 10 11 12 13 |
import {Component} from '@angular/core'; @Component({ template: ` <div>{{ foo ?? 'xxx' }</div> <div>{{ bar ?? 'zzz' }</div> `, … }) class MyComponent { foo: string | null = 'test'; bar: string = 'test'; } |
Regarding the “foo” field, the use of the non-nullish coalescing operator is reasonable (the field itself is nullable), but in case of the “bar” (with enabled strictTemplates and strictNullChecks) it’s pointless.
What’s next?
Angular team plans to add new diagnostics in minor releases of the framework. New diagnostics and new bugs may appear along with version upgrades, so by default detected anomalies are returned as warnings (this can be controlled with the “angularCompilerOptions.extendedDiagnostics.defaultCategory” field in the tsconfig file). Ideas for new diagnostics can be submitted via the github feature requests (https://github.com/angular/angular/issues/new?template=2-feature-request.yaml). Full documentation regarding the Extended Diagnostics can be found here: https://angular.io/extended-diagnostics.
References:
Leave a Reply