Héctor BlisS

@blissito

hace 2 años

¿Qué es Typescript y por qué debería aprenderlo?

Es importante decir que Typescript no es necesario para proyectos pequeños que están destinados a no evolucionar, no crecer o que nunca serán desarrollados por más de un developer. Aunque también tengo que decirte que si Typescript te llega a gustar, y descubres la cantidad de tiempo que te ahorra, puede ser que todo lo quieras escribir con TS.

superset

La razón de ser de Typescript son los problemas que tiene JavaScript, y es que no es fácil hablar de esto ya que muchos developers (yo incluido) no veíamos los problemas de JavaScript como problemas, más bien los veíamos como "flexibilidad" hasta que con el tiempo, dejas de hacer Hola mundos y construyes o colaboras en una app de tamaño razonable o con un equipo de desarrolladores que actualizan el código todos los días, ahí es cuando el dolor aparece en verdad.

Sin afán de ser agresivo en esto, la verdad es que no ves los problemas cuando eres un JR dev comenzando, es hasta que te tomas en serio el construir software seguro y robusto y sobre todo cuando trabajas con otras personas cuando los problemas se vuelven visibles e incluso molestos. Pero...

¿Cuáles son los problemas de JavaScript que TS resuelve?

Vamos al grano con esto para no hacer gigante esta entrada, te voy a listar tres por ahora:

1. La flexibilidad de JS tiene un precio muy alto.

Javascript no tiene problema en asignar diferentes tipos a una misma variable con el tiempo, por ejemplo:

1function getProducts(apiPointer,productCategory){
2	return apiPointer
3		.get()
4		.products(productCategory, apiPointer.config)
5		.then(res=>res)
6	}
7
8

A simple vista no hay problemas en esta función, y obviamente sin ningún tipo de contexto, no tienes mucha idea de cómo funciona o qué cómo debería comportarse, y lo más importante: No tienes idea de qué forma deberían tener esos dos parámetros.

Ahora supongamos que te toca trabajar con esa función y cambiar el método .products debes renombrarlo y hacer que reciba sólo 1 parámetro de tipo objeto con 2 llaves, categoryName y config esto haría que productCategory que podría ser un string ya no sea correcto con este pequeño ejemplo quiero que notes que cuando se trabaja en código que no escribiste tú y que su funcionamiento no es obvio a simple vista se vuelve muy difícil asumir como afectamos el funcionamiento con un pequeño cambio, volviendo dolorosa y compleja nuestra tarea de mantener este código porque seguramente alguno de tus primeros empleos como desarrollador JS serán/fueron de mantenimiento.

2. JS no posee una manera confiable de documentar.

Existen proyectos que con el tiempo han intentado agregar esta característica a JavaScript uno de esos proyectos es JSDoc que nos permite describir funciones, los parámetros que recibe y lo que devuelve usando bloques de comentarios.

1/**
2* Performs an api call to a particular endpoint with certain config.
3*
4* @param {ApiPointer} apiPointer
5* @param {string} productCategory
6* @returns {ApiResponse} Whatever the answer is.
7*/
8function getProducts(apiPointer,productCategory){/* ... **/}
9
10

A pesar de que es mucho más útil tener una descripción de cómo funciona nuestra función, JSDoc no tiene ninguna capacidad de prevenir el uso incorrecto de la función, es meramente texto descriptivo sin cualidades, susceptible al estilo del desarrollador permitiendo con esto que las descripciones sean inconsistentes a través del tiempo, y a veces la creatividad del developer (cuando agregan algo que refleja su personalidad) hace que sean incomprensibles (no es que sea malo que el developer tenga personalidad, es sólo que las bromas locales a veces son muy locales).

Otro problema con JSDoc es que a veces se actualiza la función (por ejemplo si tú la tienes que refactorizar) pero la descripción no se actualiza, volviendo no sólo inútil la misma, también muy confusa.

Y por último, cómo te diste cuenta a veces se definen objetos complejos @param {ApiPointer} en su propio JSDoc pero que no tienen un enlace o una referencia encadenada, haciendo increíblemente difícil buscar estas relaciones y creando una cadena de búsqueda de decenas o cientos de JSDocs que consume mucho tiempo.

3. JS no tiene un "Dev Tooling"

Si trabajas con VSCode, sabrás que tienes acceso a una infinidad de plugins y herramientas cool que te ayudan a completar el código que estás escribiendo en tiempo real, y las linternas (JSLint) son maravillosas para destacar ahí mismo los problemas en tu código, el asunto está en ¿Cuales plugins y linternas deberíamos instalar? y ¿Si yo prefiero esta más que la de mi compañero de equipo? haciendo que el uso de varias linternas destaquen errores diferentes que además destacan errores "estándar" o muy básicos de sintaxis o estilo, pero que no exactamente tienen que ver con cómo funciona tu código.

Además es importante decir que muchos de esos plugins usan Typescript por debajo para ofrecerte los "insights" así que porqué no tener de una vez todas las bondades de Typescript directamente.

Typescript entiende cómo debería funcionar tu código con base en las definiciones de tus tipos, destacando con su linterna no sólo errores de sintaxis, también posibles "crashes" de tu código por un uso incorrecto de tus funciones y objetos en tiempo real, ahorrandote las horas de debugging.

Bonus: ¿Cómo resuelve Typescript lo anterior?

Typescript fue creado de forma interna por Microsoft en 2010 liderado por Anders Hejlsberg (Say my name... ok no) famoso por ser también el responsable de liderar el desarrollo de C# y Turbo Pascal (así que hablamos de un pez gordo eh) y regularmente decimos que Typescript es un "superset" de JavaScript que básicamente NO modifica o agrega funciones al lenguaje sólo le agrega tipos. Typescript es JavaScript con tipos.

Pero es importante saber que Typescript es 4 cosas principalmente, y aquí es donde tú mismo verás con claridad como TS resuelve los problemas de JS:

*Type Checker es el término correcto, por fines de interpretación lo he llamado "checador de tipos" si tienes una mejor definición porfa ¡déjame saberla! (también me gustaba, "comprobador de tipado") pero meh

Conclusión

Ya me voy antes de ponerme más técnico y comenzar a hablar alien.

Mafer walker

la intención de esta entrada es platicarte con palabras humanas, no sólo todo lo qué es TS, también cuales son los problemas que resuelve y un vistazo a cómo se ven esos problemas, muy por la superficie, pero espero que ahora en tan sólo unos minutos de lectura ya sabes porque TS está chido.

Si este contenido te resulta útil o aprendes de él, no dudes en suscribirte a mi lista de correo, en la que comparto más sobre este tema, desarrollo web y JS visual con canvas (porque me gusta mucho jeje).

Gracias por tu tiempo. Nos leemos pronto, un abrazo.

Happy coding <3 Bliss.

Suscríbete a mi lista VIP

Y no te pierdas las actualizaciones

No te enviaré spam. Desuscríbete en cualquier momento.