Zod === TypeScript, pero en tiempo de ejecución en tus aplicaciones React

Hola a todos, y bienvenidos a esta charla sobre Zotter y TypeScript en su aplicación React. Así que, quiero comenzar con una historia. Hace casi un año, nació TypeScript. Y probablemente todos los desarrolladores de JavaScript en el mundo estaban contentos. Así que, comenzamos a crear interfaces para mapear nuestro modelo. Así que, empezamos a usar números, cadenas, booleanos y así sucesivamente. O tal vez tipos, dependiendo del escenario puedes usar interfaz o tipos. Lo que prefieras, no es un problema.

Y en nuestro proyecto todo era perfecto. Teníamos todos los tipos perfectos en nuestra base de código. Y fue un trabajo perfecto para nosotros. Hasta que un día, un desarrollador de backend decidió cambiar la API. Y desafortunadamente, él o ella decidió cambiar la firma de la API. El resultado en nuestra aplicación React es algo como esto. No es un número, no es una cadena de fragmento, o todo tipo de extraño error de JavaScript que puedes imaginar en tu aplicación React. Estos son porque sí, Tileset es fantástico. Me encanta. Pero después de la transpilación, pierdes todos los tipos y el código se convierte en código JavaScript, porque en tu navegador, solo se ejecuta código JavaScript y no código de tileset. A veces los desarrolladores olvidan esto y no se dan cuenta hasta que en producción, no reciben este tipo de error.

Entonces, ¿cómo podemos resolver este problema en nuestras aplicaciones React o JavaScript o Tilescript? Así que, el superhéroe es Zod. ¿Qué es Zod, en primer lugar? Zod es un simple paquete NPM que puedes instalar en tu aplicación React, en tu proyecto, usando tu gestor de paquetes. Puedes usar NPM, instalar, Zod, y todo está listo para usar. Zod tiene un concepto simple, el concepto de esquema. El esquema es un objeto, un verdadero objeto JavaScript en este caso, como puedes notar, que describe tu objeto. En este caso, un esquema de cliente es un esquema Zod que describe que el cliente es un objeto con cuatro propiedades, el ID, con el tipo de número, el nombre con el tipo cadena, el correo electrónico con el tipo cadena de nuevo, y lo mismo para el teléfono. También puedes agregar diferentes restricciones. Por ejemplo, la cadena puede aceptar también una restricción de que esto es un correo electrónico, el teléfono es un teléfono y así sucesivamente. O también puedes construir si quieres tu propio tipo personalizado. Por ejemplo, quieres un caso específico para describir, puedes hacer esto. Pero también puedes, por ejemplo, crear un num, tipo literal, lo que quieras.

Como puedes notar, la sintaxis es bastante similar a la sintaxis de TypeScript. Por lo tanto, no es difícil aprender Zod en este caso. Y puedes importarlo y usarlo usando el objeto Zed en este caso, que puedes importar directamente de la biblioteca Zod.

Luego, sí, en este caso, en este momento, Zod tiene un esquema. Y ahora, tenemos que usarlo. Pero es importante recordar que esto es una const o let, lo que prefieras, pero es un esquema de JavaScript. Así que este esquema permanece vivo también en producción, también durante la ejecución de tu código. Sigue vivo también en producción.

Bien, perfecto. Pero pierdo el beneficio de usar TypeScript, probablemente estás pensando. No, porque usando un método simple llamado typeof, expuesto por la tercera biblioteca, puedes convertir tu esquema en un tipo de TypeScript. Así que en este caso, usando el typeof, podemos convertir el esquema del cliente en un modelo de cliente usando una simple línea de código, bastante simple. Y usando este enfoque, ahora tenemos un tipo de TypeScript, así que el modelo del cliente, y también el esquema del cliente. Entonces, tenemos las cosas para trabajar de la mejor manera con TypeScript, pero también algo que podemos usar en nuestro código para mantener y mantener viva esta definición también en runtime.

