Single Blog

Este artículo es prácticamente de opinión. Quería centrarme en TypeScript, este que llaman «el JavaScript con objetos». Para poner en base de lo que hablo, igual es recomendable esta pequeña introducción.

Los saltos tecnológicos normalmente son malos de sobrellevar.
Actualizaciones bruscas en las que cambian criterios; cambios de tecnología por otras más modernas; o cambio en estructura de programación. Sea lo que sea, tiene un coste; y cuanto más tiempo a pasado el coste es mayor.

Uno se encontraba cómodo manejando versiones 1.x y 2.x de TypeScript, para de golpe moverse en versiones 4.x y 5.x del mismo.

¿El resultado? La mayoría del código tal cual está es erróneo.
El cambio va más allá de unos cuantos deprecated.

El «JavaScript con objetos»

TypeScript se suele describir de forma vulgar como «JavaScript con objetos». Al fin y al cabo, el «compilador» del propio TypeScript en realidad efectúa una traducción directa a JavaScript.
Sin embargo, JavaScript es inmune a tipos. Esto quiere decir que una variable number puede ser tratada en otro segmento de código como string sin perjuicio aparente; lo mismo que puedes hacer pasar un objeto por otro similar.
(Disclaimer: Recalco lo de «SIN PERJUICIO APARENTE», amén de estar corrigiéndose en nuevas versiones de JavaScript.)

Las comprobaciones propias de TypeScript

TypeScript de serie tiene sus propias reglas.

La gestión como objetos, sus atributos y métodos, permisos (public, private…), interfaces, tipos, etc. sirven como verificadores.
Si el «compilador» de TypeScript (recuérdese que por definición sería «traductor») detecta algún inconveniente, interrumpe la «compilación» y nos lo hace saber (y tanto!).

Así pues una instancia que manejemos de cierto objeto no puede llamar externamente a métodos que tenga como private.
Tampoco podemos acceder a atributos private o que no tenga.

Si cierto objeto implementa cierta interfaz, deberá hacerlo.
¡En este caso, mucho ojo! Las interfaces no existen (de momento, se está trabajando en ello) en JavaScript.
Aunque muchas veces nos veamos tentados, no podemos comprobar en tiempo de ejecución si una instancia cumple tal interfaz. Lo único verificable son tipos (una class, por ejemplo).

Hacia un lenguaje fuertemente tipado

En sus últimas versiones, TypeScript ha aumentado sus criterios y la cantidad de verificadores.

Así pues, existe el sacrosanto criterio es que todo debe estar definido y tener un valor.

Los tipos básicos todos tienen que tener un valor de base, aunque sean opcionales.
Para ese cometido, se establecen ciertos valores «neutros», «nulos» o «negativos» (según se desee llamar). Estos son:

• number => 0
• string => » (una cadena vacía)
• boolean => false
• any[] (cualquier array) => [] (array vacío)

En cuanto los objetos, serán los únicos que podrán tener valores nulos e indefinidos.

Los objetos deberán estar siempre tipados.
De igual forma, cuando no queda más remedio, se promociona el uso de «unknow» frente a «any». «any» admite atributos (aunque tendremos una advertencia por no definirlo), mientras que «unknow» nunca tiene ningún atributo.

¿Dónde está el problema?

Un lenguaje fuertemente tipado es el sueño húmedo de la ingeniería.
Todo está anclado y bien anclado. Todo está definido y bien definido. Es imposible escribir código que de por sí llegue a romper, pues todo tiene sus mínimos y sus corroboraciones; y si no es así, directamente no compila.

Entonces, ¿dónde está el problema?
La realidad. La realidad no suele ser perfecta.

Obtención de valores desde APIs

Para empezar, podemos encontrarnos con APIs que devuelven unos u otros parámetros.
Parámetros vacíos porque no atañen al producto solicitado, o mismamente que ese producto en concreto no tiene determinada característica.
En efecto, esto vendría a ser un mal diseño desde inicio, pero a veces no queda más remedio que lidiar con ello.

Estableciendo parámetros de consulta

Y tirando de APIs, lo mismo puede ocurrir en sentido contrario: enviar ciertos parámetros u otros.
Aquí ya se posee algo más de control de nuestra parte pero… si al final esto es JavaScript, ¿por qué no montar una variable o constante «params» con directamente la información que queremos enviar?
No corramos tanto, pues esto es TypeScript: hay que declarar exactamente qué objeto se envía y por supuesto cubrir todos los atributos. ¿Y si no debiera enviar determinado atributo «number», ni siquiera un 0? ¿Mal diseño de nuevo?

Atributos destacados

Por último, otro posible problema: tratar, digamos, todo producto como «producto».
Digamos que pasamos a comprar varios artículos. Según el artículo, tiene unos atributos determinados u otros.
Pero cuando pasamos por el carrito de la compra siempre van a importar dos de ellos: «precio» y «peso»; los cuales suponemos que son atributos comunes siempre.
Nos da igual el artículo en ese momento, y así actuamos. Pero… uhmmm… en su momento se pasaba (por consulta o input) el artículo sin más y se miraban estos dos atributos.
Claro, llegados a este punto todos sabemos que hay que especificar tipos sí o sí, pero… ¿qué producto es exactamente y que atributos tiene?
Llegando de otros lenguajes sabemos que esto es un claro caso de herencia entre clases, pero por celeridad al codificar en el antiguo TypeScript no hemos perdido tiempo en diseñar una ingente cantidad de clases de todo tipo de artículo.

Por concluír

Como decíamos, TypeScript ha pasado de ser una extensión de JavaScript a un lenguaje muy fuertemente tipado.
Desde el punto de ingeniería esto sería lo perfecto.
Desde el punto de un programador, quizá no tanto.

TypeScript tenía la facilidad de codificar rápidamente cualquier código usable. Ahora debes invertir mucho tiempo en declaraciones y estructuras que quizá no compensen el sencillo código que se pretendía hacer.