Zod === TypeScript, but at Runtime in Your React Applications

Rate this content
Bookmark

Many Javascript developers have added typescript to their projects in the last few years. But how many of them are sure of their types at runtime? Can types be guaranteed on runtime too?


Using Zod that can be realized! Let's see together how we can use Zod to improve the awareness of our code during its execution and prevent strange mistakes or a bad user experience.

20 min
23 Oct, 2023

AI Generated Video Summary

Zotter is a powerful tool for working with TypeScript in React applications, providing a simple schema concept for validation. It allows you to convert Zod schemas into TypeScript types and check if objects match the schema. Zod can be used for validation and contract enforcement, ensuring data consistency and preventing issues. It can also be used in React applications to create a validation layer and prevent code from running with incorrect data. The speaker encourages questions and provides contact information for further discussion.

1. Introduction to Zotter and TypeScript in React

Short description:

Hello everybody, and welcome to this talk about Zotter and TypeScript in your React application. Almost a year ago, TypeScript was born. We started to create interfaces to map our model. In our project everything was perfect. Until a day, a backend developer decided to change the API. The superhero is Zod. Zod is a simple NPM package that you can install in your React application. It has a simple concept, the schema concept.

Hello everybody, and welcome to this talk about Zotter and TypeScript in your React application. So, I want to start with a story. So, almost a year ago, TypeScript was born. And every developer, JavaScript developer in the world probably was happy. So, we started to create interfaces to map our model. So, we start to use numbers, string, Boolean and so on. Or maybe types, depending on the scenario you can use interface or types. Whatever you prefer, it's not a problem.

And in our project everything was perfect. We had all the types perfect in our code base. And it was a perfect work for us. Until a day, a backend developer decided to change the API. And unfortunately, he or she decided to change the signature of the API. The result in our React application is something like this. Not a number, not a snippet string, or all the kind of strange JavaScript error that you can image in your React application. These are because yes, Tileset is fantastic. I love it. But after the transpilation, you lose all the types and the code becomes JavaScript code, because in your browser, run only JavaScript code and not tileset code. Sometimes developers forget this stuff and they don't realize this until in production, they don't receive this kind of error.

So, how we can solve this problem in our React or JavaScript or Tilescript applications? So, the superhero is Zod. What is Zod, first of all? Zod is a simple NPM package that you can install in your React application, in your project, using your Package Manager. You can use NPM, install, Zod, and everything is ready to use. Zod has a simple concept, the schema concept. The schema is an object, a real JavaScript object in this case, as you can notice, that describes your object. In this case, a customer schema is a Zod schema that describe that the customer is an object with four properties, the ID, with the type of number, the name with the type string, the email with the type string again, and the same for the phone. You can also add different constraints. For instance, the string can accept also a constraint that this is an email, the phone is a phone and so on. Or you can also build if you want your custom type. For instance, you want a specific case to describe, you can do this. But you can also, for instance, create a num, literal type, whatever you want.

2. Using Zod with TypeScript

Short description:

The syntax of Zod is similar to TypeScript, making it easy to learn. By using the typeof method, you can convert your Zod schema into a TypeScript type. This allows you to work with TypeScript while maintaining the schema definition at runtime.

As you can notice, the syntax is pretty similar to the TypeScript syntax. So it's not difficult to learn Zod in this case. And you can import and use it using the Zed object in this case, that you can import direct from the Zod library.

Then, yes, in this case, in this moment, Zod has a schema. And now, we have to use it. But it's important to remember that this is a const or let, whatever you prefer, but it's a JavaScript schema. So this schema rest alive also in production, also during the execution of your code. Still alive also in production.

Okay, perfect. But I lose the benefit of using TypeScript, you are thinking, probably. No, because using a simple method called typeof, exposed by the third library, you can convert your schema in a TypeScript type. So in this case, using the typeof, we can convert the customer schema in a customer model using a simple line of code, pretty simple. And using this approach, now we have a TypeScript type, so the customer model, and also the customer schema. So, we have the stuff to work in the best way with the TypeScript, but also something that we can use in our code to maintain and keep alive this definition also at runtime.

3. Using the parse method and handling errors

Short description:

Using the parse method, Zod can check if an object matches the schema you created. If it does, the parse method returns the object with the expected type. However, if a property doesn't match the schema, an exception is raised. It's crucial to catch and handle these errors, especially in production, to quickly identify and resolve any unexpected issues.

How? Using a simple method called parse. Every schema that you create using Thud is an object. This object expose a simple function called parse that accept an object, something, an object, a string, whatever you want, depend on your schema. And this function parse your object. If your object respect the schema that you have create during your development, the parse return the object, and in this case, the customer variable is of type customer model. So the parse return exactly the type that you expected in a task.

