Programación TypeScript

Capítulo 1. Introducción Introducción

Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: [e-mail]

Así que has decidido comprar un libro sobre TypeScript. ¿Por qué?

Tal vez sea porque estás harto de esos extraños cannot read property blah of undefined errores de JavaScript. O tal vez has oído que TypeScript puede ayudar a que tu código escale mejor, y querías ver de qué va todo este alboroto. O eres una persona de C#, y has estado pensando en probar todo esto del JavaScript. O eres un programador funcional y has decidido que es hora de pasar al siguiente nivel. O tu jefe estaba tan harto de que tu código causara problemas de producción que te regaló este libro por Navidad (párame si me estoy calentando).

Sean cuales sean tus razones, lo que has oído es cierto. TypeScript es el lenguaje que impulsará la próxima generación de aplicaciones web, aplicaciones móviles, proyectos NodeJS y dispositivos del Internet de las Cosas (IoT). Hará que tus programas sean más seguros al detectar errores comunes, servirá como documentación para ti y para futuros ingenieros, hará que la refactorización sea indolora y hará que la mitad de tus pruebas unitarias sean innecesarias ("¿Qué pruebas unitarias?"). TypeScript duplicará tu productividad como programador, y te conseguirá una cita con esa camarera tan mona de enfrente.

Pero antes de que vayas corriendo a cruzar la calle, vamos a desgranar todo esto un poco, empezando por esto: ¿a qué me refiero exactamente cuando digo "más seguro"? A lo que me refiero, por supuesto, es a la seguridad de tipo.

Tipo seguridad

Utilizar tipos para evitar que los programas hagan cosas no válidas.¹

He aquí algunos ejemplos de que no son válidos:

• Multiplicar un número y una lista

• Llamar a una función con una lista de cadenas cuando en realidad necesita una lista de objetos

• Llamar a un método de un objeto cuando ese método no existe realmente en ese objeto

• Importar un módulo que se ha movido recientemente

Hay algunos lenguajes de programación que intentan sacar el máximo partido de errores como éstos. Intentan averiguar qué querías decir realmente cuando hiciste algo inválido, porque oye, se hace lo que se puede, ¿no? Por ejemplo, JavaScript:

3 + []            // Evaluates to the string "3"

let obj = {}
obj.foo           // Evaluates to undefined

function a(b) {
  return b/2
}
a("z")            // Evaluates to NaN

Fíjate en que, en lugar de lanzar excepciones cuando intentas hacer cosas que obviamente no son válidas, JavaScript intenta hacerlo lo mejor posible y evita las excepciones siempre que puede. ¿Está siendo útil JavaScript? Desde luego. ¿Te facilita la detección rápida de errores? Probablemente no.

Ahora imagina que JavaScript lanzara más excepciones en lugar de aprovechar tranquilamente lo que le damos. En vez de eso, podríamos obtener respuestas como ésta:

3 + []            // Error: Did you really mean to add a number and an array?

let obj = {}
obj.foo           // Error: You forgot to define the property "foo" on obj.

function a(b) {
  return b/2
}
a("z")            // Error: The function "a" expects a number,
                  // but you gave it a string.

No me malinterpretes: que intente arreglar nuestros errores por nosotros es una característica estupenda para un lenguaje de programación (¡ojalá funcionara para algo más que para los programas!). Pero para JavaScript, esta característica crea una desconexión entre el momento en que cometes un error en tu código y el momento en que descubres que has cometido un error en tu código. A menudo, eso significa que la primera vez que te enteres de tu error será por otra persona.

He aquí una pregunta: ¿cuándo te dice exactamente JavaScript que has cometido un error?

Correcto: cuando ejecutas realmente tu programa. Tu programa puede ejecutarse cuando lo pruebas en un navegador, o cuando un usuario visita tu sitio web, o cuando ejecutas una prueba unitaria. Si eres disciplinado y escribes muchas pruebas unitarias y pruebas de extremo a extremo, pruebas de humo tu código antes de lanzarlo y lo pruebas internamente durante un tiempo antes de enviarlo a los usuarios, es de esperar que descubras tu error antes de que lo hagan tus usuarios. Pero, ¿y si no lo haces?

Ahí es donde entra TypeScript. Aún más genial que el hecho de que TypeScript te dé útiles mensajes de error es cuando te los da a ti: TypeScript te da mensajes de error en tu editor de texto, mientras escribes. Eso significa que no tienes que depender de pruebas unitarias, pruebas de humo o compañeros de trabajo para detectar este tipo de problemas: TypeScript los detectará por ti y te avisará de ellos mientras escribes tu programa. Veamos qué dice TypeScript sobre nuestro ejemplo anterior:

3 + []            // Error TS2365: Operator '+' cannot be applied to types '3'
                  // and 'never[]'.

let obj = {}
obj.foo           // Error TS2339: Property 'foo' does not exist on type '{}'.

function a(b: number) {
  return b / 2
}
a("z")            // Error TS2345: Argument of type '"z"' is not assignable to
                  // parameter of type 'number'.

Además de eliminar clases enteras de errores relacionados con los tipos, esto cambiará realmente tu forma de escribir código. Te encontrarás esbozando un programa a nivel de tipo antes de rellenarlo a nivel de valor;² pensarás en los casos de perímetro al diseñar el programa, no como una ocurrencia tardía; y diseñarás programas más sencillos, rápidos, fáciles de entender y fáciles de mantener.

¿Estás preparado para iniciar el viaje? ¡En marcha!

¹ Dependiendo del lenguaje de tipado estático que utilices, "inválido" puede significar una serie de cosas, desde programas que se bloquearán cuando los ejecutes hasta cosas que no se bloquearán pero que son claramente absurdas.

² Si no estás seguro de lo que significa aquí "nivel de tipo", no te preocupes. Lo trataremos en profundidad en capítulos posteriores.