Learn how to derive a union type from an object - an incredibly useful switcheroo that's at the heart of most TS magic out there.

Derive a union type from an object

 Hello, folks. For this TypeScript tip, I'm going to show you how to change this fruitCounts object here into a union type. Imagine our code is a little bit crap at the moment because, really, we want to be deriving this type, this union of objects, from this object. I'm going to show you how to do it.

 What we're going to do is we're going to name this NewSingleFruitCount, and I'm going to create a new type here, which is type NewSingleFruitCount. This is going to be an object. This is going to get a little bit funky here. First of all, I'm going to make a type out of this const up here, which is going to be type FruitCounts equals typeof fruitCounts.

 Inside here, I'm going to go K in keyof FruitCounts is going to be...Let's, first of all, make it an object. This is going to be interesting because now, what we're going to have is fruitCounts is expecting this shape, where apple is now an empty object. In fact, it's even asking for apple is apple, which is an empty object or something crazy.

 Essentially, what we have now is -- This is correct -- we're now looking for a shape like this. Inside, here we can specify anything and it will get put into here. We can say wow true, for instance, and now, all of these will require wow true. We don't want that. We actually want to take this key and we want to represent it as this apple number.

 We're going to say K2 in K is a number. Now, each of these now require apple as a number. This is going to be 12, for instance, whatever. This is still not quite what we wanted. Even though we have all of this stuff represented, we've got this nice dynamic key here, it's still not quite a union.

 To turn it into a union, all we need to do is map over these keys and essentially get rid of them. What we're going to do is just call these and say keyof FruitCounts. Maybe call isn't the right there. Now, what we have is we can have apple 2, and it satisfies it. There you go. This is how you turn a object type into a union.

Transform a union to another union, using the in operator as a kind of for-loop. This pattern can be used for almost any kind of transformation.

Transform a union to another union, using the 'in' operator as a kind of for-loop.

This pattern can be used for almost any kind of transformation - here, I add a dynamic key.

Use 'in' operator to transform a union to another union

 Folks, the challenge for today is to take this union type here, type user, type post, type comment, and dynamically add the ID type, which is going to be userID, postID, and commentID. As you can see, the EntityWithID is currently not really...we could be auto generating this and we're not. Let's try and improve on this. 

 We're going to say type EntityWithID = -- we're going to use the sort of same trick as we did last time -- which it's going to be [EntityType in Entity ["type"] ]. This is going to be an object where the type is the EntityType. Now, so far, what this will do is we'll get to this point where we have comments where the type is 'comment'. 

 We're doing pretty well there, but really what we needed to turn this into a union. To turn into a union, we basically go EntityType here. This means now that we now have our type: 'Comment' or type: 'User', but we haven't really added anything here. We just created the same type again. We haven't added the IDs. 

 The way that we do this is we say, "OK, we've got this object here, which is representing this." We say and we're going to make a record where it's going to be entity type. In fact, we're going to use a new string literal type where it's going to be entity type and then ID. That's going to be a string. 

 now commentID is going to appear 1, 2, 3. This little thing here, we're basically saying we have the type entity type and the record, which is another way of saying a string or rather an object with this is the key, with this as the value of that key. 

 If we remove this little end, then commentID no longer exists. If we remove this bit here, then we don't need to pass the type anymore. We just pass the commentID. There we go. That's how we handle it. We've used a little bit of a quite modern TypeScript here to handle this, but it's perfectly possible to do this, of course, if we didn't then go post, then we need to pass in a post ID. 

TypeScript's string interpolation powers are incredible, especially since 4.1. Add some utilities from ts-toolbelt, and you've got a stew going.

TypeScript's string interpolation powers are incredible, especially since 4.1. Add some utilities from 

Here, we decode some URL search params AT THE TYPE LEVEL.

