Guía de supervivencia de TypeScript: Consejos y técnicas que te salvarán la vida

No tener que copiar un tsconfig nuevamente. Para el segundo consejo, quería hablar sobre algo que me llevó algún tiempo entender lo poderoso que realmente era. Estoy hablando de los tipos renderizados. Normalmente, no se ven muchos de estos en el código de TS. Eso se debe a que tienen un caso de uso muy específico. Y son enormemente útiles cuando tienes diferentes tipos de cadenas, pero aún así son cadenas, como un uid. Puedes renderizar el tipo para marcarlo como un ID, aunque sea una cadena. Pero es una cadena de un cierto tipo, lo que hace imposible pasar un nombre a un ID por error, por ejemplo. O incluso pasar el tipo incorrecto de ID a alguna función. Sin embargo, los tipos renderizados solo se pueden convertir mediante una conversión de tipo explícita, lo cual es malo, por lo que podemos crear una función para convertir explícitamente un tipo en otro. Pero aún así, hay una mejor manera de hacer esto. Y te presento el tercer consejo de supervivencia, los type guards y las assertion functions. Cuando usas tipos renderizados, generalmente los siguen uno de estos dos. Porque los guards y las assertion nos permiten reducir el tipo sin tener que convertirlo explícitamente. Puedo convertir explícitamente cualquier cosa en un ID y funcionará, básicamente. El truco aquí es básicamente agregar una nueva función que protegerá el tipo, y esta función está diciendo que un tipo es de otro tipo como una anotación de retorno. De esta manera, podemos hacer una comprobación if y verificar que el ID sea un id con los rejects. Pero esto no es solo agregar ruido, este if ahí. No me gusta. Es por eso que tenemos las assertion functions. Se declaran diciendo que la función afirma que un parámetro es de un tipo dado. Entonces, la diferencia principal entre una y otra es que las assertion functions no devuelven nada, lanzan errores, mientras que los guards devuelven booleanos. De esta manera, los tipos renderizados pueden ser más útiles.

y también puedes crear guards que son livianos. Para el siguiente consejo, Enums. El gran elefante en la habitación. Mientras a algunos no les gustan los Enums, a mí particularmente me gustan. Pero necesitas conocerlos. Así que ese es el consejo. Conoce los Enums. Entonces, empecemos con el básico Enum numérico. Los Enums son una de las pocas estructuras en TypeScript que producen código JS. Parece extraño, pero se asegura de que siempre puedas hacer coincidir un número o su tipo. El problema es que puedes usar ambos y eso medio que derrota el propósito de enumerar cosas, ¿verdad? Entonces, lo que podemos hacer es usar los Enums de cadena que son más fáciles de leer, pero no podemos asignar directamente el valor que contiene a la variable que tiene su tipo. Entonces, necesitas convertir, por ejemplo, una entrada de usuario en un nuevo valor si necesitas asignar ambos. En mi opinión, vale la pena porque estandarizas el código, sin embargo, los tipos de enum también pueden ser un muy buen sustituto para esto. Y el último es un enum constante. No produce ninguna salida porque reemplazará sus llamadas con sus valores en el transpiled.js, como magia. Entonces, en este ejemplo, todos los valores del enum se reemplazarán con sus enums en el código final. No producirá ninguna salida pero tampoco estandarizará las cosas, por lo que todavía aparecerán números mágicos de la nada. Además, los enums constantes no existen en runtime, por lo que no puedes acceder a sus claves o valores de la misma manera que puedes hacerlo con otros. Así que son

se expanden en sus valores subyacentes y eso es todo. No hay vuelta atrás. Para la próxima revolución, algo nuevo, algo bastante nuevo. En PS 5.2, hay una nueva palabra clave, que también llegará pronto a JS, que te permite controlar explícitamente la disposición de recursos y el ciclo de memoria. Es la palabra clave 'using'. Todo comienza con el símbolo dispose o el dispose asíncrono que colocas en una clase de objeto o cualquier cosa que acepte un método de ese tipo. Este método se encargará de disponer del recurso y luego solo necesitas declarar una variable con 'using' asíncrono o simplemente 'using' dependiendo de tu objeto, si es un objeto sincrónico o no. Y este es un consejo muy útil que te puede salvar la vida porque puedes abstraer mucha de la complejidad del ciclo de vida del objeto del uso de ese objeto. Para uno de nuestros últimos tips quiero presentarte el mundo de lo desconocido y cómo podemos salvar muchas vidas. En Klarna, tenemos muchos lugares donde lidiamos con sistemas heredados, especialmente aquellos que se portaron a TypeScript y en todos los lugares donde las personas no sabían qué tipo usar, no hay ninguno y eso es muy malo. Malo porque estamos deshabilitando literalmente TypeScript para esos tipos y no estamos inferiendo nada. No hay tipos, todos sabemos lo malo que es 'any' en general, pero hay una solución. Esta solución es 'unknown'. Comenzamos a implementar 'unknown' y la trampa es que todo se puede asignar a 'unknown', pero 'unknown' no se puede asignar a nada. De esta manera protegemos los data donde realmente se utiliza. Y un buen ejemplo de esto sería el tipado de una función de análisis JSON para que devuelva 'unknown' en lugar de 'any'. Así podemos ver que en el objeto antiguo incluso podemos usar claves que no existen y esto definitivamente fallaría en tiempo de ejecución. Además, 'unknown' es una muy buena manera de migrar de JavaScript a TypeScript porque tan pronto como creas uno, ya conoces todo el camino que ha tomado el recurso y quién lo está usando debido al error que va a crear. Y por último, quiero presentar la utilidad de conversión de casos utilizando mayúsculas, capitalizadas o minúsculas. El contexto de esto es que en Klarna tenemos muchos otros servicios que utilizan snake case y otros servicios que utilizan camel case. Debido a eso, necesitábamos convertir las llamadas y respuestas de la API al formato específico y esto llevó a la creación de estas interfaces duplicadas donde una era en snake case y la otra en camel case. Así que no necesitas hacer esto, obviamente hay una forma demasiado complicada de hacerlo genérico como lo hice aquí, pero en este ejemplo estoy creando un tipo que toma una cadena, la divide en snake case utilizando un tipo recursivo y la convierte en camel case. Y luego podemos usar un tipo de mapeo para mapear todas las claves de un objeto a camel case y ahora no necesitamos duplicar nuestras interfaces más. Y eso fue todo, básicamente. 10 tips en 10 minutos. Así que muchas gracias por estar aquí y por escuchar esto, y si tienes alguna pregunta, únete a mí en mis redes sociales y en los sitios web que se encuentran aquí abajo. ¡Hasta pronto!