Una de las principales prioridades de Angular es habilitar las mejores prácticas desde el principio. Queremos que se sienta cómodo creando una gran interfaz de usuario empresarial de la misma manera que creando una aplicación de tareas pendientes.

Aplicamos esta mentalidad en las API, las herramientas para desarrolladores, las mejores prácticas y la documentación del marco. Algunos ejemplos son la inversión en TypeScript que hicimos al principio, permitiendo la inyección de dependencia de forma predeterminada para un código más flexible y comprobable, así como los presupuestos de rendimiento que sigue cada aplicación Angular.

Con el tiempo, hemos estado trabajando mucho en este espacio. Al mismo tiempo, hemos intentado equilibrar el rigor y la accesibilidad. No queremos hacer que Angular sea imposible de enseñar e imposible de aprender para los recién llegados al desarrollo web. Un excelente ejemplo de esto es el modo estricto al que nos hemos estado moviendo con cautela.

En la publicación del blog ” Angular CLI Strict Mode “, describimos lo que habilita y solicitamos comentarios de la comunidad. Pasamos muchas horas hablando con desarrolladores y entrenadores de Angular y profundizamos en la telemetría de Angular CLI para descubrir que cerca del 70% de las personas han optado por el modo estricto desde que habilitamos el indicador. Basándonos en todos estos datos agregados, decidimos cómo seguir adelante.

Nos complace anunciar que habilitaremos el modo estricto de forma predeterminada para todos los proyectos nuevos a partir de la versión 12 . Aún podrá optar por no pasar por alto la --no-strictopción al crear un nuevo espacio de trabajo.

Configuración de modo estricto

Según los comentarios que recibimos de la comunidad, cambiamos un poco la definición de modo estricto. Como parte de la versión 12, habilitaremos:

• Modo estricto en TypeScript, así como otras marcas de rigurosidad recomendadas por el equipo de TypeScript. Específicamente, strict, forceConsistentCasingInFilenames, noImplicitReturnsynoFallthroughCasesInSwitch
• Indicadores estrictos del compilador Angular strictTemplates, strictInputAccessModifiersystrictInjectionParameters
• Reducción de los presupuestos de tamaño de paquete en ~ 75%

A partir de la versión 12, eliminaremos el indicador de modo estricto y todos los proyectos nuevos tendrán esta configuración habilitada desde el principio.

Habilitar para proyectos existentes

Aunque no migraremos proyectos existentes al modo estricto, puede optar por participar con bastante rapidez. Todo lo que necesita hacer es habilitar algunas banderas en su tsconfig.jsonpara sus aplicaciones Ivy:

{  ...  "compilerOptions": {    ...    "forceConsistentCasingInFileNames": verdadero,    "estricto": cierto,    "noImplicitReturns": verdadero,    "noFallthroughCasesInSwitch": verdadero,    ...  },  "angularCompilerOptions": {    "StrictInjectionParameters": verdadero,    "StrictInputAccessModifiers": verdadero,    "Plantillas estrictas": verdadero  }}

Además, puede revisar los presupuestos de su paquete en angular.json. El modo estricto utiliza la siguiente configuración:

"presupuestos": [  {    "tipo": "inicial",    "maximumWarning": "500 kb",    "maximumError": "1mb"  },  {    "tipo": "anyComponentStyle",    "maximumWarning": "2kb",    "maximumError": "4kb"  }]

Trascendencia

Tener una verificación de tipo más estricta le permitirá detectar muchos errores desde el principio. Esa es una de las mejores prácticas que hemos estado usando para todos los proyectos de TypeScript en el monorepo de Google durante un tiempo, y estamos emocionados de habilitarla de forma predeterminada para todos. Según el documento ” Escribir o no escribir: cuantificación de errores detectables en JavaScript “, podrá detectar muchos más problemas en el momento de la compilación con estrictas comprobaciones nulas habilitadas de forma predeterminada.

Debería esperar algunos errores nuevos de tipo común que comenzarán a aparecer.

Indicadores estrictos de TypeScript

Este fragmento ya no se compilará para nuevas aplicaciones que usen v12 debido a strictPropertyInitialization:

@Componente({...})class AppComponent {  // La propiedad 'title' no tiene inicializador y no 
  // está definitivamente asignada en el constructor.ts (2564)  @Input () título: cadena;}

Solucionar el problema sería tan simple como establecer un valor de la titlepropiedad:

@Componente({...})class AppComponent {  @Input () título = '';}

Puede encontrarse en una situación similar cuando olvide inicializar una propiedad o establecer su valor:

class Empleado {  // Los empleados miembros 'implícitamente tienen un tipo' any '.ts (7008)  empleado;}

TypeScript aquí arrojará un error que employeetiene un tipo implícito any. Para solucionar el problema, puede inicializar el valor o establecer un tipo explícito.

Hay algunos otros problemas similares sobre los que puede encontrar más información aquí .

Comprobación estricta del tipo de plantilla

Con el compilador Ivy y el servicio de lenguaje, ¡podrá experimentar el poder del sistema de tipos de TypeScript en sus plantillas!

El nuevo servicio de lenguaje se basa en el compilador Ivy, que usa TypeScript para la verificación de tipos. El uso de este mecanismo significa que sus plantillas serán tan estrictas como el resto de su aplicación.

En raras ocasiones, necesitamos lanzar una expresión a any. Al tener plantillas de verificación de tipo más estrictas, es posible que deba hacer lo mismo. La sintaxis de la plantilla de Angular le permite hacer esto usando:

<div> {{$ any (usuario)}} </div>

Presupuestos más ajustados

Por último, pero no menos importante, el modo estricto también ajustará sus presupuestos de tamaño . Si introduce una dependencia de terceros que no se puede cambiar de árbol o excede el tamaño del paquete al que está apuntando, obtendrá un error de tiempo de compilación.

Puede optar por no participar en esta función actualizando su angular.json configuración , pero le recomendamos encarecidamente que mantenga sus valores existentes para que pueda asegurarse de que su aplicación se mantenga rápida a lo largo del tiempo.

Si tiene una falla en el tiempo de compilación porque sus recursos exceden los presupuestos de tamaño, revise nuestras prácticas de optimización del rendimiento para optimizar su aplicación.

Software de mayor calidad para todos

Los sistemas de tipos han sido un próspero campo de investigación y desarrollo durante décadas. Tener tipos específicos y controles avanzados nos permite detectar errores desde el principio antes de enviar nuestra aplicación a producción y permite una mejor experiencia de desarrollo.

Cuantos más tipos específicos tengamos, mejor nuestro editor de texto y nuestro IDE pueden ayudarnos con el autocompletado y otras sugerencias. Una buena escritura permite el análisis de código estático avanzado para otras herramientas, incluidos los esquemas. Los esquemas de actualización transformarán su proyecto con más confianza, teniendo mejor tipo de información.

Nuestro objetivo es permitirle resolver sin problemas problemas del mundo real a través de software con una solución completa y obstinada. Estamos entusiasmados de dar este paso adelante con herramientas más estrictas y completas.