Sumérgete en TypeScript Avanzado

Entonces, hoy intento hablar de algo extraño en TypeScript. En primer lugar, permítanme presentarme. Soy Luca De Pupol. Soy italiano. Soy un desarrollador de software en Niaform, y, si no nos conocen, somos una empresa consultora irlandesa pero estamos ubicados en Estados Unidos, Europa central, Brasil y también en algunas posiciones en India. También amo TypeScript y JavaScript. Intento administrar mi canal de YouTube, pero últimamente no tengo mucho tiempo para ello, y también intento escribir publicaciones para personas técnicas. Amo correr, hacer senderismo y los animales, especialmente los perros. Por cierto, quiero comenzar con una pregunta, y no sean tímidos. ¿Quién ama TypeScript? Levanten sus manos, pero si no les gusta, pueden dejar sus manos abajo sin ningún problema. ¡No todas las personas! ¿Y quién ama JavaScript? ¡Espero que todos, porque están aquí! ¡Pero no todos! ¿Por qué? ¿Por qué están aquí? ¿Quién ama Java? ¿Por qué? De acuerdo. Quiero comenzar con pequeños tips. TypeScript ama JavaScript. Entonces, si amas JavaScript, también deberías amar TypeScript. Pero JavaScript no ama TypeScript. Si tienes un código JavaScript, también puede ser un código TypeScript, pero si tienes un código TypeScript, no es un código JavaScript. Por favor, recuerda, antes debes estudiar JavaScript y luego puedes pasar a TypeScript. Siempre. De lo contrario, TypeScript solo será magia para ti, y en tiempo de ejecución, será un desastre. Y recuerda, el código JavaScript es el único código que se ejecuta en producción. Entonces, si no lo conoces, ¡tu cliente llamará a tu jefe, probablemente! De acuerdo, eso es todo por mis tips, y pasemos al code. Creo que esta charla es como una especie de ejemplo y cosas que podemos hacer con TypeScript. Así que intentaré escribir el código con este escritorio, de lo contrario, mostraré el problema y mostraré la solución directamente desde la carpeta de soluciones. Supongo que si estás trabajando con TypeScript, comienzas a crear los tipos para tu objeto. Por ejemplo, puedes tener, en este caso, el objeto persona, el objeto compañía y en alguna parte, tienes una especie de tipo de unión, por ejemplo, el tipo usuario. Que es una unión entre la persona y la compañía. Comienzas a crear tu objeto, la persona y la compañía, puedes crear una nueva persona a partir de la persona actual, pero en alguna parte de tu code, quieres imprimir el usuario. ¿De acuerdo? Pero el usuario puede ser una persona o una compañía. Pero quieres ser estricto y tal vez quieras crear una función para la persona y crear un mensaje específico para la persona, y luego crear un mensaje específico para la compañía. Y esta función acepta una persona o una compañía.

Lo que sucedió aquí es que quieres detectar si el usuario es una persona o una compañía y llamar a la función correcta. Y también obtener el beneficio de TypeScript, por ejemplo, como puedes notar aquí, si verifico si la persona es una persona en esta línea, básicamente, TypeScript no sabe que este usuario es una persona. Pero quiero ser explícito con mi código. ¿Cómo puedo hacer esto? TypeScript tiene una característica genial llamada type guard. ¿Qué es un type guard? Es una forma de crear una función que permite a TypeScript detectar lo que quieres hacer. Por ejemplo, en este caso, quiero decir, okay, quiero crear una función que acepte al usuario y devuelva algo que diga, okay, el usuario es una persona o no. Las funciones type guard son básicamente funciones simples como esta que deben devolver un booleano. Si es verdadero, se cumple la condición, de lo contrario no. ¿Cómo funciona este type guard? Básicamente, puedes hacer esto, usar persona. Usuario es una persona. Le estás diciendo a TypeScript de esta manera, okay, si el resultado de esta función es verdadero, el usuario es una persona. De lo contrario, es otro tipo de usuario. Y también tenemos que implementarlo. ¿Cómo? Básicamente, es una función simple que acepta al usuario, y puedes hacer, por ejemplo, esto para la solución. El código fiscal es parte del usuario. Ahora hay otro... ¿Cuál es el problema? Lo siento. Persona. Usuario. Código fiscal en usuario. ¿Por qué? Maldición, ¡Dios! Lo siento. Puedo pasar a la solución. Es más fácil. También porque aquí está un poco desordenado. Lo siento. De acuerdo. Básicamente, no sé qué es esto. Esto es otro... Permíteme volver atrás. Lo siento.