Decode URL search params at the type level with ts-toolbelt

 Hello folks. Today I'm going to show you how cool TypeScript's string interpolation powers really are. We want to turn this query here, this kind of search params query into an object down here. Through this crazy web of TypeScripts, we managed to do it.

 Here we should see that if we go a=wonderful, then the type down here is no longer correct. It gives us auto complete to wonderful. Let's go through each step and see how we've managed to do this. First of all, we've taken the query and just for fun purposes, we've taken a type of it. We're going to type of query.

 Next up, the second query part we've basically split the query by here and we've taken the second part of it. If I remove the second part here, we've got string query part. We've split it by this point here. We've just said just grab the second bit of it.

 Now we've split it again by the & here. We've got now a=wonderful and B=now. We are doing this by grabbing some utilities from TS tool belt, which is a very cool library. Next up, we've got these query params, which somehow we've managed to turn into a union type. We've got now a=wonderful and b=now.

 What we do is we take query elements, which is a two pull here and we say, first of all, we want each query element. The query elements number here is a way of saying each one of these query elements. For each query element in that two pull, first of all we grab the key here.

 That key is going to be the a for instance, there, so a=wonderful because we're splitting the string by the by the equals there and grabbing the first part, and then we say is the value. The value is then the same code there is we're grabbing the second part.

 We then do this funny thing that we've seen in previous tips, where we then iterate over each member of that object. If we return this or grab it there, then you'd see it would be a=wonderful, b=now. Like this, for instance.

 Whereas instead we grab that and we do that instead, and that means that we then just get a=wonderful, b=now. Then we union merge them, which is just merges all the elements of the union into an object.

Function overloads can be used in conjunction with generics to make incredibly complex and dynamic type signatures.

Here, we make a compose function - incredibly useful for functional programming.

Use function overloads and generics to type a compose function

 Hello, folks. Function overloads in TypeScript are an incredibly powerful tool for building things that are not possible to build otherwise. Here, we have a compose function, which takes in multiple other functions and produces another function, which is a key tenet of functional programming.

 Here, if we just had an addOne function, we would have a number which returned another number. Then, if we wanted to take a num to a string, so we add one, and then turn it into a string, then finally, it goes number to string. Then if we want to turn it into a number again, we go stringToNum, and finally it's number to number.

 How do we achieve this? Well, we've used function overloads. We've got the actual implementation of the function here. You can see that it's stubbed. It's just got any inside, and TypeScript allows you to do this. Currently, we're returning this as any so I don't need to look at that too hard.

 Instead, look up here. We have the first signature of the first overload for compose, which takes in two generics. It has the Input, which is the very first thing you input into the returned function. Then you have the first argument.

 Here, we're saying FirstArg because, down here, we're going to add a SecondArg and a ThirdArg. What it returns is a function which essentially just returns the function that it's passed there. Now, that's only triggered if you use one argument here, so only if you do this, if you add one.

 If you add in a second function there, then the second overload is triggered. Now, you have an input, FirstArg, and a SecondArg. Here, you have func and func2. This returns the FirstArg. Then the FirstArg gets passed in to the second function there, which returns the SecondArg, which returns a function which takes in the input and returns the SecondArg.

 The third overload here means it just does the same thing again, but adds a third arg to it. What this does is it means that you can have things like where you add one, but imagine if you go numToString first, and then you try to add one to it. This means that there's an error here because the string is not compatible with a number signature.

 This means that function overloads are incredibly powerful for these sorts of compositions.


The 'extends' keyword is very powerful in TypeScript. Here, I use it to narrow the value of a generic to enable some beautiful autocomplete/inference.

 keyword is very powerful in TypeScript. Here, I use it to narrow the value of a generic to enable some beautiful autocomplete/inference.

Use 'extends' keyword to narrow the value of a generic

 You can use the extends keyword to narrow the scope of a generic to make it more useful. Here, for instance, we want to get a deep value from an object, and getDeepValue is going to take in the object and then take in the two keys that it's going to use to grab the value. 

 We can use extends here to say the FirstKey needs to be keyof Obj, which is our object. Now, we get some nice autocompletes on this deep value, which is either foo or bar. Let's say it's bar. This second key is now going to extends keyof Obj, FirstKey. That means that we get this bar. When we select bar, this is going to be C or D. When we select foo, this is going to be A or B. 

 Let's say it's A, for instance. We now need to work out what this result is going to be. It's currently typed as any. Here, we can say Obj, FirstKey, SecondKey, just like a property access is JavaScript. The result is a Boolean. If I change that to B, then it becomes a number.