¿Cómo? Usando un método simple llamado parse. Cada esquema que creas usando Thud es un objeto. Este objeto expone una función simple llamada parse que acepta un objeto, algo, un objeto, una cadena, lo que quieras, depende de tu esquema. Y esta función parsea tu objeto. Si tu objeto respeta el esquema que has creado durante tu desarrollo, el parse devuelve el objeto, y en este caso, la variable cliente es de tipo modelo de cliente. Así que el parse devuelve exactamente el tipo que esperabas en una tarea.

¿Qué sucede si el parse encuentra una propiedad que no coincide con tu esquema? En este caso, el parse genera un error a través de una excepción, bastante simple. Así que si algo salió mal, recibes una excepción y tienes que manejarla de alguna manera. La excepción es un error de punto. En este caso, el error de punto es una excepción simple, excepto un error, un error de JavaScript con dos propiedades, los problemas y el error. En este caso, puedes encontrar información sobre el problema en el problema y el error, bastante simple. Y es importante capturar y manejar este error porque si tienes un error, tienes que entender qué no se esperaba durante la ejecución de tu código. Y si estás en producción, tienes que react lo antes posible a este problema.

Bien, ahora tenemos toda la noción sobre Zod y es hora de entender dónde podemos usar Zod y todo esto en nuestra aplicación. Así que el primer beneficio que quiero describir hoy es este. Es normal que una aplicación obtenga los data de una API o de un socket. Así que de algo externo a la aplicación. Esta capa de tu aplicación es probablemente la mejor manera de crear una capa para comprobar si tus data que no dependen de ti son como se esperaba durante el desarrollo o durante la creación de la firma. ¿De acuerdo? Así que en este caso, entre tu aplicación y la API externa en este caso, puedes crear una simple capa de validation usando, por ejemplo, un ejemplo simple, tienes una API que recibe una lista de pedidos. Cuando recibes la respuesta, puedes comprobar si el resultado es como se esperaba durante el modo de desarrollo, o durante el desarrollo de tu característica. Así que si esperabas que el pedido tenga un ID, una cantidad, y la lista de productos, también quieres en producción y durante la ejecución, que la respuesta contenga todas estas propiedades. Y este es el primer beneficio de usar VOD. Así que puedes crear una simple capa entre tu aplicación react y el externo. Y cada vez que recibes algunos data, un objeto desde fuera, puedes comprobar si son como se esperaba. Y si es cierto, puedes ejecutar el resto del código con confianza con confianza porque cada objeto es como se esperaba en tu firma, en tus tipos. Como puedes generar un error y enviar una notificación a tu sentry, por ejemplo, y comprobar lo antes posible cuál es el problema y solucionarlo lo antes posible porque probablemente hay un cliente con el problema en tu aplicación, con tu aplicación en este caso. Bien, y este es el primer beneficio.

Pero Zod también puede ayudarte con algunos contratos expuestos por algunas bibliotecas que normalmente usas en tu aplicación. Por ejemplo, ¿cuántos de ustedes usan el UseParamHook expuesto por React-RouterDAO? Bien, este hook es fantástico. Pero, por ejemplo, en este caso, si pides el ID, el ID, el tipo de ID es string o undefined. Y lo mismo ocurre con todos todos los parámetros que decides poner en el UseParam. Y tal vez estás seguro de que el ID es un número, por ejemplo. Y si estás en esta página, el ID es un número y no está indefinido porque el router entra en esta ruta solo si el ID está definido. Para solucionar este problema, puedes usar, por ejemplo, Zot. Por ejemplo, puedes crear tu propio UseParams tipo shape. En este caso, puedes definir el esquema para tus parámetros. En este caso, OrderParamsSchema es un objeto simple que describe que los parámetros contienen un ID. Usando el método Course y Number, comprueba si el ID existe y si es un string. Por ejemplo, convierte este string en un número. Y luego en tu componente React, puedes usar el UseParam tipo shape con el esquema. Y el resultado es que tienes un ID, y el tipo de este ID, en este caso, es un número, como se esperaba. Esta es la implementación. Usando los genéricos, puedes usar el esquema, y puedes pasar el esquema, y la salida y la definición y la entrada del tipo.

