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

5 minuto(s)

En esta página:

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

Parte 1
Parte 2 (Final)

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:


const funcion1 = (str: String): String => {
  return str;
};

const funcion2 = (str: string): string => {
  return str;
};

funcion2(funcion1('postre'));

const funcion1 = (str: String): String => {

return str;

};

const funcion2 = (str: string): string => {

return str;

};

funcion2(funcion1('postre'));

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


Argument of type 'String' is not assignable to parameter of
type 'string'. 'string' is a primitive, but 'String' is a wrapper object. 
Prefer using 'string' when possible.

Argument of type 'String' is not assignable to parameter of

type 'string'. 'string' is a primitive, but 'String' is a wrapper object.

Prefer using 'string' when possible.

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.


class Postre {
  nombre: string;
  private precio: number;
constructor(nombre: string, precio: number) {
    this.nombre = nombre;
    this.precio = precio;
  }
}
const postre = new Postre('Gelatina de Fresa', 2.00);
postre.nombre;
postre.precio;

class Postre {

nombre: string;

private precio: number;

constructor(nombre: string, precio: number) {

this.nombre = nombre;

this.precio = precio;

}

const postre = new Postre('Gelatina de Fresa', 2.00);

postre.nombre;

postre.precio;

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:


const postres = ['Gelatina de Fresa', 'Pie de Manzana', 'Torta Helada'].find((el) => el === 'Torta de Chocolate'); 
const miFuncion = (el: string) => {
  //
};
someFn(postres);

const postres = ['Gelatina de Fresa', 'Pie de Manzana', 'Torta Helada'].find((el) => el === 'Torta de Chocolate');

const miFuncion = (el: string) => {

};

someFn(postres);

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:


Argument of type 'string | undefined' is not assignable to parameter 
of type 'string'. Type 'undefined' is not assignable to type 'string'

Argument of type 'string | undefined' is not assignable to parameter

of type 'string'. Type 'undefined' is not assignable to type 'string'

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:


const miFuncion = (nombre: string, apellido: string): boolean => {
  return nombre.length > apellido.length;
}; 

miFuncion.apply(undefined, ['xyz', 'ddd', 'fwegw']); 
// Error: Argument of type '[string, string, string]' is not assignable to parameter of type '[nombre: string, apellido: string]'

miFuncion.call(undefined, 1); 
// Error: Argument of type '1' is not assignable to parameter of type 'string'

miFuncion.bind(undefined)('abc'); 
// Error: Expected 2 arguments, but got 1

const miFuncion = (nombre: string, apellido: string): boolean => {

return nombre.length > apellido.length;

};

miFuncion.apply(undefined, ['xyz', 'ddd', 'fwegw']);

// Error: Argument of type '[string, string, string]' is not assignable to parameter of type '[nombre: string, apellido: string]'

miFuncion.call(undefined, 1);

// Error: Argument of type '1' is not assignable to parameter of type 'string'

miFuncion.bind(undefined)('abc');

// Error: Expected 2 arguments, but got 1

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.


const miFuncion = (nombre, apellido): boolean => {
  //
}

const miFuncion = (nombre, apellido): boolean => {

}

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.


const postre = {
  nombre: 'Gelatina de Fresa',
  decirNombre: function () {
    return function () {
      console.log(this.nombre);
    };
  }
};
postre.decirNombre();

const postre = {

nombre: 'Gelatina de Fresa',

decirNombre: function () {

return function () {

console.log(this.nombre);

};

}

};

postre.decirNombre();

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.