ArkType: Bringing TypeScript to Runtime

ArkType is a new runtime validator for TypeScript and the first library with the goal of making type syntax available 1:1 in JS with no compilation step.

It uses a carefully optimized static parser so that with each character you type, you'll see a list of completions, a clear ParseError, or your inferred type. At runtime, a simple definition like "string|number[]" will be transformed into a TypeNode that can be used to validate or transform inputs, compared to other TypeNodes, or combined with other definitions to form new TypeNodes.

This talk will cover the process of building ArkType, with a focus on the type-level parser and runtime type system, and demo some of the most exciting features like scopes, index signatures and generics.

Rate this content
Bookmark
Video Summary and Transcription
The video delves into the capabilities of ArkType in the TypeScript ecosystem, focusing on runtime validation and how it bridges the gap between TypeScript's expressive type system and JavaScript's runtime capabilities. ArkType enhances the validation process by offering features like generic inference capabilities and morphs, which handle transformations at the property level. This approach avoids the function coloring problem and allows for more efficient type combinations. The shift-reduce parser method is highlighted as a key innovation, enabling efficient parsing of complex syntax and improving performance. ArkType's integration with TypeScript's type system ensures type-safe strings and optimizes validation processes, making it significantly faster than other validators. The video also covers the development journey from 'parse type' to ArkType, emphasizing improvements in runtime validation and the ability to define custom keywords within a scope.

FAQ

David developed a solution called 'arc type' that leverages TypeScript's type system for runtime validation.

Arc type offers features like generic inference capabilities, scope for custom keywords, and morphs for handling transformations, all integrated with TypeScript's type system.

Arc type handles transformations granularly, avoiding the function coloring problem and allowing types to be combined with other types more effectively.

Arc type can implicitly discriminate large unions and perform validations much faster, often 20-30 times faster than other top validators in complex scenarios.

David initially used a top-down parser approach but switched to a shift-reduce parser due to the former's limitations with complex syntax and performance.

The shift-reduce parser is a method that keeps track of state and operates on tokens in a loop, making it more effective for parsing complex syntax and more efficient in TypeScript.

Arc type includes a type-level testing framework called 'a test' that benchmarks type instantiations to ensure performance and accuracy.

Arc type's integration with TypeScript's type system allows for deep type system knowledge and optimizations, leading to more efficient validation and type comparisons.

David's talk focuses on runtime validation within the TypeScript ecosystem.

David believes there is a gap between the expressiveness and power of TypeScript's type system and its runtime validation capabilities.

1. Introduction to Runtime Validation in TypeScript#

Short description:

Hey, everyone, my name's David. I'm here to talk about runtime validation in TypeScript. There are great solutions out there, but there's a gap between TypeScript's expressiveness and runtime capabilities. I asked myself how we could express a TypeScript type for runtime use. The answer is simple: leverage the same structures as JavaScript. With some adjustments, we can achieve a one-to-one parallel between TypeScript and runtime validation.

Hey, everyone, my name's David. I'm very lucky to be here today and have the chance to talk to you about one of my absolute favorite topics in the TypeScript ecosystem, which there are many. But as many of you may know, one of them is perhaps the nearest and dearest to my heart, which is runtime validation. So this is something that's been discussed very frequently by the community in the past and solved many times by some fantastic engineers. So there are some great solutions to this out there.

But when I was looking at this problem, I couldn't help but feel there was this gap between the expressiveness and power of TypeScript and its type system and its syntax versus what was available at runtime through some combination of builder methods or various things like that. So essentially this is a couple years ago I asked myself this very dangerous question of what is the closest we could get to expressing a TypeScript type like this in a way that we can use at runtime. So remarkably the answer is pretty simple. And I don't think there's actually as much ambiguity as there is when you're answering most design problems like this. So luckily TypeScript leveraged a lot of the same structures for its object literals, tuple literals, etc. as our built in to JavaScript.

So we can do the same thing. We can say name as a string. Sure. OK. So we have to embed this. We got a device. We got a nested object here. Platform. So this will be a little tricky because they're already in a string. So probably have to do some kind of nested quotes or something like that. So that we know we're still in a string literal since Android and iOS aren't keywords. And then just a couple ways you could go about this one. But let's just go with this. So this is the closest I think you could basically get to a one-to-one here, if you compare these two things, look at this. You know, we don't have an as const here, but essentially these two have a very strong parallel, right. So the question is, is this structure something that we could theoretically use for runtime validation in a way that captures the essence of what makes TypeScript index so powerful and extends that for some of the core needs of a runtime validator.

