Cómo el sistema de tipos mejora su código JavaScript

Por lo tanto, no tiene tiempo para dar la vuelta, y el mes ya está luchando por su finalización. Quedan unos días para el lanzamiento de un nuevo hilo en el curso "Desarrollador de JavaScript" , según la tradición, antes de comenzar el curso compartiremos con ustedes la traducción de material útil.

Vanilla JavaScript no está escrito por naturaleza. Incluso puede llamarlo "inteligente", porque puede calcular qué es un número y qué es una cadena.

Esto facilita la ejecución de código JavaScript en un navegador o cuando se ejecuta Node.js. Sin embargo, es vulnerable a numerosos errores de tiempo de ejecución (tiempo de ejecución), que pueden arruinar su experiencia de usuario.



Si alguna vez sucede lo que se describirá más adelante, solo ganará si usa el sistema de tipos.

• Después de recibir una lista de datos, encuentra que cierto campo no existe en uno de los registros. Esto lleva a un mal funcionamiento de la aplicación si este caso no se detecta y no se procesa explícitamente.
• La instancia de la clase que importó no tiene el método al que está intentando llamar.
• Su IDE no sabe qué métodos y propiedades están disponibles para módulos y bibliotecas, por lo que no puede ofrecer la finalización automática de manera eficiente.

Flow, TypeScript o ReasonML

Digamos que tiene una base de código existente que desea hacer más confiable y estable. Teniendo en cuenta los errores de escritura existentes, puede intentar usar Flow o TypeScript para esto (tienen una sintaxis bastante similar).

Por otro lado, usar cada una de estas herramientas voluminosas es complicado. Se cargará con el trabajo de crear tipos e interfaces para el código que no se han desarrollado previamente.

Sin embargo, Flow y TypeScript no brindan un 100% de seguridad al agregar el código de escritura.
Por esta razón, la seguridad de escritura ideal se logra mediante inferencia y hace que las variables de anotación y las firmas de funciones sean más simples.

Ejemplos simples y claramente ideados

Considere el siguiente código:

let add = (a, b) => a + b; 

En JavaScript normal, estos argumentos pueden ser números o cadenas. En TypeScript o Flow, estos argumentos se pueden anotar como:

 let add = (a: number, b: number) => a + b 

Ahora aparentemente estamos configurando exactamente dos valores int. No dos flotadores o dos cadenas; se utilizan otros operadores para sus operaciones de suma.

Ahora echemos un vistazo a un ejemplo ligeramente modificado en Reason:

 let add = (a: string, b: number) => a + b add('some string', 5) // outputs: "some string5" 

Esta característica funciona! Y eso puede parecer sorprendente. ¿Cómo entiende esto la razón?

 let add = (a, b) => a + b; add("some string", 5); /* This has type: string but somewhere wanted: int */ 

Esta característica tenía fallas en el nivel de implementación. La razón tiene diferentes operadores para agregar int, float y string.

El propósito de este sencillo ejemplo es mostrar que es posible tener "errores de tipo" adicionales incluso si esto no elimina la aplicación.

En un programa Reason, los desarrolladores no tienen que lidiar con errores de producción que surgen debido a la incompatibilidad de tipos o valores nulos.

Experiencia de desarrollador

Una de las mejores características de TypeScript es que puede ver sugerencias para mejorar o completar automáticamente en el editor de código.

Esta es un área donde TypeScript tiene prioridad sobre Reason, porque un programa TypeScript no tiene que compilarse perfectamente para ofrecer autocompletado. La razón lo obligará a corregir todos los errores en la sintaxis y los tipos antes de ofrecerle una solución útil.

Así es como funciona en VSCode, pero conozco a muchos desarrolladores de Reason que usan vim. Aquí no entraremos en comparaciones.

Aunque soy un gran admirador de Reason, también escribí aplicaciones en TypeScript o Flow. La onda publicitaria alrededor de TypeScript proporciona un buen incentivo para elegirlo, debido a esto, tiene un gran apoyo de la comunidad.

La razón, por otro lado, es más difícil de usar porque hay menos artículos y documentación disponibles. Espero que con su desarrollo esto se corrija.

Si está interesado en Reason, puede encontrar su documentación aquí . Y siga a personas como @jordwalke , @jaredforsyth y @sgrove en Twitter. Pueden decir mucho sobre el ecosistema Reason / OCaml.

Si desea saber cómo funciona Reason con GraphQL, consulte mi otro artículo, "Razón con GraphQL, el futuro de las aplicaciones web de tipo seguro" .

Estamos a la espera de comentarios sobre el material y, según la tradición establecida, invitamos a todos los lectores a una jornada de puertas abiertas , que tendrá lugar el 25 de marzo por nuestro maestro, Alexander Korzhikov .