Type helpers change the game when it comes to types in your codebase. They help TypeScript infer more from your code - and make your types a lot more readable. 

Type helpers change the game when it comes to types in your codebase. They help TypeScript infer more from your code - and make your types a lot more readable. Here, I write my own PropsFrom helper to extract props from any React component.

Write your own 'PropsFrom' helper to extract props from any React component

 A common pattern in TypeScript is to create type helpers that allow you to extract types from things that are not types. Here, we've created a PropsFrom type helper which extracts a component, if I call this TComponent here. Currently, what we wanted to do is we want it to return the props. Here, it would return enabled boolean if we put my components in there. Let's see how we do that.

 If we go TComponent extends React.FC, which is a functional component, then we can actually add a generic there. We can say infer the props and then we can return the props. Otherwise, because this is a ternary, it needs to return something, we say never.

 Now, PropsFrom, this is going to return enabled boolean because, if I change this up here to a, for instance, just say it's true and I had false here, then that's going to fail because it's expecting true. What if you want to be able to feed in two different types of things into this helper? Then you need to add an extra layer to the ternary.

 Let's imagine that we had a MyOtherComponents here, because React components can be added as classes, too. Here, what we do is we say instead of this, TComponent extends React.Component, then we return Props, and then we have never.

 Now, we can say PropsFrom is basically like...Why is this not working? Boolean is not returned, so never, so we can say Components instead. This now is working both with React functional components, which you see here, and with react components declared as classes.

The looseness of Object.keys can be a real pain point when using TypeScript. It's pretty simple to create a tighter version using generics and keyof operator.

 can be a real pain point when using TypeScript. Luckily, it's pretty simple to create a tighter version using generics and the 

Create your own 'objectKeys' function using generics and the 'keyof' operator 

 A common pain point when using TypeScript is when you have this object.keys function here. MyObject here has keys A, B, and C, but when I try to iterate over its keys when I've extracted them from object.keys, then the key is typed as a string. That means that when I try to access it, I get this horrible long type error, "No index signature with parameter of type 'string' was found in type A, B, C." 

 This should be typed as key of myObject. The way to get around this is to create your own object.keys function, so object.keys=. We're going to have Obj, which is our object. We're going to add that to the generics list here. Then we're going to return a keyof Obj, and that is going to be in an array like this. 

 Here, "A function whose declared type is neither 'void'...and must return a value." We just need to return Object.keys(obj) as...Yeah, we can do this instead. Now, if we go object.keys(myObject), then key is typed as A, B, or C.


You can use generics in React to make incredibly dynamic, flexible components. Here, I make a Table component with a generic 'items' type.

Use generics in React to make dynamic and flexible components

 You might be used to using generics with functions, but you can also use them with React components. Here, this Table component, it takes in an array of items, which have currently time to just ID String. Then it also takes a function to render the item, which says Item ID String.

 Actually, what you want here is you want to be able to parse in any items. For that ID String to then propagate through to the renderItem here. We can do that. You can make a item here, which would be, lets say, tItem. You might be put off by the fact that inside this TSX file, this syntax actually isn't valid.

 What you need to do instead is you need to turn this table into a function, which looks like this, and remove the arrow. Now, you're allowed to use it. Here, we probably need to make this generic as well, tItem. Let's add tItem up here.

 We can take the ID String and just put tItem in there. Anything we put into here, name, Matt, for instance, will be propagated through to our item because it's generic. If we ever want to pass the generic manually and specify it, then we can pass it here. We can say, "ID equals a number," for instance.

 This will array because it's not passing that. It's a funny syntax. Not a lot of people know about it. I stumbled on it by accident. Every time I use it, I think, "Wow, that's pretty cool."

Generics can be 'locked in' by function calls, meaning that generics can be 'curried' through functions.

Generics can be 'locked in' by function calls, meaning that generics can be 'curried' through functions. Here, we create a 'key remover' function which can process any generic object.