All right, so fast forward, give or take a few months. Basically what I'm facing here is we need some way to take that original structure that looks just like TypeScript type but infer back out the original TypeScript type without all that runtime embedded syntax that's designed to fit within JavaScript. So essentially, after some iteration, I came up with this initial solution.

2. Evolution of Top-Down Parsing#

Short description:

You can see that I called it parse type, which eventually evolved into arc type. It was the beginning of my iterate on types, type iterate. It had some inherent limitations. I added cyclic inference capabilities. I added function parsing for some reason. This top-down approach had little control over precedence and other issues. Eventually, I realized it's not going to work for a fundamentally scalable solution.

You can see that I called it parse type, which eventually, as you can probably guess, evolved into arc type. And it was just a simple process of a couple of years and some iteration. So as you can imagine, this is the beginning of my iterate on types, type iterate. And it has, kind of, been a theme since then. But there's a few intermediate stages and you'll be able to see a little bit about how some of this evolved.

So this is my initial stab at things. It's got some fairly complex types in it. It's this top down parser approach doing a lot of pattern matching. It's a pretty... I'll say familiar. I mean, this is a little crazy stuff still. But in terms of what had been done within TypeScript in the past for parsing, it is kind of this, like, hey, does this match this template expression? If it does, then infer this part of the syntax. Otherwise, do the same thing. So somewhat straightforward. But I would find that it had some kind of inherent limitations.

So got some nice error messages. Impressively, one of the first things I added was this, kind of, cyclic inference capabilities. So it's able to do that. So that's cool. I added function parsing for some reason, which is useless for run time validation. So I think I just thought it was cool or something. I'm not sure why that was there. This precedence issue would kind of continue to be a thorn in my side. Because I had very little control with this top-down method in terms of ensuring, for example, that the array operator had higher precedence than the union operator. And that was really the most straightforward manifestation of this issue. As I went on, I would discover others, like trying to represent string literals like this, yes or no. Well, you need to make sure that it's not interpreted as the string literal containing that union operator. So this top-down approach, you know, I'm going to continue and try to work around it for a while. But eventually I'm just going to figure out, you know, it's just not going to work. This case was the specific one that made me realize, okay, there's no way that I'm actually going to be able to use this approach at all if I want a fundamentally scalable solution.

3. Shift-Reduced Parser and Improved Efficiency#

Short description:

Both in terms of performance and in terms of capabilities of parsing more complex syntax. The idea of a shift-reduced parser is a fundamental breakthrough that made arctype possible. Instead of a top-down approach, we keep track of a state with various branches and data to parse a string. TypeScript handles this efficiently, allowing us to represent complex syntax and write types close to imperative runtime code.

Both in terms of performance and in terms of capabilities of parsing more complex syntax.

Okay. So where do we go from here? How do we solve this problem? This ridiculous type with the union operator and two string literals, and how are we going to do this? Pattern matching is kind of at its limit here in terms of what we're going to get. So where do we go?

All right. So back to present day. We're back in our editor. It was that problem that really led me to the first sort of fundamental breakthrough that made arctype possible. It's the idea of a shift-reduced parser. So it's pretty different from the top-down approach that we had before. Let's see if I can find this.

And basically what you have is, instead of having this top-down approach where we are matching against various expressions across the whole string, this is, you know, there's a lot going on here. But the core of what you really need to understand is that we actually are keeping track of a state that has various branches and has groups and various other data that we need in order to parse a string. And it's just a simple algorithm where we're looping, checking if we have something to operate on. So, for example, maybe it's string or number or the literal five. Or we don't, and we need to get something to operate on. So we keep looping like this. If we don't have anything to operate on, we get something to operate on. And if we do, we figure out what's operating on it. So it's actually really straightforward. And it lends itself really well to this problem.

TypeScript handles this incredibly efficiently as we'll get into a little bit in the future. Basically using this method, both allowed me to represent much more complex syntax than I would have otherwise been able to do. But also allow TypeScript to do it much more efficiently, which was really surprising to me. Because the logic is not trivial. This is in my opinion kind of one of the more beautiful parts of the type level implementation here. You can kind of look and see this parallel between the runtime implementation of the parser and the static implementation of the parser. And certainly, you know, in this case, I definitely went a little bit out of my way to kind of create that parallel, but it really kind of demonstrates, in my view, that with some of the right patterns in mind, types can be written that really are quite close to imperative runtime code in terms of their expressiveness, in terms of their capabilities. Of course, eventually you're going to hit the limits of TypeScript's type system a lot faster than you're going to hit the limits of your language in general. But for something like this, it works remarkably well. You can kind of, again, see some of the patterns here where we're checking the remaining part of the string, we're kind of just getting the next token, and then based on that, making some decisions about what to do with the state and how to continue.

