TypeScript War o Enum Conquest

Antecedentes

Hace medio año, nuestra compañía decidió cambiar a tecnologías más modernas y de moda. Para hacer esto, se formó un grupo de especialistas, que debía: decidir sobre la pila tecnológica, hacer un puente al código heredado sobre la base de esta pila y finalmente transferir algunos de los módulos antiguos a nuevos rieles. Tuve la suerte de entrar en este grupo. La base del código del cliente es aproximadamente un millón de líneas de código. Elegimos TypeScript como el lenguaje. Decidieron hacer un sustrato GUI en vue junto con vue-class-component e IoC .

Pero la historia no se trata de cómo nos deshicimos del legado del código, sino de un pequeño incidente que resultó en una verdadera guerra de conocimientos. A quién le importa, bienvenido al gato.

Conociendo el problema

Un par de meses después del inicio, el grupo de trabajo se sintió cómodo con la nueva pila y logró transferirle parte del código anterior. Incluso podría decir que hubo una masa crítica de carne cuando necesitaba detenerse, respirar y ver lo que habíamos hecho.

Los lugares que requieren un estudio profundo, como saben, fueron suficientes. Pero de todas las cosas importantes, irónicamente, nada me atrapó. No como desarrollador. Pero uno de los sin importancia, por el contrario, era inquietante. Me molestó hasta el punto de la locura cómo trabajamos con los datos de enumeración. No hubo generalización. Te encontrarás con una clase separada con un conjunto de métodos requeridos, luego encontrarás dos clases, para la misma, o incluso algo misterioso y mágico. Y no hay nadie a quien culpar. El ritmo que tomamos para deshacernos del legado fue demasiado grande.

Habiendo planteado el tema de las transferencias entre colegas, recibí apoyo. Resultó que no solo no estaba satisfecho con la falta de un enfoque unificado para trabajar con ellos. En ese momento, me pareció que en un par de horas de codificación lograría el resultado deseado y me ofrecí para corregir la situación. Pero qué equivocado estaba entonces ...

//    ,        . import {Enum} from "ts-jenum"; @Enum("text") export class State { static readonly NEW = new State("New"); static readonly ACTIVE = new State("Active"); static readonly BLOCKED = new State("Blocked"); private constructor(public text: string) { super(); } } //   console.log("" + State.ACTIVE); // Active console.log("" + State.BLOCKED); // Blocked console.log(State.values()); // [State.NEW, State.ACTIVE, State.BLOCKED] console.log(State.valueOf("New")); // State.NEW console.log(State.valueByName("NEW")); // State.NEW console.log(State.ACTIVE.enumName); // ACTIVE 

1. Decorador

Por donde empezar Solo se me ocurrió una cosa: tomar como base una enumeración similar a Java. Pero como quería presumir ante mis colegas, decidí abandonar la herencia clásica. Use un decorador en su lugar. Además, el decorador podría aplicarse con argumentos para dar a las enumeraciones la funcionalidad requerida de manera fácil y natural. La codificación no tomó mucho tiempo, y después de un par de horas ya tenía algo similar a esto:


Y aquí sufrí el primer fracaso. Resultó que no puede cambiar el tipo con la ayuda de un decorador. Microsoft incluso tiene una apelación sobre este tema: Class Decorator Mutation . Cuando digo que no puede cambiar el tipo, me refiero a que su IDE no sabrá nada sobre esto y no ofrecerá ninguna pista y autocompletado adecuado. Y puedes cambiar el tipo tanto como quieras, solo lo bueno ...

2. Herencia

Como no traté de persuadirme, tuve que volver a la idea de crear transferencias basadas en la clase general. Sí, y ¿qué hay de malo en eso? Estaba molesto por mí mismo. Se está acabando el tiempo, muchachos del grupo, Dios no lo quiera, estoy pasando tiempo en decoradores. Fue posible presentar una enumeración en general en una hora y seguir adelante. Que así sea. Lanzó rápidamente el código de la clase base Enumerable y suspiró, sintiendo alivio. Lancé el borrador al repositorio general y le pedí a mi colega que verificara la solución.