What happens if the parse finds a property that doesn't match your scheme? In this case, the parse raise an error through an exception, pretty simple. So if something went wrong, you receive an exception and you have to handle it in some way. The exception is a dot error. In this case, the dot error is a simple exception, except a error, a java script error with two properties, the issues and the error. In this case, you can find info about the problem in the issue and the error, pretty simple. And it's important to catch and handle this error because if you have an error, you have to understand what is not expected during the execution of your code. And if you are in production, you have to react as soon as possible to this problem.

4. Using Zod for Validation and Contract Enforcement

Short description:

Zod provides a simple validation layer between your React application and external APIs, ensuring that the received data matches the expected schema. This allows you to confidently run the rest of your code, as any unexpected objects will raise errors and can be quickly fixed. Additionally, Zod can help with contract enforcement in libraries like React-Router-DOM, where the types of parameters may not match your expectations. By creating custom schemas with Zod, you can ensure that the parameters meet your requirements and have the correct types.

Okay, now we have all the notion about Zod and it's time to understand where we can use Zod and all this stuff in our application. So the first benefit that I wanna describe today is this. It's normal for an application to get the data from an API or from a socket. So from something external to the application. This layer of your application is probably the best way to create a layer to check if your data that doesn't depend from you is as expected during the development or during the creation of the signature. Okay? So in this case, between your application and the external API in this case, you can create a simple validation layer using, for instance, a simple example, you have an API that receives a list of order. When you receive the response, you can check if the result is like expected during the development mode, or during the development of your feature. So if you expected that the order have an ID, a amount, and the list of product, you want also at production and during the execution, the response contains all these properties. And this is the first benefit of using VOD. So you can create a simple layer between your react application and the external. And every time you receive some data, an object from outside, you can check if they are like expected. And if it's true, you can run the rest of the code with confidence with confidence because every object is like expected in your signature, in your types. As you can raise an error and send a notification to your sentry, for instance, and check as soon as possible what is the problem and fix it as soon as possible because probably there is a customer with the problem in your application, with your application in this case. Okay, and this is the first benefit.

But Zod can help you also with some contractor exposed by some library that you usually use in your application. For instance, how many of you use the UseParamHook exposed by React-RouterDAO? Okay, this hook is fantastic. But, for instance, in this case, if you ask for the ID, the ID, the type of ID is string or undefined. And the same is for every every params that you decide to put in the UseParam. And maybe you are sure that the ID is a number, for instance. And if you are in this page, the ID is a number and it's not undefined because the router go inside of this route only if the ID is defined. To fix this problem, you can use, for instance, Zot. For instance, you can create your custom UseParams type shape. In this case, you can define the schema for your params. In this case, OrderParamsSchema is a simple object that describes that the params contains an ID. Using the Course and Number method, check if the ID exists and if it is a string. For instance, convert this string in a number. And then in your React component, you can use the UseParam type shape with the schema. And the result is that you have an ID, and the type of this ID, in this case, is a number, as expected. This is the implementation. Using the generics, you can use the schema, and you can pass the schema, and the output and the definition and the input of the type.

5. Using Zod in React Application

Short description:

Then you pass the schema as parameter and the return is the Z.INF of the schema. This is only one of the use cases. I'm not a fan of prop types. You can use this with.validation in this simple way. If you run this check every time you run the component, your code will start to check the object. This is the last scenario where you can use Zod in your React application. The TypeScript is awesome, but with Zod, it's a bit more. Create a validation layer between your application and the outset is the best way to prevent that your code run with the wrong data.

Then you pass the schema as parameter, and the return is the Z.INF of the schema, so the type of the schema. And the line nine and 10 is the really code that run at the runtime. So useParam, get all the UseParam, and using the schema.pass, you can pass the result. Okay. This is only one of the use cases.

Who loves prop types? I'm not a fan of prop types. So I create a with.validation. This is an iOrder component that accepts a schema and a component. Using this pretty not simple syntax, you can pass the schema and then also a React component and build a function that when you receive a prop, you can check if the props are like expected in your schema and if it's true, you can rent your component as you can raise an error in this case. You can use this with.validation in this simple way, so you can define the props in the schema and then when you export the component, you can use the with.validation, you can pass the schema and then you can pass your component. So you have built a React component check every time if the props of the component respect the schema that you have in mind.

Yes, everything is cool, everything works, but there is a trade-off obviously. If you run this check every time you run the component, your code will start to check the object. You have to understand where you want to put this control. Typically, in my project, I love to put this control in all the components that receive data or that are used from an external application. Maybe, I don't know, you are building a small component that must be included in another application. It's important, in this case, to create this layer because in this way, you can check if your component run as expected, with the right data, or if the problem is because someone called your React component in a wrong way.