4. Benefits of Runtime Validation in TypeScript#

Short description:

This is a remarkably effective way to parse strings in TypeScript. It provides flexibility to handle complex cases and can scale as needed. It's efficient and has the potential to revolutionize type authoring for runtime validation.

So, again, this is really a remarkably effective way to parse strings in TypeScript. Everyone should totally use, if you're parsing something more than trivial, this is absolutely the way to go. Maintaining the current state, getting the next characters, and it gives you as much flexibility as you need to handle these very complex potentially cases where you're maybe having to disambiguate between various operators or things like that, things you'd never be able to do with a top-down approach. So it really can scale as far as you need it to, which was amazing for me to find. I thought that I had kind of hit the end of the road in terms of a lot of the utility of the project when I ran into that last problem, thinking that this kind of implementation would just be out of reach in terms of performance for the compiler and everything. But to the contrary, it's actually much more efficient. And this was the breakthrough that I had, where I was like, wow, this really has a lot of potential. Like, if I can parse arbitrary syntax, and it's really performative to do that, and then I can infer that one to one as types, who really knows where this thing could go? This could feel amazing to author our types for runtime, get live validation and everything. So I was really, really excited.

5. TypeScript Type Safety and Performance#

Short description:

If you're a grizzled veteran of the TypeScript ecosystem, you might have some alarm bells going off in your head when you see types like this. Libraries with similar types often crash TypeScript servers. To address this, we built a framework called a test that benchmarks the number of instantiations contributed by any expression. We ensure accurate and performant inference, even for complex types. The type level parser capabilities are advanced, providing an IDE-like editing experience. Strings are now type safe within TypeScript's type system.

So if you're a grizzled veteran of the TypeScript ecosystem, and see a type that looks like this one, my guess would be, probably have some alarm bells going off in your head. Because despite my enthusiasm, your experience might be that when libraries have types like It's very frequent that they will, for example, crash your TypeScript server. That's maybe the most frequent reaction I get when someone sees Archetype for the first time by a factor of three or four. But rest assured, the problem itself kind of necessitated, we come up with some better solutions for type level testing, including performance testing.

So we built a framework called a test that can benchmark at a type level, the number of instantiations contributed by any expression. So you can see that we have this very granular metric for every type of expression in Archetype. We can ensure that it's inferred performantly and accurately, even for a very complex types like this one. You know, we know that it's going to do exactly what you expect and it's going to do it very quickly. So you don't notice any delay whatsoever.

And in terms of functional assertions, for example, we could check out our divisibility tests over here. A little bit more space. You can see that the types of assertions we're making here at a type level, we have all sorts of syntactic errors, semantic errors. At this point, the capabilities of the type level parser are really, really advanced and essentially on par with a kind of like native IDE editing experience. So, for example, let's say you want to define some type. Say it's a number. Of course you get autocomplete for everything in your scope, including all the keywords. And then maybe it's divisible by two. It's not going to affect the inference. That's a runtime constraint. But if I were to write, oh, you see we're missing an operand there. Oh zero. You get a specific error for that. Let's say I try to divide by unknown. Essentially we can narrow down exactly what the problem is whenever anything goes wrong like this. So the idea of strings not being type safe, that's also out the window. Again, this is really on par with the native IDE experience just from within TypeScript's type system. So that's a really, really exciting point to be at with all this. And I've just been so excited to share with you all for so long. So but even with all this implemented there was one thing that was nagging at me as I was getting ready to release this quite a while ago. And it was just something about the way the types composed together and reduced together that didn't feel quite right.

6. Enhancing Type Comparisons and Runtime Constraints#

Short description:

I wanted the ability to compare arbitrary types together, reduce intersections and unions, and have a runtime type system. TypeScript now treats runtime constraints like divisors, ranges, and regex with the same rigor as comparisons between other types.

I couldn't put my finger on it because I really work much with type systems in the past. But what I eventually figured out what I was missing and what I wanted was the ability to compare arbitrary types together, the ability to reduce intersections and unions as completely as possible to go beyond shallow validation capabilities and truly have a runtime type system. And you can see some of that after very significant iteration has finally come to fruition where in addition to the kind of standard constraints that TypeScript covers, it treats runtime constraints like divisors, ranges, regex, etc., with the same rigor that you treat comparisons between numbers and strings and objects and things like that.

