TS Congress

TypeScript Congress 2022

We all know, that TypeScript helps us in many ways. The compiler guides us during our work, ensuring, that every piece of data falls into a given place. But there are some limitations. TypeScript was meant to help us during development time. After the compilation step, we still cannot be 100% sure what can happen during runtime... Unless we do something about that and defend ourselves against unwanted runtime errors! This talk serves as an introduction to the problem and explains how we can face it to make our applications more error-proof. by <a href="https://www.froala.com/wysiwyg-editor?pb=1"> </a>

Type Safety at Runtime in Typescript

Hello everyone, today I'd like to walk you through a very cool topic around TypeScript, so type safety at runtime. But before that, I'd like to introduce myself. I'm Kejtan Świątek, I'm a frontend developer from Wrocław, and you can find my work on either Twitter, on at kejtansw, or on my blog kejtan.dev, when I occasionally write about frontend, functional programming, and stuff I learn along the way.

Let me start this presentation by stating that TypeScript is not perfect. And I know it's a pretty bold statement, considering this is a TypeScript conference, and I hope organizers won't ban me for life because of it, but what I mean is that TypeScript, like any other tool, will never meet all expectations of all of its users. And in the early stages of TypeScript, one of the expectations was to have a runtime type system, and the community asked whether it is a missing piece of the TypeScript ecosystem. And this question was answered pretty early, and in 2014, it was stated that runtime type checking remains outside of the design goals for TypeScript. And as you can see, it had pretty mixed feelings from the community, but I think after eight years since that answer, this pretty much settled in in our minds as TypeScript developers. And we got pretty much used to the fact that TypeScript underneath is just plain JavaScript. And what I mean by that is that after our work with our code is done, it compiles down to JavaScript to be interpreted by different runtimes, like Node.js or our browsers. So we got rid of all our interfaces and typolases, so we have no runtime validation for our types. And the simplest example of that may be fetching some data from external API. So this is a common code in our TypeScript projects. We have an interface for our runtime data, and we fetch this data from some API and parse the response to a JSON payload. But you can see in the line seven that we declare that our runtime value is of type hero, but the question here is how sure are we that the return object here is really of type hero? And I can assure you that in this example, we are not 100% sure about that. So what's the potential solution to this problem? This might be runtime types, also known as runtime validators or schema validators or JSON decoders. And what about TypeScript ecosystem? Like with almost every issue, we can either implement it ourselves or use a library for it. And fortunately for runtime types or runtime validators, there are multiple libraries doing just that. And we're choosing a library that suits your needs. There are different criteria that you can use. For example, performance of such parsing. And the best resource for that is called TypeScript Runtime Type Benchmarks, and it's a GitHub repository and you can find it under the QR code here in the corner. And basically it gives you a different statistic around different types of parsing and type assertion and gives you a performance benchmarks of those for different libraries. And like with every other library, the other criteria you can use for finding the one that suits your needs is popularity. And we all like measuring popularity by GitHub stars.

So here we have it, top five runtime types libraries by number of GitHub stars. And those are YAP, AJV, ZAD, IOTS and Runtypes. Here I would like to give you a small preview of one of those libraries. And for that I've chose ZAD. And not because it's the most performant one of our most popular, it's just because it comes out pretty often in the React ecosystem and also it has pretty simple API. So starting from basics, ZAD has something called schema primitives. So primitive schemas for every primitive type of JavaScript and TypeScript, like string, number, boolean, even date or empty type like undefined or null. And from that we can be more specific. For example, create a schema for a string that has a maximum number of characters or minimal or has an email format or URL format, something like that. And for numbers as well, like number greater than some value or lower than some value or an integer value and many other specific methods for those schema primitives. We can also create schemas for more complex data like objects or arrays. For example, with the object method, we create our schema for the dog type by passing the desired structure with name and age, but instead of values, we pass the primitive schemas for those fields. What's also cool about ZAD is also that we can extract the inferred type out of the created schema. So we can create a type of dog by using the inferred type from ZAD. If you are also interested in reusing our schemas, there are some combinators for extending and merging object schemas and for picking and omitting some fields out of the object schema. And how can we use our schemas in practice? So for example, let's create a schema for a basic string type, then we can use the parse method to parse our value. So we passed our runtime value and if the parsing is successful, it just returns our value untouched. But if it's failing, it shows a ZAD error. But if we don't like throwing errors around, we can use save parse method and it returns an object with an information whether the parsing was successful or not. And if it is, it returns our data as a payload or our error object if the parsing fails. That's all from my side. I gave you all the theory behind runtime validators, gave you a list of potential solutions and also introduced you to one of it. And now it's your turn to try it out in your project. Thank you very much for listening and attending this conference and have a nice day.