Lo que sucedió aquí, básicamente, es que puedes asignar el usuario al tipo 'never', y esto es posible simplemente porque el usuario ahora es del tipo 'never'. Por ejemplo, si olvidaste manejar la compañía, como en este caso, como puedes notar, debería ocurrir un error. Porque aquí el usuario puede ser del tipo compañía, y no has manejado el problema. Imagina, no has manejado el tipo. Por ejemplo, si en el futuro decides agregar el tipo animal, ¿qué sucederá? Recibirás un error de compilación antes de que el código esté en producción. Si olvidas manejar la función. Y esto es fantástico. Porque puedes evitar el error antes de lanzar el código en producción. Y por eso amo TypeScript. También podemos hacer esto de otra manera. Imagina que quieres usar el switch. Sé que el switch no es la mejor estructura en JavaScript, pero también puedes hacer una verificación de tipo con un switch. Ahora, imagina que quieres crear una calculadora que básicamente acepta un usuario. Puedes verificar el tipo aquí. En el caso, tienes el beneficio del tipo literal. Entonces, básicamente aquí, TypeScript sabe que quieres manejar a todas las personas o una compañía. Ya he manejado la compañía en la línea siguiente. Entonces, TypeScript sabe que probablemente quieres manejar a la persona. Y básicamente, lo que sucede aquí, aquí el usuario es un usuario. Pero en esta rama, el usuario es una persona. Y lo mismo ocurre aquí.

Y lo mismo ocurre aquí. Luego también puedes manejar el error predeterminado, la parte predeterminada usando el 'never' si lo deseas. Pero lo que sugiero es siempre agregar el predeterminado con el tipo 'never' y generar el error. Básicamente, esa es la mejor solución porque en tiempo de ejecución, también puedes manejar si alguien llama a la función sin la forma correcta. Y la segunda opción es siempre devolver el tipo. Porque en este caso, si olvidé manejar, por ejemplo, la compañía, recibiré un error en tiempo de ejecución. En tiempo de compilación. ¿Por qué? Porque mi función tiene un bloqueo. TypeScript también puede entender si ya has manejado todas las posibles ramas de tu código. En este caso, solo manejo a la persona, por ejemplo. Y el resultado es este. Recibo una notificación durante la compilación y no en producción cuando el usuario ejecuta mi código JavaScript. Y esto es fantástico. Ahora, puedes hacer lo mismo también si quieres manejar el filtro. ¿De acuerdo? Imagina que tienes una lista de usuarios donde tienes persona, compañía o nueva persona, y quieres filtrar la lista solo por la persona. ¿Cómo? Básicamente, usando el filtro, puedes llamar directamente a tu función 'esPersona'. Vamos. Esta es la función 'esPersona', y puedes ver aquí que la persona es una lista de personas y no una lista de usuarios. Luego hay un pequeño problema. Entonces, si quiero llamar a 'usuario.tipo' igual a 'persona', como puedes notar, no funciona. ¿Por qué? Porque en esta versión de TypeScript, TypeScript no puede entender que esta es una función de tipo. Pero tenemos suerte. Y si nos movemos a la nueva versión de TypeScript, la versión beta, como puedes notar ahora, aquí, la persona es una lista de personas. Y puedes hacer lo mismo también usando el tipo igual a número, TypeScript, cadena, etc., etc. Usando, por ejemplo, una lista de números o cadenas. Y esto es fantástico porque muchas veces uno de los problemas con la versión antigua de TypeScript es que estoy seguro de que esto es una comprobación de tipos para mi usuario. En este caso, para mi tipo. Y la gente tiene que crear un tipo específico solo para pasar la función a través del filtro, por ejemplo. Pero, afortunadamente, con la próxima versión, TypeScript solucionará el problema. Y todos los desarrolladores deberían estar felices.