7. Integration of Validation and Type System#

Short description:

It's all integrated together into a single type safe system that you can use, for example, to do more than just define validators. It's essentially a full type system as well at this point on top of all the validation capabilities.

It's all integrated together into a single type safe system that you can use, for example, to do more than just define validators. You can compare them to one another. You can say, you know, does this numeric type extend some other numeric type that maybe is an integer or it's divisible only by one. And it will, because it's more specific than that. So it's essentially a full type system as well at this point on top of all the validation capabilities, and really this was an amazing problem to work on. It gave me a much deeper understanding of the kind of work that the TypeScript team does, and really it was just a lot of beauty in having a chance to work with these kinds of types.

8. Validation Capabilities and New Features#

Short description:

Archetype offers significant improvements in validation capabilities, such as automatic discrimination of unions and optimized runtime validation processes. It outperforms other validators in terms of performance, especially in cases where it can leverage its deep type system knowledge. The upcoming release of Archetype introduces new features like generic inference capabilities and the ability to define custom keywords within a scope. These features enhance the flexibility and power of runtime validation in TypeScript.

In general, to find the, you know, simplest possible representation that allows types to be composed together, compared against one another, and reduced fully was really such an amazing problem to work on, and it led to a lot of really significant new capabilities within validation as well.

By having this type information, for example, we can do things like discriminate unions automatically. So for example, in archetype, you can just define a union like this directly, and essentially we will, within our type system, identify the optimal discriminant, or set of discriminants, in case, you know, it requires multiple checks to figure out which branch you're on, and we'll implicitly, you know, optimize the actual runtime validation process around leveraging those checks so that most unions are, without you even having to think about it, going to be checked in constant time, whereas other existing validators without that type system information are either just going to be checking it linearly, or they're going to require you to, you know, opt in and manually specify it through a syntax like this.

Zod, I think, actually, specifically recently was having some issues maintaining their discriminated union types, and, you know, even defining it explicitly, it's really expensive at a type level. You can see there's a massive disparity of about 20 times fewer instantiations for the union here, and of course it's just a much more straightforward type to define and read as well. You mouse over it, you see exactly what the union is, versus we go here, and I mean, I don't use Zod constantly, but it's a lot harder to tell what's going on exactly without being able to, you know, see many of the parameters, and maybe you have to pull it out with Zod.infer. But there are some pretty significant disparities, and largely those come out of the two major areas we've discussed. The ability to use the runtime type system to optimize the validation process, so we don't need to rely on user-provided information like this, as well as the optimizations in TypeScript's type system to ensure that this can be parsed much more efficiently.

So, in terms of runtime performance in general, Archetype has been very heavily optimized, and for the sort of base case checking simple props on an object is going to be basically identical to some of the top runtime validators performance wise that are out there, like Tibia and TypeBox. But where it really shines is these cases where it can leverage its deep type system knowledge, for example, to implicitly discriminate a large union. It could very easily result in speeds of 20 or 30 times faster than even those most performant validators in cases where, again, it can, through multiple steps, identify which checks it needs to make sequentially in order to determine which branch of a union it's on, and often we'll be able to check that union in constant time without you having to even think about it. Whereas again, the alternatives are sort of generally to not have that option at all, or to have to build in that logic manually and maintain it as your tech changes. And as a point of reference, those base cases I was talking about for existing performant validators are already about 400 times faster than Zot for these kinds of scenarios. So, certainly, if you need to optimize around performance, there's going to be some really big gains to be had in that area as well.

So I know we're sort of running out of time here, I just wanted to demo a couple of my favorite features from the upcoming release, which hopefully, I guess, is the current release now that you're seeing this video. It's been hard getting to this point, there's so many things that I wanted to cover. The scope definitely grew quite a bit beyond what I had anticipated in terms of the improvements for beta. But hopefully, if you're seeing this, and I was able to wrap everything up the way that I intended, you can try all these things out now. But regardless, I wanted to show off some of these generic inference capabilities, which I feel are very cool, so there's a new feature in beta that you can define these generic types. You can define a signature like this and then reference a type parameter and then instantiate it later on and you just get this one to one inference. Again, it's just like TypeScript. And then, it will work for runtime validation as well. You can define them within a scope, which is essentially a way to bind keywords, your own custom keywords, to whatever types that you want. So, this one is probably the most kind of mind-blowing type within TypeScript's type system that's in here. You can see we've got this alternate generic that takes A and B and it calls itself, and then swaps A and B. This is just a classic TypeScript recursive generic, but this can actually be inferred within archetype and you can see that, in fact, you get these alternating inputs. If we instantiate it later, we pass it off or on instead of 01, you get the expected result and those two are toggling back and forth. So, the fact that all this ends up actually being possible within TypeScript was really incredible for me to discover. Again, props to the TypeScript team for creating such an amazing parser, an amazing tool that would support probably unintentionally this kind of level of depth just within its own type system. I think it's incredible.