Create a 'key remover' function which can process any generic object

 Generics are really interesting in that they're tied to a function's execution context. What that means is that you can make a function, which has one generic locked inside of it, then make another function in the future out of that function with the first generic still locked and add another one.

 Here's what I mean by that. Here, we want to make a function called Make Key Remover. Now, Make Key Remover, what it's going to return is a function to remove keys from an object. Here, the expected case for this object is that it's going to be a new object with just the key of C. Here, we're making a function. Here, we're actually calling the function and using it.

 How do we get around to that? First of all, what we're going to do is we're going to say, "Key, extend string here." This is the first function, the key remover one. We're going to say, This key is a...or key array." This is an array of keys. You can see now that the key's generic has been locked in as A or B.

 What we want to do next is we want to take in the object, which is going to be...I'm going to give it a generic of obj. Obj is going to be here. I'll just save it to get the formatting. Obj, as you can see here, it's been locked in. The generic is locked in here into the key remover. That means that we need to just remove the keys from the object.

 We're going to return from this function. I think it's Omit, and then obj, and then key. If I just return this, I need to quieten down the error. What's going on here is that now we've got Omit, which removes keys from an object.

 We're removing A and B. You can see that the key remover locks in that first generic, which is just up here. Then this one, when we actually instantiate the second function, is, it locks in this generic. The new object, it only has C available to it. Pretty cool.

Using a crazy trick I picked up from @AndaristRake, you can throw detailed error messages for type checks.

, you can throw detailed error messages for type checks.

Here, I move a runtime check in a function to the type level, meaning you get a detailed error if you use it wrong.

Throw detailed error messages for type checks

 You can use TypeScript to throw some absolutely crazy errors at the type level, even without touching the runtime code at all. Here in our deepEqual compare function, we use this A triple equals B, which is really good for comparing primitives like 1 and 1, for instance, or a string to another string.

 It's really not very good at comparing two arrays. This will always return false, for instance, even if it's like this because this first array is not the same element as the other array. We can actually move this to the type level by saying, first of all, we're going to say, "Check for bad args."

 We're going to say, "This is going to be generic. The arg is going to be like this." We're going to say arg extends any array." We're going to say, "You cannot compare two arrays using deepEqual compare." We're just going to copy and paste that in.

 Otherwise, we're going to return the arg. We're going to use this in the function arguments here. We're going to say, "Check for bad args here and check for bad args there." Now, what you'll see is that here, argument of type never is not assignable to parameter of type.

 You cannot compare two arrays using deepEqual compare. We actually managed to move this to the type level.

Deep partials are SUPER useful and not natively supported by TypeScript. Here, I use one to help with mocking an entity in a (imaginary) test file.

Use deep partials to help with mocking an entity

 DeepPartials are incredibly useful for very, very narrow use cases. For instance, if you're in a test file, let's say, you're writing a unit test or something, and you want to make a seed for something, you have an entity that you want to mock, basically, let's say, it's a post here, you don't really want to have to go into, say, comments, value, this, for instance, and have to mock out all of everything every single time.

 Usually, what you want to do is just provide a little bit of it enough to make the test run, essentially. What you can do there is you can use a DeepPartial for this. Now, a DeepPartial, if you were to just wrap this in a partial, for instance, which is something that TypeScript gives you, then you would, for instance, have meta.

 Let's say you wouldn't need to provide meta. Let's say that you do provide meta, then you still have to provide description and a name because the partial is only one level deep. It doesn't go deeper. A DeepPartial, as we've got there, it actually goes and makes everything inside it partial, too. Even in comments here, we don't have to provide this value here.

 Again, this is very, very useful for very narrow use cases. Let's break down how this works. We have DeepPartial where we have a thing, essentially. And if that thing extends a function, then we just return the thing because there's nothing to make it partial there. If it extends an array, and we infer the inferred array member, then we use DeepPartial array, which, basically, just calls DeepPartial on the thing inside it.

 Otherwise, if it's an object, then for each key of the thing, then we, first of all, make sure it's not required there. That's crucial. Then we call DeepPartial on that thing again. You can see how it just gets recursively partialed down until everything is there.

Ever wanted just a bit of autocomplete? Here, we create a TypeScript helper called LooseAutocomplete which allows arbitrary values.