Pero la tragicomedia estaba ganando fuerza. La versión 2.6.2 de TypeScript se instaló en mi máquina, la versión en la que había un error invaluable. No tiene precio, porque no es un error, sino un fitcha. Una voz de la habitación contigua gritó que no iba a hacer nada. Error al compilar ( transpilar ). No podía creer lo que escuchaba, porque siempre armaba un proyecto antes de un impulso, incluso si era un borrador. Y la voz interior susurró: esto es un fiasco, hermano.

Después de una breve prueba, me di cuenta de que era una versión TypeScript. Resultó que si el nombre genérico de la clase coincidía con el nombre del genérico especificado en el método estático, entonces el compilador consideraba esto como un tipo. Pero sea lo que sea, ahora ya es parte de la historia de esa guerra por el conocimiento de TypeScript.

El resultado final: el problema con las transferencias como era y se mantuvo. Mi pena ...

Nota: No puedo reproducir este comportamiento ahora mismo con 2.6.2, tal vez cometí un error con la versión o no agregué algo en los casos de prueba. Y se rechazó la solicitud del problema anterior Permitir que los miembros estáticos hagan referencia a parámetros de tipo de clase .

3. Función de fundición

A pesar del hecho de que había una solución torcida, con una indicación explícita del tipo de la clase de enumeración en métodos estáticos, por ejemplo, State.valueOf <State> (), no se adaptaba a nadie y, en primer lugar, a mí. Por un tiempo, incluso dejé de lado las jodidas transferencias y perdí la confianza de que generalmente podría resolver este problema.

Una vez que recuperé mi fortaleza moral, busqué en Internet trucos de TypeScript, miré quién sufría de qué, leí la documentación del idioma nuevamente, por si acaso, y decidí, para evitarlo, terminar el trabajo. Siete horas de experimentos continuos, sin buscar nada, ni siquiera café, dieron su resultado. Solo una función, que consiste en una línea de código, coloca todo en su lugar.

 export function EnumType<T>(): IStaticEnum<T> { return (<IStaticEnum<T>> Enumerable); } //  IStaticEnum : export interface IStaticEnum<T> { new(): {enumName: string}; values(): ReadonlyArray<T>; valueOf(id: string | number): T; valueByName(name: string): T; } 

Y la declaración de una enumeración similar a Java ahora se ve así:

 import {Enum, EnumType, IStaticEnum} from "ts-jenum"; @Enum("text") export class State extends EnumType<State>() { static readonly NEW = new State("New"); static readonly ACTIVE = new State("Active"); static readonly BLOCKED = new State("Blocked"); private constructor(public text: string) { super(); } } //   console.log("" + State.ACTIVE); // Active console.log("" + State.BLOCKED); // Blocked console.log(State.values()); // [State.NEW, State.ACTIVE, State.BLOCKED] console.log(State.valueOf("New")); // State.NEW console.log(State.valueByName("NEW")); // State.NEW console.log(State.ACTIVE.enumName); // ACTIVE 

No sin curiosidad, con una importación adicional de IStaticEnum, que no se usa en ningún lado (ver el ejemplo anterior). En la versión muy desafortunada de TypeScript 2.6.2, debe especificarlo explícitamente. Un error sobre el tema aquí .

Total

Si sufres por mucho tiempo, algo funcionará. Enlace a github con el resultado del trabajo realizado aquí . Por mí mismo, descubrí que TypeScript es un lenguaje con excelentes características. Hay tantas de estas oportunidades que puede ahogarse en ellas. Y quien no quiere hundirse, aprende a nadar. Si vuelve al tema de las transferencias, puede ver cómo otros trabajan con ellas:

• Enum basado en dos clases
• Envoltorio de caja

Escribe sobre tu trabajo, creo que la comunidad estará interesada. Gracias a todos por su paciencia e interés.