De acuerdo. Pero también tenemos otra posible solución para manejar el tipo. Y si quieres ser, por ejemplo, más estricto, no quieres devolver un booleano, sino que quieres continuar en el flujo de tu código solo si el tipo o lo que estás verificando cumple con la condición. De lo contrario, hay un error. Podemos hacer esto usando una subfunción. Entonces, básicamente, como puedes notar aquí, he creado un usuario. Y este es un usuario simple. Lo usé solo para forzar el tipo como usuario. Y aquí el usuario es un usuario. Y si vas allí, desafortunadamente, el usuario sigue siendo un usuario. Pero quiero que el usuario en esta línea coincida con el tipo de compañía. Porque estoy seguro de que si paso por esta función, el usuario es una compañía. Ahora puedo hacer esto. Básicamente, permíteme saltar a la solución. Y evitar la codificación en vivo. Entonces, ¿qué pasó? Podemos implementar la función de esta manera. Básicamente, la función es una función. Tienes que usar una función. No puedes usar una variable que sea una función, desafortunadamente. Pero la sintaxis es esta. Dices, de acuerdo. Quiero alojarlo. Y luego tienes que pasar la condición. Por ejemplo, en este caso, quiero verificar si el usuario es una compañía. Luego, la lógica empresarial para verificar el tipo es tu negocio. TypeScript no puede saberlo. Y básicamente, en este caso, si el tipo de usuario es diferente de compañía, está bien. Genero un error. De lo contrario, continúo con el resto del código.

Lo que sucedió aquí, como puedes notar, aquí el usuario es un usuario. Pero si estoy aquí, el usuario es una compañía. Básicamente, si en tiempo de ejecución llamas a la función asset con un tipo diferente que no sea un tipo de compañía, se genera un error. Por favor, captura el error y envíalo a Sentry o donde quieras y revisa en Slack cuando tengamos un problema porque tienes que solucionarlo. De acuerdo. Perfecto. Esta es la primera parte. Luego, cuando tenemos esto en mente, queremos ser más expresivos con nuestro tipo. Permíteme saltar aquí y mostrar otro ejemplo. De acuerdo. Quiero crear el tipo de contraseña, el tipo de entero y el tipo de código fiscal. Luego, tal vez quiero crear el tipo de personalidad y luego también quiero crear mi tipo de persona. Fantástico. Pero básicamente, en mi dominio, la contraseña no es solo una cadena simple. Es una cadena con una regla específica. Por ejemplo, una longitud mínima de 5 y una máxima de 18 y alguna regla extraña. Un entero es un número, sí, pero es un número sin decimales. Un código fiscal es otra cadena con una regla específica. ¿Cómo podemos mostrar, cómo podemos ser más expresivos con nuestro tipo y tal vez no tener esta situación? Por ejemplo, si creo una contraseña aquí, la contraseña es una cadena simple, ¿de acuerdo? Y no quiero que la contraseña, la cadena simple, coincida con el tipo de contraseña. Quiero que alguien verifique la contraseña y convierta mi cadena en un tipo de contraseña real que describa mi dominio empresarial, ¿de acuerdo? ¿Cómo puedo hacer esto? Usando el tipo de marca. Básicamente, si salto aquí, ¿qué son los tipos de marca? Básicamente, los tipos de marca son mágicos, ¿de acuerdo? Dentro de TypeScript. Esta es una de las partes más mágicas de TypeScript. Básicamente, puedes crear una constante de marca que básicamente es algo que permite al compilador de TypeScript detectar que tienes un campo específico en tus tipos que describe el tipo de marca. Luego puedes crear tu tipo de marca que acepta tu tipo. Puedes tener una cadena, puedes tener un objeto complejo o lo que quieras. Y debes dar un nombre específico a este tipo de marca. ¿Qué significa esto? Puedes describir tu contraseña de esta manera. Básicamente, como puedes notar ahora, la contraseña no es solo una cadena simple. Es una cadena con esta sintaxis extraña que describe que esta cadena es parte del tipo de marca contraseña.