Ever wanted just a bit of autocomplete? Here, we create a TypeScript helper called LooseAutocomplete which gives us autocomplete while also allowing arbitrary values. 

Create autocomplete helper which allows for arbitrary values

 Sometimes, you run into an issue where you want some autocomplete, but not total autocomplete. For instance, here, we have a React component which takes in a prop which is a size. This size here can be either SM or XS.

 Imagine that we design an API where you can either pass in SM, XS, or can you pass in any arbitrary value. Here, what you might think is the right thing to do is go "or string" here. This is a union type, so it has SM or XS or string. This seems to make sense, except that you lose all the autocomplete on the size prop, which isn't really what you want.

 The reason this happens is that TypeScript is quite clever with union types. It tries to pull in all of the types that it can. For instance, if you specify the same type twice, like XS, then it won't show up twice in the autocomplete. You'll just have SM and XS.

 The reason that this is happening with the string is it's saying, "OK, SM is a string, and XS is also a string. What we need to do is remove these two, and then only offer string," which is why you don't get any autocomplete. The way we can get around this is we can actually use the omit utility type.

 We can omit XS or SM from the union. Now, TypeScript won't collapse these three things, and you'll have the autocomplete here. You'll have SM, XS, and you'll be able to pass any other arbitrary value. We can even turn this into a type helper, if we want to.

 We can say type loose autocomplete with a T, and we're going to say extend string, just because we're dealing with strings here, and we're going to say T, or we can have omit string T. This is a way of just taking this information up here and turning it into type helper.

 Now, we can just wrap this with loose autocomplete, and it's going to work for us. Again, XS, SM, and any arbitrary value.

Want to turn a module into a type? You can use typeof import('./') to grab the type of any module, even third-party ones. 

Want to turn a module into a type? You can use 

 to grab the type of any module, even third-party ones. 

 file, then map over the values to create a union.

Turn a module into a type

 Hello, folks. Let's imagine that we've got a union type that looks like this, where we have add to-do, remove to-do, and edit to-do as part of the union. This is a common pattern in old Redux applications. Now, this action type here, we've actually got a constants.ts file right next to it which has all of the elements of the union.

 They're even inferred by TypeScript, because we have add to-do is actually not inferred as a string, it's inferred as the literal add to-do, same as remove to-do, edit to-do. There must be a way that we can extract this information and create the union type dynamically.

 Otherwise, whenever we add a new element here, we've also got to add it to the new place. It's just not very dry. If we go to types, what we can do is we can say export type, action module, and we're going to use this funky little bit of TypeScript syntax, which is type of import constants.

 You can use any kind of normal import that you would here. It just grabs the information from constants and creates a new type out of it. We can say export constant action module is action module, like this, and you can see that it has all of the elements in there.

 If we removed one of the exports from constants, for instance, like if we just take this off, then it won't be a part of this types anymore, which is quite clever. Now, what we want to do, then, is we want to take this action module, and we want to turn it into the action below, if I just re-add this export.

 The way that we can do that is we can use a trick that we've done before, which is the take the values of an object and turn them into a union, which we just do like this. We say action module, and then key of action module. What that does is it takes the keys of the action module, the exported keys, and it iterates over them, so we end up with add to-do, remove to-do, edit to-do, that will stay in sync with our actual code.

Globals in TypeScript?! 🤯 'declare global' is a super useful tool for when you want to allow types to cross module boundaries.

 is a super useful tool for when you want to allow types to cross module boundaries. Here, we create a 

 type, where you can add new event types as you create new reducers.