That's it. This is the last scenario where you can use Zod in your React application. Yes, there are not only these three examples, but you can imagine your project. If you need something that validates your data, this is the perfect library for you probably. Simple conclusion. This is my personal conclusion. Our personal yet, but I hope you agree with me. The TypeScript is awesome, but with the Zod, it's a bit more. It's a bit more because I love TypeScript, but be sure that also the code during the execution run with the data expected is perfect for me, because I'm sure that all the assumptions are okay also at run time. Create a validation layer between your application and the outset is the best way to prevent that your code run with the wrong data. If you have a problem, you can send a notification to your Sentry and react to this problem as soon as possible. You can guarantee your type both the runtime and brief time and this is fantastic for me. If you want, you can also improve library, like in the Reactor-Router-DOM example, or you can also add whatever you want in your application if you need to guarantee your type system also at runtime.

6. Conclusion and Contact Information

Short description:

I hope you enjoyed this talk. If you have any questions, feel free to reach out to me on Twitter or LinkedIn. You can also follow me on YouTube for more content. Thank you to everyone and bye-bye.

I think that's all. I hope you enjoy this talk, and if you have any question, I'm open and you are welcome. Here you can find the site of this talk.

Before leave this talk, I'm Luca Del Pupo, a Senior Software Developer at NearForm. I'm a Microsoft MVP, and a GitHub Ambassador. These are my contacts. Twitter and LinkedIn are open, so if you want to chat with me or drop a message, feel free to reach out and you are welcome. If you want to follow me on YouTube, this is my YouTube channel. If you want to read something in my WTO account, you can find something to read about technical stuff.

Okay, that's all. Thank you to everyone and bye-bye.

Check out more articles and videos

We constantly think of articles and videos that might spark Git people interest / skill us up or help building a stellar career

React Advanced Conference 2022React Advanced Conference 2022
25 min
A Guide to React Rendering Behavior
React is a library for "rendering" UI from components, but many users find themselves confused about how React rendering actually works. What do terms like "rendering", "reconciliation", "Fibers", and "committing" actually mean? When do renders happen? How does Context affect rendering, and how do libraries like Redux cause updates? In this talk, we'll clear up the confusion and provide a solid foundation for understanding when, why, and how React renders. We'll look at: - What "rendering" actually is - How React queues renders and the standard rendering behavior - How keys and component types are used in rendering - Techniques for optimizing render performance - How context usage affects rendering behavior| - How external libraries tie into React rendering
React Summit Remote Edition 2021React Summit Remote Edition 2021
33 min
Building Better Websites with Remix
Remix is a new web framework from the creators of React Router that helps you build better, faster websites through a solid understanding of web fundamentals. Remix takes care of the heavy lifting like server rendering, code splitting, prefetching, and navigation and leaves you with the fun part: building something awesome!
React Advanced Conference 2022React Advanced Conference 2022
30 min
Using useEffect Effectively
Can useEffect affect your codebase negatively? From fetching data to fighting with imperative APIs, side effects are one of the biggest sources of frustration in web app development. And let’s be honest, putting everything in useEffect hooks doesn’t help much. In this talk, we'll demystify the useEffect hook and get a better understanding of when (and when not) to use it, as well as discover how declarative effects can make effect management more maintainable in even the most complex React apps.
React Summit 2022React Summit 2022
20 min
Routing in React 18 and Beyond
Concurrent React and Server Components are changing the way we think about routing, rendering, and fetching in web applications. Next.js recently shared part of its vision to help developers adopt these new React features and take advantage of the benefits they unlock.In this talk, we’ll explore the past, present and future of routing in front-end applications and discuss how new features in React and Next.js can help us architect more performant and feature-rich applications.
React Advanced Conference 2021React Advanced Conference 2021
27 min
(Easier) Interactive Data Visualization in React
If you’re building a dashboard, analytics platform, or any web app where you need to give your users insight into their data, you need beautiful, custom, interactive data visualizations in your React app. But building visualizations hand with a low-level library like D3 can be a huge headache, involving lots of wheel-reinventing. In this talk, we’ll see how data viz development can get so much easier thanks to tools like Plot, a high-level dataviz library for quick & easy charting, and Observable, a reactive dataviz prototyping environment, both from the creator of D3. Through live coding examples we’ll explore how React refs let us delegate DOM manipulation for our data visualizations, and how Observable’s embedding functionality lets us easily repurpose community-built visualizations for our own data & use cases. By the end of this talk we’ll know how to get a beautiful, customized, interactive data visualization into our apps with a fraction of the time & effort!

Workshops on related topic