Y como puedes notar aquí, la contraseña no coincide con el tipo de contraseña, por ejemplo. Lo mismo ocurre con el entero. Puedo describir mi parte entera con esta parte. Y lo mismo con el código fiscal. Luego tenemos que usar una función para convertir la contraseña en un tipo de marca específico. Lo mismo ocurre con el entero. Y al final, el resultado es este. Ya he implementado la contraseña para ti, pero puedes confiar en mí. De acuerdo. Como puedes notar, creo mucho código boilerplate. ¿Cómo puedo reducir esta parte? Básicamente, podemos usar una biblioteca que se basa en la validación de esquemas. ¿Qué significa esto? Hay bibliotecas específicas, como Zod, que te permiten crear un código JavaScript que puede funcionar en tiempo de ejecución. ¿De acuerdo? Pero también puedes convertirlo en un tipo de TypeScript. ¿Qué es todo este tipo de cosas? Básicamente, puedes crear un esquema de contraseña que comienza con Z. Z es un objeto expuesto por Zod. Bueno, puedes decir que mi esquema es una cadena que tiene un mínimo de 8, un máximo de 32 y también puedes crear tu regla de negocio específica. Puedes hacer lo mismo con la parte entera, por lo que el entero es un tipo de marca entero. También puedes usar el tipo de marca aquí. Y puedes hacer lo mismo con el código fiscal. Y puedes convertir, si quieres, tu esquema en un código de TypeScript real, en un tipo de TypeScript real, por lo que puedes tener tanto el beneficio en tiempo de ejecución como en tiempo de compilación porque básicamente, si creas un tipo, cuando compilas tu código de TypeScript, este tipo desaparece y en tiempo de ejecución, no tienes la garantía de que tus tipos sigan vivos también en ese momento. De esta manera, también puedes verificar esto en tiempo de ejecución, si quieres. Puedes hacer esto usando dos métodos diferentes. El esquema expuesto para ti, dos métodos diferentes, un método schema.pass, que básicamente es como una función de asset que devuelve el resultado con el tipo correcto, por lo que puedes pasar el esquema, como en este caso, el valor, y verificar si el valor es de este tipo, guardarás, por ejemplo, el tipo de marca de la contraseña. Como puedes notar aquí, la contraseña es una cadena. Paso por este esquema, verifico el esquema y el resultado es este. Si tu objeto no cumple la condición, guardarás un error. ¿De acuerdo? También puedes usar una especie de type guard utilizando una función de análisis segura que devuelve un tipo de unión donde el éxito es verdadero y contiene los datos con el tipo de tu objeto, o exitoso con el error. ¿Qué significa esto? Es lo mismo. Puedes crear tu función de análisis segura que acepta el esquema y el valor.

Puedes llamar a schema.safeparser y, básicamente, como puedes notar aquí, este es un tipo de marca de un resultado seguro del tipo de marca. ¿Qué significa esto? Puedes usarlo y, en este caso, si el éxito es verdadero, tienes la contraseña igual a éxito verdadero, y data es un tipo de marca de contraseña, o si es falso, tienes el tipo igual a éxito falso y el error. Lo mismo ocurre con el entero y lo mismo ocurre con el analizador. Puedes validar lo que quieras, cadena, entero, número, objeto, lo que quieras.

También puedes crear tu validación personalizada si quieres usando refine. Esto te ayuda a garantizar tus tipos también en tiempo de ejecución porque, sí, es fantástico poner el tipo número o el mismo tipo, pero en tiempo de ejecución no tenemos ninguna garantía de que este tipo siga vivo, especialmente si tu backend o tu frontend envían lo que quieran en tu API o en tu UI. Por lo tanto, puedes evitar mostrar, no sé, un número o cosas así. Con eso, he completado mi presentación. Espero que lo hayas disfrutado. Este es el código QR para la presentación, pero supongo que te gusta más este código QR que contiene el código. Por último, pero no menos importante, si quieres, en mi cuenta de DevTools, puedes encontrar algunos artículos de blog sobre TypeScript, también en mi canal de YouTube. Estos son mis contactos. Twitter y LinkedIn son gratuitos, así que si quieres enviarme un mensaje, puedes enviarme lo que quieras. Si quieres suscribirte a mi canal de YouTube y a mi cuenta de DevTools, eres libre. Espero que lo disfrutes y muchas gracias. Gracias.