Use 'declare global' to allow types to cross module boundaries

 Let's talk about globals in TypeScript, because globals in TypeScript can be manipulated and used in really interesting ways. Here, we have a global reducer, and this global reducer, it's got its state here, or its representation of state.

 In fact, this is supposed to be an array of to-dos, because it's to-dos, ID, string, array. Here, we take in a state, we have an event, and then we return the state, which is a typical pattern for a reducer, except our event is typed as never, so let's fix that.

 We can say declare global, which is a way of accessing TypeScript's global scope, and we're going to say interface global reducer event. We're going to pass in some events here. Let's say we have an add to-do event, where we can pass in an ID of string, for instance, to-do, for instance, or text string. That maybe makes more sense.

 Now, our event here has add to-do in it, and we can actually access it saying event.type equals add to-do. We've also got another reducer called the user reducer, which is another global reducer. This also receives now add to-do. If we wanted to do the same here, then we would just copy and paste this over, and we would add some more events to the global scope.

 Now, for instance, if we have a used Lexa or something like that -- so in here, we might have a login function -- and now, we have a login event, which all reducers can receive. That's usually how works in something like Redux. Now, the way that this works is we have a types file in here.

 In here, we just declare an empty interface, global reducer event here. Here, there's a bit of a clever mapping type, which maps over all of the login stuff here, and then turns it not a union type. Here, we're just saying key of global reducer event, so here are the keys.

 We grab the type in there, and then we grab anything the user puts in here, and we append it to or intersect it with the event as well. This means that you can use globals in really cool ways across your application.

You can use generics to dynamically specify the number, and type, of arguments to functions. 

 function which only asks for a payload if it's present on the event you're sending.

Use generics to dynamically specify the number, and type, of arguments to functions

 You can run into a problem with TypeScript when you start trying to deal with optional arguments that you want to be optional in some cases and not optional in others. Here, we've got a sendEvent function which takes in the event type, which is this event type up here, and an optional payload.

 This payload is not really optional, because we need to pass it when we pass login, but not pass it when we pass sign out, as you can see here. These ones should error, because we shouldn't even be able to pass an empty payload here. We should not be able to pass an incorrect payload.

 How do we handle this? How do we make the function arguments different case-by-case? Well, I'm going to do a little bit of, here's one I created earlier. This sendEvent now takes in a generic, which is the event type. Here, we do some crazy stuff based on that type.

 We extract out the event, and we extract out the event and the ones matching this. Essentially, this, we check if there's a payload there, and we infer the payload. If there is a payload on the event type that we've specified, we say these are the two arguments, type and T payload. Otherwise, it's just type.

 This means that, when we go to send an event -- whoops, sendEvent -- then we've got log in or sign out. Based on the one we choose -- let's say log in -- then we need to specify the payload, and it's all autocompleted for us, but there's an issue here which is on the autocomplete, you actually have arg zero and argos one, which you don't want.

 You can actually use a named tuple here, and you could say type, type, payload, payload, and this is type, type. Now, what you'll see is it's properly registered as the name of the argument there. It's quite verbose, this syntax, but it's very, very useful in some specific cases.

The "noUncheckedIndexedAccess" is the most awesome config option you've never heard of.

The "noUncheckedIndexedAccess" is the most awesome config option you've never heard of. It makes accessing objects a lot safer, and also powers up TypeScript's inference on objects.

Make accessing objects safer by enabling 'noUncheckedIndexedAccess' in tsconfig

 There are a couple of things about the TypeScript default config that let you do some quite unsafe things. Specifically, this one, which is where you have, let's say, an object, and your object has a key which is a string, and then every element of the object is an array of strings. 

 Let's imagine that you want to push something to this. Let's say you want to go my_object.foo.push(bar). Now, if my_object doesn't have a key of foo on it, and you try to push to it, this will result in a runtime error, but we're not getting any of that inference here. It's not telling us that it might be an error.

 Well, there happens to be a TypeScript config option for this, which my man Andores told me about. Here, what you can do is you can go into here, and you can say no unchecked index access, which by default is . Let's set it to 1. 

 Now, let's go back into our file here, and it says that object is possible undefined. This is pretty cool. We can do this, I guess, but this won't actually have the result that we want, because it will say, "OK, my_object.foo, if it exists, then push to it." 

 Actually, what we want to do is, if it doesn't exist already, we want to create an empty array. Let's do that. If my_obj.foo, then my_obj.foo equals an empty array, and TypeScript stops erroring. TypeScript is smart enough to know now that my_object.foo has an array in there. 

 You don't need to do any extra generic stuff or any other crazy helper function. It just knows, and it's crazy that the inference is this smart.

Sometimes you may need want to type an object which has several different optional keys, but all with the same type. We can map over a union type to accomplish this instead of chaining 

I start with some code that looks like this

