10 Errores que Debes Evitar en TypeScript – Parte 2 (Final)

TypeScript | | Comunidad: Crear un Post, Eventos Devs, Foro

En la primera parte de este Post llamada 10 Errores que Debes Evitar en TypeScript – Parte 1 vimos los 5 primeros errores que debes evitar cometer en TypeScript, si lo leíste puedes ver que hablamos sobre Iterar innecesariamente las propiedades de un Objeto, Usar Aserciones de Tipo en Lugar de Declaraciones de Tipo, No Especificar Tipos de Retorno de Función, etc. En esta Parte 2 y última veremos los 5 últimos errores que debes evitar cometer en TypeScript, vamos con ello.

Partes


Antes de continuar con este Post, te invito a leer los siguientes artículos:

Asimismo te invito a escuchar el Podcast: “Porque Algunos Desarrolladores no Terminan El Proyecto de Un Cliente”:

Spotify: Sound Cloud: Apple Podcasts

Bien ahora continuemos con el Post: 10 Errores que Debes Evitar en TypeScript – Parte 1.

Igual que en la Parte 1, para conocer mejor los errores que no debes cometer en TypeScript, colocaré el nombre, una descripción y si es posible un código de ejemplo.

Usar Objetos de Envoltura en Lugar de Primitivas

Este punto puede parecer un poco confuso si no se esta familiarizado con la idiosincrasia de JavaScript relacionados con sus tipos primitivos number, string, boolean, etc. Es fácil anotar algo por error con la versión en mayúsculas de uno de ellos:

El código anterior nos devolverá el siguiente error:

El error anterior es correcto porque String y string no son equivalentes. También TypeScript nos sugiere una solución adecuada. Siempre debemos evitar esos tipos de mayúsculas (objetos en caja o envoltorios) porque son solo una forma específica de JavaScript para proporcionar algunos métodos primitivos, por lo general no los necesitamos ni debemos usarlos directamente.

Depender de lo Privado para Ocultar Información

Cuando se trabaja con clases, un aspecto en común que nos gustaría hacer es restringir el acceso a algún campo. TypeScript tiene un manera de hacer algo así con su palabra clave private.

Al llamar postre.precio nos devolverá Property ‘precio’ is private and only accessible within class ‘Postre’. Esta característica es genial y tiene algunos usos, pero debemos ser conscientes de un aspecto importante: solo se aplica durante el tiempo de compilación. La anotación private desaparecerá en tiempo de ejecución y la propiedad será completamente accesible y visible, por ejemplo postre.precio funcionará.

Para restringir el acceso en tiempo de ejecución, podemos usar, por ejemplo, la nueva función de campo privado de JavaScript #precio.

No Verificar los Nulos

Muchos errores se pueden evitar si activamos el modo estricto en la configuración de nuestro compilador, debemos de hacerlo siempre, pero a veces cuando estamos trabajando en un proyecto que ya tiene mucho tiempo funcionando, no podemos darnos ese lujo y tenemos que trabajarlo gradualmente.

El modo estricto consta de varias opciones que se pueden habilitar una a la vez, talvez la más importante sea la opción –strictNullChecks que nos permite evitar muchos errores de ejecución. La idea es simple: sin ella se nos permite asignar undefined ni null a ningún tipo, consideremos el siguiente código:

Sin la opción –strictNullChecks esto seria completamente legal aunque el método find() en el ejemplo nos devuelve string | undefined. Con la opción –strictNullChecks habilitada se puede obtener el siguiente error:

No Verificar los Tipos de Vinculación, Llamada y Aplicación

En TypeScript existe la opción –strictBindCallApply y sin ella habilitada podemos hacer llamadas a los métodos bind(), call() y apply() y obtener any, asimismo no obtenemos verificaciones de tipo cuando los usamos con argumentos incorrectos. Cuando tenemos activada la opción –strictBindCallApply todos los ejemplos a continuación dan como resultado errores de tipo:

Usar Implícitamente any y this

Cuando la opción o flag –noImplicitAny esta habilitada, puede detectar muchos de los errores mencionados en este Post que consta de 2 partes, básicamente no nos permite introducir el tipo any en nuestro código, si no se anota explícitamente como any. Esto es útil para todos los casos en los que podríamos asumir la inferencia correcta de nuestro tipo, pero sobrestimamos las habilidades de TypeScript.

El código anterior devolverá el error: Parameter ‘nombre’ implicitly has an ‘any’ type.

Otro problema que se nos puede resolver cuando tenemos la opción o flag –noImplicitAny habilitada, esta relacionado con la forma en que funciona this en JavaScript. Básicamente a veces no podemos decir de antemano cuál será el tipo real y si el verificador de tipos puede detectar esos casos por nosotros, para esto usamo la opción o  flag –noImplicitAny.

El código anterior devolverá el error: ‘this’ implicitly has type ‘any’ because it does not have a type annotation. Una manera de solucionarlo es convertir la función más interna en una flecha () => { console.log(this.nombre) }.

Bueno hasta aquí llegamos con este Post que consta de 2 partes y te comparto 10 errores que debes evitar comentar en TypeScript.

Conclusión

Hemos aprendido ciertos errores que debemos evitar cometer en TypeScript, hay otros tipos de errores que no han sido mencionados en este Post y en general conforme vayas aprendiendo a evitarlos lograrás mejorar el código de tu proyecto creado con TypeScript. 

Nota (s)

  • No olvides que debemos usar la Tecnología para hacer cosas Buenas por el Mundo. 

Síguenos en nuestras Redes Sociales para que no te pierdas nuestros próximos contenidos.

Newsletter

Suscríbete a Nuestro Boletín de Novedades:

(Luego de la suscripción no te va salir ningun mensaje. Solo revisa tu bandeja de Correo para confirmar tu suscripción)
* indicates required
Subscribirse
Notificar a
guest
0 Comments
Inline Feedbacks
View all comments