9. Archetype's Morphs and Transformation Handling#

Short description:

The last feature I want to show is morphs, which handle transformations in Archetype. They are built into the type system and allow granular handling of transformations at the property level. This avoids the function coloring problem and provides a visual representation of the transformations. It's a unique and useful feature.

So, the last feature that I just wanted to show off quickly, which actually does exist in alpha, but because it's a really major part of what Archetype does in addition to scope, which I barely had a chance to go over, but unfortunately it's just 20 minutes is a very short amount of time, so much here, but of course I'm so excited to follow up with you all. Morphs are how Archetype handles transformations. What's really unique about them is they're actually built into the type system. So, instead of just at a high level, shallowly kind of marking everything as an effect where it can't be combined with types anymore, they're handled granularly so that only at the particular property where this transformation occurs is it considered a morph and can't be combined with another morph. But, in general, it just avoids the function coloring problem where, more broadly, the type can still be used as a type intersecting with other types, union with other types, etc., etc. And you get this really nice visual representation of exactly what kinds of transformations are going to occur. So, I think that's a really nice feature as well, and I hope you guys enjoy it.

David Blass
David Blass
21 min
21 Sep, 2023

Comments

Sign in or register to post your comment.

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's Most Useful Types
React Day Berlin 2023React Day Berlin 2023
21 min
React's Most Useful Types
Top Content
Watch video: React's Most Useful Types
Today's Talk focuses on React's best types and JSX. It covers the types of JSX and React components, including React.fc and React.reactnode. The discussion also explores JSX intrinsic elements and react.component props, highlighting their differences and use cases. The Talk concludes with insights on using React.componentType and passing components, as well as utilizing the react.element ref type for external libraries like React-Select.
TypeScript and React: Secrets of a Happy Marriage
React Advanced 2022React Advanced 2022
21 min
TypeScript and React: Secrets of a Happy Marriage
Top Content
React and TypeScript have a strong relationship, with TypeScript offering benefits like better type checking and contract enforcement. Failing early and failing hard is important in software development to catch errors and debug effectively. TypeScript provides early detection of errors and ensures data accuracy in components and hooks. It offers superior type safety but can become complex as the codebase grows. Using union types in props can resolve errors and address dependencies. Dynamic communication and type contracts can be achieved through generics. Understanding React's built-in types and hooks like useState and useRef is crucial for leveraging their functionality.
Making Magic: Building a TypeScript-First Framework
TypeScript Congress 2023TypeScript Congress 2023
31 min
Making Magic: Building a TypeScript-First Framework
Top Content
Daniel Rowe discusses building a TypeScript-first framework at TypeScript Congress and shares his involvement in various projects. Nuxt is a progressive framework built on Vue.js, aiming to reduce friction and distraction for developers. It leverages TypeScript for inference and aims to be the source of truth for projects. Nuxt provides type safety and extensibility through integration with TypeScript. Migrating to TypeScript offers long-term maintenance benefits and can uncover hidden bugs. Nuxt focuses on improving existing tools and finds inspiration in frameworks like TRPC.
Stop Writing Your Routes
Vue.js London 2023Vue.js London 2023
30 min
Stop Writing Your Routes
Designing APIs is a challenge, and it's important to consider the language used and different versions of the API. API ergonomics focus on ease of use and trade-offs. Routing is a misunderstood aspect of API design, and file-based routing can simplify it. Unplugging View Router provides typed routes and eliminates the need to pass routes when creating the router. Data loading and handling can be improved with data loaders and predictable routes. Handling protected routes and index and ID files are also discussed.
Faster TypeScript builds with --isolatedDeclarations
TypeScript Congress 2023TypeScript Congress 2023
24 min
Faster TypeScript builds with --isolatedDeclarations
Top Content
This talk discusses the performance issues in TypeScript builds and introduces a new feature called isolated declarations. By running the compiler in parallel and using isolated modules, significant performance gains can be achieved. Isolated declarations improve build speed, compatibility with other tools, and require developers to write types in code. This feature has the potential to further increase performance and may be available in TypeScript soon.
Full-stack & typesafe React (+Native) apps with tRPC.io
React Advanced 2021React Advanced 2021
6 min
Full-stack & typesafe React (+Native) apps with tRPC.io
Top Content
Alex introduces tRPC, a toolkit for making end-to-end type-safe APIs easily, with auto-completion of API endpoints and inferred data from backend to frontend. tRPC works the same way in React Native and can be adopted incrementally. The example showcases backend communication with a database using queries and validators, with types inferred to the frontend and data retrieval done using Prisma ORM.

