Tinselcity

Diferencias

Muestra las diferencias entre dos versiones de la página.

Enlace a la vista de comparación

bytes:typescript [2021/08/06 02:01] (actual)
flynn creado
Línea 1: Línea 1:
 +====== TypeScript ======
  
 +
 +He estado estos últimos días re-escribiendo un pequeño ejercicio que hice hace tiempo, el de [[https://github.com/gezeta-id/kata-tres-en-raya|Tres en raya]] de hace ya unos años. Pero esta vez en TypeScript.
 +
 +
 +==== ¿Por qué? ====
 +
 +No tenía ningún motivo demasiado importante. Principalmente la curiosidad, supongo, o quizá es solo una forma de entretenerme ahora que los únicos trabajos que encuentro parecen ser todos del mercado de la trata de programadores.
 +
 +En cualquier caso, lo que he pensado ha sido hacer algo que ya estuviera hecho. Esto es relevante. Cualquier impresión o conclusión que pudiera sacar está claro que no es necesariamente aplicable a, por ejemplo, un proyecto realizado desde cero en TypeScript.
 +
 +==== Y ¿qué tal? ====
 +
 +Bueno... Creo que la respuesta más clara que puedo dar es //"Eeeh..."//.
 +
 +Tiene algunas cosas buenas, claro. El tema de definir tipos ayuda... //casi siempre//.
 +
 +Un ejemplo claro es que en la versión en JavaScript, para mi tranquilidad y por darle un poco de solidez, tuve que incluir en varios sitios algunas validaciones para los "símbolos" -la ''X'' y la ''O''- que van en las celdas del tablero y que representan a cada jugador. Tener esas validaciones implica además escribir unos cuantos tests unitarios --[[https://github.com/gezeta-id/kata-tres-en-raya/blob/55bb89df432bfab2e5cabb87710830e905234b82/src/test/11-cell-spec.js#L29-L35|p-ej-]] para verificar que las validaciones funcionan como se espera. Esto, en la versión en TypeScript, podemos resolverlo más fácilmente definiendo un tipo de dato que solo puede tomar los valores ''O'' o ''X'' y dejando que sea el compilador quien le entregue esos errores al programador. No sólo se reduce algo el código, también podemos eliminar algunos tests.
 +
 +Por otro lado, mi código original realmente contemplaba que una celda puede //no tener nada//, estar vacía. Y, sinceramente, es muy práctico que ese "no tener nada" sea un ''undefined''. Esto hace, sin embargo, que tengamos que declararlo explícitamente por todas partes que manejamos "una ''X'', una ''O'' //o ''undefined''//" y obviamente tendremos que incluir comprobaciones para ese ''undefined''. A la larga, esto se hace un tanto pesado y complica innecesariamente algunas cosas. No es grave, pero sí un poco feo. En algún otro caso, la declaración de tipos más complejos simplemente lo hace muy tedioso. Algo parecido ocurre al usar ''reduce'', donde terminamos teniendo que tipar el acumulador explícitamente demasiadas veces. Como digo no es grave, pero sí resulta pesado.
 +
 +Otro tema diferente es que, antes o después, incluso en un proyectito casi de juguete como este, se termina viendo el cartón que hay detrás. Sin necesidad de hacer cosas muy complicadas, es fácil que terminemos encontrando el JavaScript que hay debajo del TypeScript. En algunos casos de forma bastante incómoda. Vale, en este caso sí estaba haciendo algo //un poco// turbio. Pero realmente muy poco. Se trata de usar ''apply'' para poder llamar a diferentes métodos de cierta clase -basándonos en su nombre- pasando -o no- diferente cantidad de parámetros adicionales. Seleccionar el método para luego llamarlo con ''apply'' termina produciendo conflictos con el tipo de ''this'', aunque estemos pasando exactamente la misma instancia de la que tomamos el método. En algunos casos como este, el problema es que se mezcla lo que intentamos hacer con lo que intenta hacer el compilador de TS. Es relativamente fácil terminar viéndole algunas de las costuras.
 +
 +Por último está el tema de las herramientas y, en parte, de la documentación. La documentación es razonable, en general. Las herramientas tampoco están mal. Se esfuerzan por trabajar con una aceptable variedad de herramientas ya existentes en JavaScript. Eso está bien, claro, pero también hace que parezca que no hay una forma //recomendada// de hacer algunas cosas. Es el caso de los módulos. TS puede tratar con todo tipo de módulos (ESM, CommonJS, UMD) y, por supuesto, también aporta sus pequeños añadidos propios. También soporta variedad de herramientas de empaquetado. Pero... ¿cuál es la recomendación? También hay pequeños cambios entre versiones de TS donde la documentación te dice cosas como "Hasta la versión tal, esto se hace de la forma X. Desde esa versión se puede hacer de la forma X o de la forma Y", pero en ningún momento dice cuál, X o Y, es preferible o recomendable. La documentación, en general, explica bastantes detalles pero pocos motivos, y eso a veces dificulta algunas decisiones.
 +
 +También reconozco que tengo preferencia por herramientas más simples y que he mantenido la decisión de usar browserify -con //tsify//- en lugar de meter con otras opciones como Webpack, Babel, Rollup, MSBuild, Duo o qué sé yo. Browserify es simple y efectivo y para este experimento no necesitaba más. También he continuado usando Mocha+Sinon+Chai como tenía en la versión original. Ambas cosas han sido relativamente sencillas de configurar. No puedo decir nada sobre esas otras que no he usado.
 +
 +==== En resumen ====
 +
 +Como resumen, lo dicho. La impresión es un poco tibia. Quizá en otra situación aporte más, pero teniendo un proyecto ya sólido en JavaScript, no creo que pasarlo a TypeScript sea algo que merezca la pena. El beneficio no parece compensar el esfuerzo. Algunas cosas se simplifican algo. Otras se complican sin aportar nada interesante a cambio.