Let's start improving this. First I will make a 

 object, then I'm going to make a new type called 

What this is doing is its taking each key in 

 and setting its type to an empty object. So when I use it, TypeScript will be expecting a shape like this.

But, I want the properties to be numbers.

As you can see, if I just do that, I still haven't quite got a union type. I get this odd nested structure, and I will still have to have every possible fruit present.

 type to get rid of those parent keys, and fully create my union type.

Mapping over a union type can feel tricky to conceptualise. But actually, TypeScript does it all for you - using Distributive Conditional Types.

Map over a union type

 I've got a puzzle for you. I've got three letters at the top here that are all expressed as a union. This letter can be either one of A, B, or C. I want to create a type helper to remove one of the letters. How do I do that? You think of, when something is an object or something is an array, you can usually map over it. There's some kind of iterator you can use.

 What's the iterator when it comes to unions? How do I map over each member of the union? It turns out that TypeScript does this automatically, and this what's called distributivity in TypeScript. The way this works is we can actually treat these letters as though they were one thing, as though they were, for instance, just C, let's say.

 The way we're going to do that is we're just going to check T type. We're going to check if T type extends C, and if not, we're going to return never, because never means that it can never be C. We're trying to remove it from union. When you add never to a union, it just removes itself, basically.

 Then, if it doesn't extend C, we're going to return T type. Now, while without C, it's just A or B. Now, that's unexpected, because you would think that T type, C is part of these letters. You would think, "OK, T type does extend C, because C is included, so let's return never."

 No, actually, automatically maps over each member of the union when it's doing a conditional type check like this. This means that we can return different members of the union or manipulate them. We can actually just return D, for instance. Now, while without C is A, B, or D.

 This is pretty exciting, because it means that you can really tear into unions and do lots of really smart things with them.

It can be hard to know when to reach for generics. I'll show you when you need them.

It can be hard to know when to reach for generics. Ask yourself: 

Are there ZERO dynamic elements in your function? No generics needed. 

If you have dynamic elements, do you know all their shapes up front? You might just need a union type.

Know when to use generics

 It's sometimes hard to work out if you should use a generic or if you shouldn't. The first question I want you to ask yourself when you get to that point is are all of the elements known when I make the function? Here, in this get_display_name function, we take in an animal, and we return a display name based on the animal's name.

 What if, woo, we add a bit of dynamism here. This looks like it's dynamic now, because it can either take in an animal, or it can take in a human, but really, we still know all the elements and all of their types before we get into the function call.

 Here, what you probably do is, if name in item.name or if just item, in fact, then return display name, item.name, and you do the same thing for human, first name, last name, concatenate them together. When you start needing a generic is when you truly don't know what the type is going to be passed into the function, or you have things inside the function that rely on knowing that type.

 Let's imagine that we do need to add a generic here, so we're going to say T item. T item is going to extend either animal or human. In here, what we're going to do is we're going to reference this here, and we're going to see T item extends human.

 Then we're going to return a human name string. Other than that, we're going to return the animal name string. This is where things start getting complicated, because inside here, we now need to return the animal name, which is going to be item.name.

 What that means, then, is we get a different return type based on what we pass in. Here, we're passing in an animal, and so we get animal name. Here, we're passing in a human name, and so we get a human name. This is where it truly starts.

 You need to use a generic, basically, because inside the function, it has to decide what it returns. If we were to just return this as a union type, like either human name or animal name, then it wouldn't respond to what gets passed in. This is a way to really just hack TypeScript's inference and get that information so you can use it in your return types.

You can DRY up your generics code MASSIVELY (and improve perf) by assigning local variables to default generic slots.

Here, we move some complex 'Extract' logic to a generic slot, meaning it only gets calculated once.