Workshops on related topic

React, TypeScript, and TDD
React Advanced 2021React Advanced 2021
174 min
React, TypeScript, and TDD
Top Content
Featured WorkshopFree
Paul Everitt
Paul Everitt
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.
Mastering advanced concepts in TypeScript
React Summit US 2023React Summit US 2023
132 min
Mastering advanced concepts in TypeScript
Top Content
Featured WorkshopFree
Jiri Lojda
Jiri Lojda
TypeScript is not just types and interfaces. Join this workshop to master more advanced features of TypeScript that will make your code bullet-proof. We will cover conditional types and infer notation, template strings and how to map over union types and object/array properties. Each topic will be demonstrated on a sample application that was written with basic types or no types at all and we will together improve the code so you get more familiar with each feature and can bring this new knowledge directly into your projects.
You will learn:- - What are conditional types and infer notation- What are template strings- How to map over union types and object/array properties.
Deep TypeScript Tips & Tricks
Node Congress 2024Node Congress 2024
83 min
Deep TypeScript Tips & Tricks
Top Content
Featured Workshop
Josh Goldberg
Josh Goldberg
TypeScript has a powerful type system with all sorts of fancy features for representing wild and wacky JavaScript states. But the syntax to do so isn't always straightforward, and the error messages aren't always precise in telling you what's wrong. Let's dive into how many of TypeScript's more powerful features really work, what kinds of real-world problems they solve, and how to wrestle the type system into submission so you can write truly excellent TypeScript code.
Best Practices and Advanced TypeScript Tips for React Developers
React Advanced 2022React Advanced 2022
148 min
Best Practices and Advanced TypeScript Tips for React Developers
Top Content
Featured Workshop
Maurice de Beijer
Maurice de Beijer
Are you a React developer trying to get the most benefits from TypeScript? Then this is the workshop for you.In this interactive workshop, we will start at the basics and examine the pros and cons of different ways you can declare React components using TypeScript. After that we will move to more advanced concepts where we will go beyond the strict setting of TypeScript. You will learn when to use types like any, unknown and never. We will explore the use of type predicates, guards and exhaustive checking. You will learn about the built-in mapped types as well as how to create your own new type map utilities. And we will start programming in the TypeScript type system using conditional types and type inferring.
Building Your Own Custom Type System
React Summit 2024React Summit 2024
38 min
Building Your Own Custom Type System
Featured Workshop
Kunal Dubey
Kunal Dubey
I'll introduce the audience to a concept where they can have end-to-end type systems that helps ensure typesafety across the teams Such a system not only improves communication between teams but also helps teams collaborate effectively and ship way faster than they used to before. By having a custom type system, teams can also identify the errors and modify the API contracts on their IDE, which contributes to a better Developer Experience. The workshop would primarily leverage TS to showcase the concept and use tools like OpenAPI to generate the typesystem on the client side. 
Frictionless Development With Unified Type System
JSNation 2024JSNation 2024
113 min
Frictionless Development With Unified Type System
Featured Workshop
Ejiro Asiuwhu
Ejiro Asiuwhu
Imagine developing where frontend and backend sing in harmony, types dance in perfect sync, and errors become a distant memory. That's the magic of TypeScript Nirvana!
Join me on a journey to unveil the secrets of unified type definitions, the key to unlocking frictionless development. We'll dive into:
- Shared language, shared love: Define types once, share them everywhere. Consistency becomes your BFF, errors your worst nightmare (one you'll rarely see).- Effortless coding: Ditch the manual grind of type checking. TypeScript's got your back, freeing you to focus on building awesomeness.- Maintainability magic: With crystal-clear types guiding your code, maintaining it becomes a walk in the park. More time innovating, less time debugging.- Security fortress: TypeScript's type system shields your app from common vulnerabilities, making it a fortress against security threats.