Luego pasas el esquema como parámetro, y la devolución es el Z.INF del esquema, por lo tanto, el tipo del esquema. Y la línea nueve y diez es el código real que se ejecuta en el runtime. Así que useParam, obtén todos los UseParam, y usando el schema.pass, puedes pasar el resultado. Vale. Este es solo uno de los casos de uso.

¿A quién le encantan los tipos de prop? No soy un fan de los tipos de prop. Así que creé un with.validation. Este es un componente iOrder que acepta un esquema y un componente. Usando esta sintaxis bastante no simple, puedes pasar el esquema y luego también un componente React y construir una función que cuando recibes una prop, puedes verificar si las props son como se esperaba en tu esquema y si es cierto, puedes alquilar tu componente como puedes generar un error en este caso. Puedes usar esto con.validation de esta manera simple, por lo que puedes definir las props en el esquema y luego cuando exportas el componente, puedes usar el with.validation, puedes pasar el esquema y luego puedes pasar tu componente. Así que has construido un componente React que verifica cada vez si las props del componente respetan el esquema que tienes en mente.

Sí, todo está bien, todo funciona, pero obviamente hay una compensación. Si ejecutas esta verificación cada vez que ejecutas el componente, tu código comenzará a verificar el objeto. Tienes que entender dónde quieres poner este control. Típicamente, en mi proyecto, me encanta poner este control en todos los componentes que reciben data o que son utilizados por una aplicación externa. Quizás, no sé, estás construyendo un pequeño componente que debe ser incluido en otra aplicación. Es importante, en este caso, crear esta capa porque de esta manera, puedes verificar si tu componente se ejecuta como se esperaba, con los data correctos, o si el problema es porque alguien llamó a tu componente React de una manera incorrecta.

Eso es todo. Este es el último escenario donde puedes usar Zod en tu aplicación React. Sí, no solo hay estos tres ejemplos, pero puedes imaginar tu proyecto. Si necesitas algo que valide tus data, esta es probablemente la biblioteca perfecta para ti. Simple conclusión. Esta es mi conclusión personal. Nuestra personal aún, pero espero que estés de acuerdo conmigo. El TypeScript es increíble, pero con Zod, es un poco más. Es un poco más porque me encanta TypeScript, pero estar seguro de que también el código durante la ejecución se ejecuta con los data esperados es perfecto para mí, porque estoy seguro de que todas las suposiciones están bien también en tiempo de ejecución. Crear una capa de validation entre tu aplicación y el exterior es la mejor manera de prevenir que tu código se ejecute con los data incorrectos. Si tienes un problema, puedes enviar una notificación a tu Sentry y react a este problema lo antes posible. Puedes garantizar tu tipo tanto en el runtime como en tiempo breve y esto es fantástico para mí. Si quieres, también puedes mejorar la biblioteca, como en el ejemplo de Reactor-Router-DOM, o también puedes agregar lo que quieras en tu aplicación si necesitas garantizar tu sistema de tipos también en runtime.

Creo que eso es todo. Espero que disfruten de esta charla, y si tienen alguna pregunta, estoy abierto y son bienvenidos. Aquí pueden encontrar el sitio de esta masterclass.

Antes de dejar esta charla, soy Luca Del Pupo, un Desarrollador de Software Senior en NearForm. Soy un MVP de Microsoft, y un Embajador de GitHub. Estos son mis contactos. Twitter y LinkedIn están abiertos, así que si quieren charlar conmigo o dejar un mensaje, no duden en contactarme y son bienvenidos. Si quieren seguirme en YouTube, este es mi canal de YouTube. Si quieren leer algo en mi cuenta de WTO, pueden encontrar algo para leer sobre temas técnicos.

Bueno, eso es todo. Gracias a todos y adiós. Gracias por ver.