React Summit 2023React Summit 2023
170 min
React Performance Debugging Masterclass
Featured WorkshopFree
Ivan’s first attempts at performance debugging were chaotic. He would see a slow interaction, try a random optimization, see that it didn't help, and keep trying other optimizations until he found the right one (or gave up).
Back then, Ivan didn’t know how to use performance devtools well. He would do a recording in Chrome DevTools or React Profiler, poke around it, try clicking random things, and then close it in frustration a few minutes later. Now, Ivan knows exactly where and what to look for. And in this workshop, Ivan will teach you that too.
Here’s how this is going to work. We’ll take a slow app → debug it (using tools like Chrome DevTools, React Profiler, and why-did-you-render) → pinpoint the bottleneck → and then repeat, several times more. We won’t talk about the solutions (in 90% of the cases, it’s just the ol’ regular useMemo() or memo()). But we’ll talk about everything that comes before – and learn how to analyze any React performance problem, step by step.
(Note: This workshop is best suited for engineers who are already familiar with how useMemo() and memo() work – but want to get better at using the performance tools around React. Also, we’ll be covering interaction performance, not load speed, so you won’t hear a word about Lighthouse 🤐)
React Advanced Conference 2021React Advanced Conference 2021
132 min
Concurrent Rendering Adventures in React 18
Featured WorkshopFree
With the release of React 18 we finally get the long awaited concurrent rendering. But how is that going to affect your application? What are the benefits of concurrent rendering in React? What do you need to do to switch to concurrent rendering when you upgrade to React 18? And what if you don’t want or can’t use concurrent rendering yet?

There are some behavior changes you need to be aware of! In this workshop we will cover all of those subjects and more.

Join me with your laptop in this interactive workshop. You will see how easy it is to switch to concurrent rendering in your React application. You will learn all about concurrent rendering, SuspenseList, the startTransition API and more.
React Summit Remote Edition 2021React Summit Remote Edition 2021
177 min
React Hooks Tips Only the Pros Know
Featured Workshop
The addition of the hooks API to React was quite a major change. Before hooks most components had to be class based. Now, with hooks, these are often much simpler functional components. Hooks can be really simple to use. Almost deceptively simple. Because there are still plenty of ways you can mess up with hooks. And it often turns out there are many ways where you can improve your components a better understanding of how each React hook can be used.You will learn all about the pros and cons of the various hooks. You will learn when to use useState() versus useReducer(). We will look at using useContext() efficiently. You will see when to use useLayoutEffect() and when useEffect() is better.
React Advanced Conference 2021React Advanced Conference 2021
174 min
React, TypeScript, and TDD
Featured WorkshopFree
ReactJS is wildly popular and thus wildly supported. TypeScript is increasingly popular, and thus increasingly supported.

The two together? Not as much. Given that they both change quickly, it's hard to find accurate learning materials.

React+TypeScript, with JetBrains IDEs? That three-part combination is the topic of this series. We'll show a little about a lot. Meaning, the key steps to getting productive, in the IDE, for React projects using TypeScript. Along the way we'll show test-driven development and emphasize tips-and-tricks in the IDE.
React Advanced Conference 2021React Advanced Conference 2021
145 min
Web3 Workshop - Building Your First Dapp
Featured WorkshopFree
In this workshop, you'll learn how to build your first full stack dapp on the Ethereum blockchain, reading and writing data to the network, and connecting a front end application to the contract you've deployed. By the end of the workshop, you'll understand how to set up a full stack development environment, run a local node, and interact with any smart contract using React, HardHat, and Ethers.js.
React Summit 2023React Summit 2023
151 min
Designing Effective Tests With React Testing Library
Featured Workshop
React Testing Library is a great framework for React component tests because there are a lot of questions it answers for you, so you don’t need to worry about those questions. But that doesn’t mean testing is easy. There are still a lot of questions you have to figure out for yourself: How many component tests should you write vs end-to-end tests or lower-level unit tests? How can you test a certain line of code that is tricky to test? And what in the world are you supposed to do about that persistent act() warning?
In this three-hour workshop we’ll introduce React Testing Library along with a mental model for how to think about designing your component tests. This mental model will help you see how to test each bit of logic, whether or not to mock dependencies, and will help improve the design of your components. You’ll walk away with the tools, techniques, and principles you need to implement low-cost, high-value component tests.
Table of contents- The different kinds of React application tests, and where component tests fit in- A mental model for thinking about the inputs and outputs of the components you test- Options for selecting DOM elements to verify and interact with them- The value of mocks and why they shouldn’t be avoided- The challenges with asynchrony in RTL tests and how to handle them
Prerequisites- Familiarity with building applications with React- Basic experience writing automated tests with Jest or another unit testing framework- You do not need any experience with React Testing Library- Machine setup: Node LTS, Yarn