Assign local variables to default generic slots to dry up your code and improve performance

 You can do some really clever things with default parameters of generics, and they can really help tidy up really complicated-looking generic signatures. Here, we've got an object where what we want to do is we want to extract the values of the keys that start with A from this object.

 This union, it's looking at the A, A2, A3, just here, and if I change this to foo, for example, it's extracting the values of those keys that start with A. It's a pretty messy type signature, because there's quite a bit of duplication here. Here, we're extracting the key of the objects, and we're saying we only want those keys that start with A in them. Then we return the part of the object that corresponds to that key.

 Here, we're also doing it a second time, because we need to then map over the object in order to pull those values out. We can do something about this and reduce the duplication by saving it to a local variable. You might think, "Where on Earth would I save it here?"

 Well, you can stick it inside the default parameters of a new private generic. If I call this extracted keys here, you can see that this is yelling at me, because it requires two type parameters. If I give it a default type parameter here, I can actually pass extract in there.

 Now, we've got our keys all extracted already. What we can do is we can now get rid of these, and we can name them extracted keys instead. Now, there's an error going on here, because extracted keys, it says, it's not assignable to type string, number, or blah, blah, blah.

 That's because it takes the value from the type of this generic here. If we add to it, and we say it extends a key of obj, then it starts working, because we say, "OK, this extracted keys extends the key of the object." Sorry, my cats are fighting.

 Then we can just start using it here. This is now much easier to read, and our union still says the same.

You can do some really, really neat stuff with assertion functions inside classes.

Here, we assert that the user is logged in and get proper inference on the user's logged in user id.

Use assertion functions inside classes

 Assertion functions are pretty useful when they're applied to classes, and there's some cool stuff you can do. Here, we've got an SDK, which is like, if you imagine, the back end centerpoint, where you invoke this, and you've got your methods and stuff.

 Here, we've got a logged-in user ID, and this can either be string, or it can be undefined. When it's undefined, it means the user isn't logged in, and so there might be still anonymous things they can do. Inside createPost, we want to assert that the user is logged in.

 There, we're going to use the user ID. The issue here is that we've got string or undefined in this position, which is not good, because actually, we need string. Really, we've asserted that the logged-in user ID exists, so we should just be able to get this going, but we haven't told TypeScript that this is defined.

 If we were move this stuff inside here, then it would work, but how do we get this inference working? Well, we can return assert this is this, and -- so we're saying this is an assertion function now, and we're saying that this is this and something else, and -- we're going to add logged-in user ID, string.

 What this does is it basically just adds an intersection into the class and matches them both together, and this one wins. We get the string inside the SDK, and now this is typed a string. We could probably do even something more in here. We could say wow, which is a pretty Boolean, and I'm pretty sure we'll be able to go this.wow, which is a Boolean.

 Assertion functions are pretty useful. You do need to make sure that you check everything there, like this wow Boolean is technically unsafe, but it does give you a lot of flexibility, and it means you can use it a lot more way of a reusable way.

If you're thinking about putting a TypeScript package up to NPM, you should be considering preconstruct.

If you're thinking about putting a TypeScript package up to NPM, you should be considering preconstruct. It makes setup EXTREMELY easy and takes many decisions out of your hands. 

Here, we get a package ready for release in under 2 minutes.

Get a TypeScript package ready for release to NPM in under 2 minutes

 If you are thinking of deploying a time script package to NPM, you should be considering preconstruct. It's incredibly easy to set up and it handles so many things for you. Let's get started. We have a simple index source file here, which just is inside SRC, we've got our package here, and we've got a basic name, map preconstruct example. [0:20] [0: 20] This is not set up at all for deploying to NPM and you see how quick it can go. We can go yarn add, as a devDependency, @preconstruct/cli. This is going to install a CLI, which handles all of our building, handles a lot of our other stuff too. 

 Now we can run yarn preconstruct fix. Preconstruct is there because we've installed the CLI. You'll notice here that it's added dist/matt-preconstruct-example.cjs.js into our main. We don't even need to think about our main.

 If we want to add bundling for ESM, we just add "module" true, run yarn preconstruct fix again, and it'll go in and add the ESM version. Now we can run yarn preconstruct build. I'm just going to, while this is running, just going to add this into a script, into my MPM as well. We've got build yarn preconstruct build.

 Now we've got a dist file with all of the correct stuff in there. I'm just going to gitignore it, actually. We've got cjs.d.ts. We've got all of our declaration files properly exported. We've got everything working for ESM as well if we want it. It just gives you everything out of the box. 

TypeScript Tips