¡Hola amigos y amigas! Soy yo, Daniel.
Si me conoces en la vida real, probablemente me habrás oído parlotear largo y tendido sobre algo relacionado con JavaScript. Mi primer trabajo de programación profesional fue casi todo con Vanilla JavaScript, así que me encanta JS desde hace mucho tiempo. A diferencia de otras personas, sus peculiaridades y excentricidades me resultan entrañables. La herencia prototípica es un poco estrafalaria al principio, pero en realidad es bastante sencilla para las necesidades cotidianas. He visto muchas modas ir y venir (te miro a ti, Coffeescript). Dicho esto, tardé mucho en subirme al tren de Typescript. Pero mira, ahora que estoy aquí... Soy TODO EN.
I amor Typescript. Puedes establecer contratos claramente comprensibles para tus estructuras de datos, funciones y clases, y aplicarlos en tiempo de compilación. Eso significa que si alguien hace un mal uso de algo o cambia algún contrato o interfaz, se detecta. antes de ir a pinchar y perjudicar a tus usuarios. Es un código que explica cómo debe utilizarse. ¿Qué puede no gustarte? Ya pensaba en JS de esta manera, ¿por qué no añadir una capa para explicar mis pensamientos? Esto realmente brilla para los equipos o la interfuncionalidad, pero también es genial para mi futuro yo (después de haberme dormido y olvidado todo).
En mi trabajo diario utilizamos Typescript™ pero no siempre ha sido así. Trabajo en una aplicaci mumble-mumble años con muchas generaciones de código: desde los días de React basado en clases con Redux+Thunks hasta los componentes funcionales más modernos basados en React Hooks. Es como excavar a través de capas de sedimento rocoso para descubrir los porqués históricos. Todo lo nuevo está escrito en Typescript y eso sienta muy bien, pero no ayudaba cuando teníamos que profundizar en funciones antiguas (o *gasp* limpiar deudas). Cuando nos dimos cuenta de la alegría de utilizar nuestros nuevos componentes (y del dolor de utilizar los antiguos), quise llegar más rápido. Quería vivir en el futuro, no en el pasado.
Entra en La asombrosamente útil herramienta de AirBnB, ts-migrate.
Quería llegar antes. Quería vivir en el futuro, no en el pasado.
Esta genial herramienta revisará todo tu código base, convirtiendo todos .js(x) archivos a .ts(x).
Lo sé, lo sé, esto parece sucio. Utiliza por defecto el temido cualquier tipo de datos, que es un no-no preferente. En los lugares donde no puede determinar cómo deben interactuar los tipos, inserta un comentario indicando a Typescript que ignore la línea siguiente. De nuevo, lo sé, lo sé, esto no parece menos sucio.
PERO escucha. Estos archivos JS ya se comportan esencialmente así. No hay tipos, así que todo es ya un cualquiera.
Así que, independientemente del asco, esto tiene al menos dos ventajas estratégicas inmediatas:
- Integrar nuevos componentes en componentes antiguos es ahora seguro desde el punto de vista del tipo. Antes de este cambio, bien podrían haber sido JS normales y corrientes cuando teníamos que introducirlos en código antiguo.
- Esto significa que ahora nuestro nuevo código Typescript está tirando hacia arriba de la calidad de estos archivos antiguos, en lugar de que los archivos antiguos tiren hacia abajo de toda la base de código.
- Cada lugar que necesita atención para estar realmente preparado para Typescript está ahora marcado por un comentario o un cualquier tipo de datos. Intentamos limpiar cualquier archivo antiguo que se toque, archivo por archivo. Enumerar la magnitud de un problema puede llevar mucho tiempo en sí mismo; con este enfoque, ya está hecho.
Es un código que explica cómo debe utilizarse. ¿Qué puede no gustarte?
Sé que esa sensación de "suciedad" persistirá en algunos de vosotros, pero os digo... tu vida será mejor por ello. El nuestro es definitivamente mejor. Pudimos desautorizar los archivos JS, forzando así aún más la adopción. Tenemos una enumeración clara de nuestra deuda JS restante. Y la limpieza de archivos antiguos se ha convertido en un fácil añadido al trabajo existente, en lugar de un lío insalvable.
Las ventajas positivas superan con creces cualquier preocupación sobre el desorden creado por un proceso automatizado. Esto no estaba claro antes de utilizarlo, pero ahora está clarísimo. ¿No lo está siempre?
Abraza el futuro: sólo te llevará un poco de tiempo y no te arrepentirás.
ES 
EN 
FR 
DE 
DE_AT 
IT
Esta es una gran lectura para cualquier desarrollador JS que dude en migrar a TypeScript. La honesta visión de los autores sobre la sucia sensación de la conversión automatizada y cómo, en última instancia, mejora la calidad del código es comprensible e inspiradora. Muy recomendable.