In this talk, I want to show how we can use Zod to guarantee the type in a React Application at runtime. Environment variables, HTTP requests, forms and so on could create troubles in our applications, mainly if they contain unexpected types. Using Zod, we can create schemas to guarantee the types expected in our editor at runtime. In this way, we can react quickly when an environment variable misses or when someone changes the API contract without informing us.
A small validation layer in our applications can prevent a bad user experience and notify us immediately, so we can fix the problem as soon as possible and mitigate the visualization of wrong data.
Zod === Typescript, but at Runtime in Your React Applications
From:
React Summit 2023
AI Generated Video Summary
Today's Talk discusses how Zod, an NPM library, can guarantee the TypeSystem at runtime, providing all the benefits of TypeScript. Zod's parse method allows for checking if objects match the schema, creating a validation layer between applications and APIs. By combining TypeScript with Zod, developers can ensure type safety at both runtime and build time, preventing code execution with incorrect data and improving the user experience.
1. Guaranteeing TypeSystem at Runtime with Zod
Short description:
Today I talk about how you can guarantee your TypeSystem at runtime using Zot. TypeScript is not able to check types at runtime, but Zod, an NPM library, allows you to create a custom schema that remains alive at runtime. Zod helps you get all the benefits of TypeScript and guarantees your type system at runtime. Each schema exposes a method called parse to check if the object is as expected by the schema. Zod can create a validation layer between your application and the API, allowing you to check if the result of the API is as expected during development.
Hi there, I'm Luca De Pupo, and today I talk about how you can guarantee your TypeSystem at runtime using Zot! So, first of all, who I am? I'm Luca De Pupo, I sign on Software Engine at Dreams, JavaScript and TypeScript Lovers, and in my free time I try to keep content in my YouTube channel and also write some blog posts. I love running, hiking and animal.
By the way, I want to start with a history, so today, almost 10 years ago, born TypeScript, and every JavaScript developer in the world probably was happy. We started to create our interfaces, our types and so on. The world was perfect, but a day, a back-end developer decided to change an API and, unfortunately, change a property from String to Number or Number to String and the result in our application is something like this. Not a number, a string, and so on. This is because TypeScript is not able to check the types at runtime because the code that runs in your browser is Javascript. But how can we prevent this mistake? So our superhero is Zod. Zod is a simple NPM library that allows you to create a custom schema. In this case, the schema is a JavaScript object, so the schema rests alive also at runtime. And this schema contains a definition of your type. In this case, as you can notice, the customer schema is an object with four properties, id of type Number, name, email and phone of type String. Then you can also convert this type, this schema, into a TypeScript type, in this case using the type of method. It's pretty simple, you can use the schema and convert it to TypeScript. This helps you to get all the benefits of TypeScript, but also guarantees your type system at runtime.
Last but not least, each schema exposes a method called parse. This method is used to check if the object is like expected by the schema. In this case, if the object parsed to the parse method is like expected. The customer variable is of type Customer and contains the object. Otherwise, the parse raises an error. This error is of type ZodError and contains the issue and error to understand what is wrong. Which are the benefits of using Zod in our application? Typically, when you create an application, you have your react application and some API to get the data. Using Zod you can create a validation layer between your application and the API. At runtime, you can check if the result of the API is like expected during the development and in this case you are able to run the code only if the types respect the expected type in this case. Otherwise, you can erase an error, show an error to the user and send a notification to Datadog or maybe to Sentry to fix the problem as soon as possible.
So now it's time to see a simple demo to understand how we can use Zod and the benefits of using it. So the demo is pretty simple. There is a list of order and each order has a different property in this case. For instance, if I change my back end, in this case I change the amount from number to string and go back to the application and refresh the page. As you can notice, in this case Zod erased an error and Scribd, which is the problem.
2. Implementing Schemas and Conclusion
Short description:
In this section, we saw how to identify and fix issues in the schema. We also explored how to implement schemas using .object and union types. The schema can be converted to types and used to validate API results. TypeScript understands the result of the parse method and ensures type safety. In conclusion, TypeScript, combined with Zod, allows you to guarantee your type system at both runtime and build time. This helps prevent code execution with incorrect data and ensures a better user experience. You can also receive notifications and take action to fix any issues quickly. Thank you for joining this talk!
As you can notice in the issue property, you can see some info about the problem. In this case, in the path, the first element of the list contains a total object that contains an amount property and this amount property is of type string, but Zod expects a number type. As you can notice, you can have a readable error and you can maybe fix the problem quickly if you want.
So, I go back to that, take back and fix the error and now it's time to see how we can implement this kind of stuff. For instance, in this case, I create a bigger file with all the schema is composed by using .object and for instance, the currency contain an amount of type number and the currency is an union type between dollar and euro, for instance, the same is for the order and so on. Then, if you want, you can also convert the schema to types. Pretty simple using the type of method and then you can use the schema to pass the result of the API, for instance.
In this case, using a fetch, we can call the backend. Using the JSON method, we can pass the result and then using the order array schema, we can pass the result of the data and be sure that the data is of type order model and respect our signature of the type, for instance. For instance, if I use const res='', you can see that the result is an array of order and also TypeScript is able to understand that the result of the parse is an array of order model. So if I go back to the browser and refresh again, as you can notice, now everything is okay because the response is perfect like expected.
Now it's time to go to the conclusion. So, conclusion. TypeScript is awesome, but without you can guarantee your dev system also at runtime if you want. Create a validation layer between your application and the outside, help you to prevent the execution of code with wrong data and maybe to prevent you to see to the user's wrong or strange data in the UI. And also you can get a notification from... You can send a notification to Datadog or to Sendit to fix the problem as soon as possible. Last but not least, using Zod, you can guarantee your type system both runtime and build time. And this is perfect, I suppose, also for you. Okay, that's all. Here are, you can find the slide of the talk. Here you can find my contact, they are open. If you want to chat with me, you are welcome. I hope you enjoyed this talk and bye bye.
Comments