La pregunta principal es, sí, ¿cuáles son tus enfoques para migrar desde una gran base de código JavaScript a TypeScript, o a otra cosa? Ok. Esta es una pregunta interesante, y lo que te digo es que es una pesadilla. Así que no seré honesto. Es una pesadilla. Sí. Pero lo que puedes hacer es intentar dar pequeños pasos. Este es el único consejo que puedo darte. Y tal vez puedas comenzar teniendo una configuración de TypeScript menos estricta. Y luego... Definitivamente no lo trates estrictamente si estás avanzando. Puedes tener la parte estricta en tu primer paso, pero avanza paso a paso y haz esto. Esto puede llevar un año. Así que no... Creo que, sí, si pones una gran S en una configuración de TypeScript, puedes mover las cosas a medida que trabajas en ellas, ¿verdad? A veces es una historia interminable.

Sí. Sí. Totalmente. Ah, hice eso. Correcto. Siguiente pregunta. Quería hacer eso. Ahí vamos. Pregunta rápida. ¿Crees que la documentation de TypeScript está más orientada hacia usuarios advanced que hacia recién llegados? Y si estás de acuerdo con eso, ¿por qué crees que podría ser? Sí. Sí. Desafortunadamente, sí. A veces, para entrar en la parte advanced, también es difícil encontrar respuestas. En algunos casos específicos. Creo que esto se debe a que muchas personas que se acercan a TypeScript no están muy familiarizadas con él y tratan de involucrar a todos los desarrolladores en el entorno al final. Quiero decir, es solo una curva de aprendizaje, ¿no? Sí. Sí. No es solo JavaScript. Es más que eso. Sí. Entonces no es JavaScript. No sé cómo explicar TypeScript, pero es otra parte de JavaScript. Sí. Quiero decir, si haces esa pregunta, quieres ayudar, como escribir algunos artículos para principiantes en TypeScript, si puedes explicarlo mejor. Sí.

Oh, esa pregunta acaba de saltar al principio, preguntando ¿TypeCast bueno o malo? Si estás diciendo que TypeCast es algo, evítalo, por favor. Así de malo. Lo uso solo para la demostración, porque TypeScript es capaz de entender el tipo si usas los dos puntos, no recuerdo. Si eres usuario, si eres, digamos, un usuario constante y creas el objeto en ese momento, TypeScript es capaz de inferir el tipo directamente en el tipo. Y básicamente, pierdes que es un usuario, pero al final es una persona.

Bastante justo. Y creo que tenemos tiempo para una pregunta más. Creo que esta es interesante, dado que fue uno de los primeros ejemplos. ¿No es bastante frágil depender de un tipo de guardia de tipo similar a una propiedad de objeto como base de un tipo de guardia? Sí. Podría ser. Pero básicamente, esta es la única solución que tenemos en este momento en el entorno, en el ecosistema. Y lo que puedo sugerirte, básicamente, es garantizar todo el flujo de tu código, debes crear validaciones en el límite de tu aplicación. Por ejemplo, si estás en una aplicación front-end, al recibir datos de una API o de una parte externa, valídalos utilizando Zod. Así te aseguras de que la entrada de tu aplicación sea la esperada durante tu código de tipo C, y el resto del código, el flujo del resto del código, está garantizado por esta suposición al final. Luego, si estás usando 'any' en tu código, es tu decisión. Pero si eres estricto con este tipo de cosas, básicamente, el resultado es una base de código agradable al final. Sí. Correcto.

De acuerdo. Creo que eso es todo el tiempo que tenemos para preguntas aquí. Gracias de nuevo, Luca. Ahora te dirigirás al puesto de preguntas, así que si tienes más preguntas para Luca, ve a buscarlo allí. Pero sí, muchas gracias. Gracias de nuevo.