Antes de comenzar, quiero mencionar que soy un fanático de TypeScript. Este es mi lenguaje de programación principal para proyectos front-end en React y para cualquier trabajo de backend que realice en Node. Estoy completamente a favor de Typecript, pero hay momentos que me molestan y sobre los que quería contar este artículo.
Escribí exclusivamente en TypeScript en los últimos tres años para muchas compañías diferentes, por lo que, en mi opinión, TypeScript al menos hace algo bien o cierra ciertas necesidades.
A pesar de sus imperfecciones, TypeScript ingresó a la interfaz de desarrollo principal y ocupa el séptimo lugar en la lista de los lenguajes de programación más populares según el
informe de habilidades del desarrollador de HackerRank .
Cualquier equipo de desarrollo, sin importar si es grande o pequeño, escribe en TypeScript o no, siempre vale la pena por seguridad:
- Asegúrese de que las pruebas unitarias bien escritas cubran la mayor cantidad de código posible en la producción.
- Use la programación de pares: un par adicional de ojos ayudará a detectar cosas más serias que solo errores de sintaxis
- Construya cualitativamente un proceso de revisión de código e identifique errores que la máquina no puede encontrar
- Use linter, como eslint
Aunque TypeScript agrega un nivel adicional de seguridad además de todo esto, en mi opinión, está muy por detrás de otros lenguajes a este respecto. Explicaré por qué.
TypeScript no es un sistema de tipos confiable
Creo que este puede ser el principal problema con TypeScript, pero primero déjame determinar qué
son los sistemas de tipos confiables y
no confiables .
Sistema de tipo robusto
Un sistema de tipos
confiable asegura que su programa no termine en estados inválidos. Por ejemplo, si el tipo estático de una expresión es una
cadena , cuando se evalúa en tiempo de ejecución, se garantiza que solo obtendrá una
cadena .
En un sistema de tipos confiable, nunca se encontrará en una situación en la que la expresión no coincida con el tipo esperado, ya sea en tiempo de compilación o en tiempo de ejecución.
Por supuesto, hay varios grados de confiabilidad, así como varias interpretaciones de confiabilidad. TypeScript es algo confiable y detecta errores de tipo:
Sistema de tipo inseguro
Typecript informa abiertamente que el 100% de confiabilidad no es su propósito. Incluso el número "no objetivo" 3 en la lista "no objetivo" de
TypeScript establece claramente:
Tener un sistema de tipo confiable o "demostrablemente correcto" no es nuestro objetivo. En cambio, nos esforzamos por lograr un equilibrio entre precisión y rendimiento.
Esto significa que no hay garantía de que la variable sea de un tipo específico en tiempo de ejecución. Puedo ilustrar esto con el siguiente ejemplo un tanto artificial:
interface A { x: number; } let a: A = {x: 3} let b: {x: number | string} = a; bx = "unsound"; let x: number = ax;
El código anterior no funciona, ya que se sabe que
ax es un número de la interfaz
A. Desafortunadamente, después de un par de fintas con reasignación, se convierte en una cadena y este código se compila, pero con errores en tiempo de ejecución.
Desafortunadamente, esta expresión se compila sin errores:
axtoFixed(0);
Que la fiabilidad no es el objetivo del lenguaje es probablemente uno de los mayores problemas de TypeScript. Sigo recibiendo muchos errores de tiempo de ejecución en tiempo de ejecución que el compilador
tsc no detecta, pero que el compilador habría notado si TypeScript tuviera un sistema de tipos robusto. TypeScript ahora está un pie en el campo de los idiomas "confiables", y el otro en el "no confiable". Este enfoque de media medida se basa en
cualquier tipo, que discutiremos más adelante.
Estoy frustrado por el hecho de que el número de pruebas que escribo no ha disminuido en absoluto con la transición a TypeScript. Cuando recién comencé, decidí por error que podía reducir la onerosa rutina de escribir una gran cantidad de pruebas unitarias.
TypeScript desafía el estado actual de las cosas argumentando que reducir los costos cognitivos cuando se usan tipos es más importante que la confiabilidad.
Entiendo por qué TypeScript ha elegido este camino y existe la opinión de que TypeScript no sería tan popular si la fiabilidad del sistema de tipos estuviera 100% garantizada. Esta opinión no resistió la prueba:
el lenguaje Dart está ganando popularidad rápidamente, junto con el uso generalizado de Flutter. Y
se argumenta que la fiabilidad del tipo es el objetivo de Dart.
La inseguridad y las diversas formas en que TypeScript proporciona una "salida de emergencia" de una escritura fuerte lo hacen menos eficiente y, desafortunadamente, lo hacen
"mejor que nada" en este momento. Me alegraría que a medida que TypeScript creciera en popularidad, se pusieran a disposición más opciones de compilación, lo que permitiría a los usuarios experimentados luchar por el 100% de fiabilidad.
TypeScript no garantiza ningún tipo de verificación en tiempo de ejecución
La verificación de tipos en tiempo de ejecución no es el propósito de TypeScript, por lo que mi deseo probablemente nunca se hará realidad. La comprobación de tipos en tiempo de ejecución es útil, por ejemplo, cuando se trabaja con datos JSON devueltos por llamadas a la API. Sería posible eliminar toda una categoría de errores y muchas pruebas unitarias, si pudiéramos controlar estos procesos a nivel del sistema de tipos.
Como no podemos garantizar nada en tiempo de ejecución, esto puede suceder fácilmente:
const getFullName = async (): string => { const person: AxiosResponse = await api();
Hay algunas bibliotecas auxiliares como
io-ts , lo cual es genial, pero eso puede significar que tienes que duplicar tus modelos.
Tipo de miedo cualquiera y opción estricta
El tipo any significa "any", y el compilador permite cualquier operación o asignación de una variable de este tipo.
TypeScript funciona bien para cosas pequeñas, pero las personas tienden a poner el tipo cualquiera en cualquier cosa que lleve más de un minuto. Recientemente trabajé en un proyecto angular y vi mucho código como este:
export class Person { public _id: any; public name: any; public icon: any;
TypeScript le permite olvidarse del sistema de tipos.
Puede romper el tipo de cualquier cosa con
cualquiera :
("oh my goodness" as any).ToFixed(1);
La opción
estricta incluye las siguientes opciones de compilación, que hacen que todo sea más confiable:
- --strictNullChecks
- --noImplicitAny
- --noImplicitThis
- --Siempre estricto
También hay una regla eslint
@ typescript-eslint / no-explicit-any .
Distribuir
cualquiera puede arruinar la confiabilidad de su código.
Conclusión
Tengo que repetir que soy un fanático de TypeScript y lo uso en mi trabajo diario, pero siento que es imperfecto y la exageración no está completamente justificada. Airbnb
afirma que TypeScript ayudó a prevenir el 38% de los errores . Soy muy escéptico sobre el porcentaje que se indica con tanta precisión. TypeScript no mejora ni combina todas las prácticas existentes de buen código. Todavía tengo que escribir un montón de pruebas. Se podría argumentar que escribo más código, así que tengo que escribir tantas pruebas. Sigo recibiendo muchos errores inesperados de tiempo de ejecución.
TypeScript ofrece solo la verificación de tipos básica, y el hecho de que la confiabilidad y la verificación de tipos en tiempo de ejecución no formen parte de su propósito deja a TypeScript en el mundo de las medias medidas, a medio camino entre el mejor mundo y el que codificamos ahora.
TypeScript es excelente gracias al buen soporte de IDEs como vscode, donde obtenemos comentarios visuales durante el proceso de impresión.
Error de TypeScript en vscodeTypeScript también mejora la refactorización y los cambios de descifrado de código (como los cambios en las firmas de métodos) que se identifican instantáneamente cuando se inicia el compilador de TypeScript.
TypeScript proporciona una buena verificación de tipo y definitivamente es mejor que ninguna verificación de tipo o simple eslint, pero creo que TypeScript puede ser mucho mejor y las opciones de compilación necesarias podrían complacer a aquellos que quieren más del lenguaje.
Suscríbase a nuestro desarrollador de Instagram
