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 `|` in an object type.

I start with some code that looks like this



```typescript
type SingleFruitCount =
  | {     
        apple: number;
    }
  | {
      banana: number;
  }
  | {
      pear: number;
```

```typescript
export const fruitCount = {
  apple: 1,
  pear: 4,
  banana: 26,
}

type SingleFruitCount =
  | {
      apple: number
    }
  | {
      banana: number
    }
  | {
      pear: number
    }

const singleFruitCount: SingleFruitCount = {
  banana: 12,
}
```

Let's start improving this. First I will make a `FruitCount` type out of my `fruitCounts` object, then I'm going to make a new type called `NewSingleFruitCount`.

```typescript
type FruitCounts = typeof fruitCounts

type NewSingleFruitCount = {
  [K in keyof FruitCounts]: {}
}
```

What this is doing is its taking each key in `FruitCounts` and setting its type to an empty object. So when I use it, TypeScript will be expecting a shape like this.

```typescript
const singleFruitCount: NewSingleFruitCount = {
  apple: {},
  pear: {},
  banana: {},
}
```

But, I want the properties to be numbers.

```typescript
type NewSingleFruitCount = {
  [K in keyof FruitCounts]: {
    [K2 in K]: number
  }
}
```

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.

```typescript
const singleFruitCount: NewSingleFruitCount = {
  apple: {
    apple: 2,
  },
  pear: {
    pear: 4,
  },
  banana: {
    banana: 26,
  },
}
```

So, what I'm going to do is map over our `NewSingleFruitCount` type to get rid of those parent keys, and fully create my union type.

```typescript
type NewSingleFruitCount = {
  [K in keyof FruitCounts]: {
    [K2 in K]: number
  }
}[keyof FruitCounts]
```

And with that, I can now assign our `singleFruitCount` how I'd like.

```typescript
const singleFruitCount: NewSingleFruitCount = {
  apple: 2,
}
```

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

0:00 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.

0:20 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.

0:44 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.

1:04 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.

1:29 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.

1:50 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.

The challenge for today is to take this union type here type `user` type `post` type `comment`.

```typescript
export type Entity =
  | {
      type: "user"
    }
  | {
      type: "post"
    }
  | {
      type: "comment"
    }
```

And then dynamically add `id` to the type which is going to be `userId` `postId` and `commentId`. As you can see bellow, we are manually defining the types of those id properties.

```typescript
type EntityWithId =
  | {
      type: "user"
      userId: string
    }
  | {
      type: "post"
      postId: string
    }
  | {
      type: "comment"
      commentId: string
    }
```

We can automate this with TypeScript

First we'll use the `[Key in Type]` syntax to iterate over our `Entity` type and set the `type` property to the key which we've named `EntityType`.

```typescript
type EntityWithId = {
  [EntityType in Entity["type"]]: {
    type: EntityType
  }
}
```

We'll want to turn this object into a union type. We do this by applying an index operation to the object. In this case we'll use `[Entity["type"]]` to get the value of the `type` property.

```typescript
type EntityWithId = {
  [EntityType in Entity["type"]]: {
    type: EntityType
  }
}[Entity["type"]]
```

and this means. now that we now have our type comment or type user

```typescript
const result = (EntityWithId = {
  type: "comment",
})
```

But we haven't really added anything here. We just sort of created the same type again.

What we need to do is say that we want `type` property AND our id property. We can create the dynamic id property using `Record` utility type. This is used to define a key and the type of its value. We'll make the key dynamic by using string interpolation.

```typescript
type EntityWithId = {
  [EntityType in Entity["type"]]: {
    type: EntityType
  } & Record<`${EntityType}Id`, string>
}[Entity["type"]]
```

So now in our `result` object we can set `commentId` to a string.

```typescript
const result: EntityWithId = {
  type: "comment",
  commentId: "123",
}
```

so in `EntityWithId` where we set the `type` and use `& Record...`, we're saying we have have the type of `EntityType` AND the `Record` which is another way of saying we have an object with a key of ``${EntityType}Id`` and a value of `string`

We can then create objects for `user` and `post`.

```typescript
const userResult: EntityWithId = {
  type: "user",
  userId: "123",
}

const postResult: EntityWithId = {
  type: "post",
  postId: "123",
}
```

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

0:00 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. 

0:18 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'. 

0:47 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. 

1:05 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. 

1:24 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. 

1:44 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. 

2:05 Thanks so much for your time.

TypeScript has really cool string interpolation powers. We want to take this following query:

```typescript
const query = `/home?a=foo&b=wow` 
```

And turn it into an object like this:

```typescript
const obj: Union.Merge<QueryParams> = {
  a: "foo",
  b: "wow",
}
```

This features autocomplete and if we change one of the query parameters, TypeScript will let us know that it's incorrect and give us autocomplete.

To accomplish this we start with creating a `Query` type and then splitting the query up on the `?` character in order to get the query parameters. Make sure to grab the second element of the array because the first element is just the path.

```typescript
type Query = typeof query

type SecondQueryPart = String.Split<Query, "?">[1]
```

Once we have the query split up, we'll split it again on each `&` character to get each individual query parameter.

```typescript
type QueryElements = String.Split<SecondQueryPart, "&"> 
```

We are using the `ts-toolbelt` library to help us with the string manipulation.

Now we want to build our `QueryParams` type now that we have them all split up. First of all, we want each `QueryElement`. So we'll create a mapped type with `[QueryElement in QueryElements[numbedr]]`.

```typescript
type QueryParams = {
  [QueryElement in QueryElements[number]]: {}
}
```

Then we can create key value pairs of each parameter by mapping again over the split `QueryElement` and setting the key to the first element of the split and the value to the second element of the split.

```typescript
type QueryParams = {
  [QueryElement in QueryElements[number]]: {
    [Key in String.Split<QueryElement, "=">[0]]: String.Split<
      QueryElement,
      "="
    >[1]
  }
}
```

And we then do this funny thing. that we've seen in previous tips. We iterate over each each member of the object, since we don't want the type to be the nested structure, just the key value pairs of the query params.

```typescript
type QueryParams = {
  [QueryElement in QueryElements[number]]: {
    [Key in String.Split<QueryElement, "=">[0]]: String.Split<
      QueryElement,
      "="
    >[1]
  }
}[QueryElements[number]]
```

And finally we `Union.Merge` the `QueryParams` to merge them all into an object.

```typescript
const obj: Union.Merge<QueryParams> = {
  a: "wonderful",
  b: "wow",
}
```

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 `ts-toolbelt`, and you've got a stew going.

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

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

0:00 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.

0:18 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.

0:37 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.

0:55 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.

1:16 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.

1:34 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.

1:51 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.

2:05 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 in TypeScript are an incredibly powerful tool for building. things that really are not possible to build otherwise. Here we have a `compose` function. which takes in multiple other functions and produces another function.

This is a key tenet of functional programming.

```typescript
function compose(...args, any[]) {
  return {} as any;
};
```

So here if we just had an `addOne` function we would just have a number which returned another number.

```typescript
function addOneToString = compose(addOne);
```

But what if we wanted to chain several functions together? With the result of each previous function piping into the next.

```typescript
const addOneToString = compose(addOne, numToString, stringToNum) 
```

How would we achieve this? We use function overloads.

We've got the actual implementation of the function here and you can see that it's kind of stubbed. It's just got an `any` inside it, which TypeScript allows you to do.

```typescript
function compose(...args, any[]) {
  return {} as any;
};
```

What's actually interesting are the overloads. So we have a function that takes in a function and returns a function.

```typescript
export function compose<Input, FirstArg>(
  func: (input: Input) => FirstArg
): (input: Input) => FirstArg
```

We have the first signature or 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 and then you have the first argument.

So here we're saying `FirstArg`, because further down we're going to add a `SecondArg` and a `ThirdArg`.

This is only triggered if you use one argument.

```typescript
function addOneToString = compose(addOne); 
```

If you add in a second function there then the second overload is triggered. So now you have an `<Input, FirstArg, SecondArg>`. And here your arguments `func` and `func2`. `func` returns the `FirstArg`, and that is the input for `func2`, which returns the `SecondArg`.

```typescript
export function compose<Input, FirstArg, SecondArg>(
  func: (input: Input) => FirstArg,
  func2: (input: FirstArg) => SecondArg
): (input: Input) => SecondArg
```

And the third overload here it means it just does the same thing again but adds a third arg to it.

```typescript
export function compose<Input, FirstArg, SecondArg, ThirdArg>(
  func: (input: Input) => FirstArg,
  func2: (input: FirstArg) => SecondArg,
  func3: (input: SecondArg) => ThirdArg
): (input: Input) => ThirdArg
```

What this does is protect you from cases where the output from one of the previous functions doesn't match the input of the next function.

So for example you can't run `numToString` and then `addOne` because `numToString` returns a string and `addOne` takes in a number.

```typescript
const addOneToString = compose(numToString, addOne) 
```

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

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

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

0:00 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.

0:20 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.

0:40 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.

0:56 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.

1:10 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.

1:28 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.

1:48 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.

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

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

```typescript
const result = getDeepValue(obj, "bar", "d")
```

`getDeepValue` is gonna take in the object and then take in the two keys that it's gonna use to then grab the value. So we can use `extends` here to say the `FirstKey` needs to be `keyof Obj`, which is our object.

```typescript
export const getDeepValue = <Obj, FirstKey extends keyof Obj, SecondKey>(
  obj: Obj,
  firstKey: FirstKey,
  secondKey: SecondKey
) => {
  return {} as any
}
```

And now we get some nice auto-complete on this deep value. Which is either `foo` or `bar`. Let's say it's `bar` for now.

```typescript
const result = getDeepValue(obj, "bar", "d") 
```

Now this second key is now going to `extends keyof Obj[FirstKey]`.

```typescript
export const getDeepValue = <
  Obj,
  FirstKey extends keyof Obj,
  SecondKey extends keyof Obj[FirstKey]
>(
  obj: Obj,
  firstKey: FirstKey,
  secondKey: SecondKey
) => {
  return {} as any
}
```

And that means that when we select bar, this third argument is going to be c or d.

```typescript
const result = getDeepValue(obj, "bar", "d") 
```

And when we select foo, it will be either a or b.

```typescript
const result = getDeepValue(obj, "foo", "a") 
```

So let's say it's a for instance. We now need to work out what the `result` is going to be, because it's currently typed as `any`. So here in the return type definition we can just say `Obj[FirstKey][SecondKey]` just like property access in JavaScript.

```typescript
export const getDeepValue = <
  Obj,
  FirstKey extends keyof Obj,
  SecondKey extends keyof Obj[FirstKey]
>(
  obj: Obj,
  firstKey: FirstKey,
  secondKey: SecondKey
): Obj[FirstKey][SecondKey] => {
  return {} as any
}
```

Now the `result` is a Boolean. And if I change the third argument to b, then it becomes a number.

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.

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.

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

0:00 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.

0:15 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.

0:47 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.

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.

```typescript
type PropsFrom<TComponent> = any

const props: PropsFrom<typeof MyComponent> = {
  enabled: true,
}
```

Currently what we want it to do is to return the props. Here it would return `enabled: boolean` if we put `MyComponent` in there.

```typescript
const MyComponent = (props: { enabled: boolean }) => {
  return null
}
```

So let's see how we do that. If we go `TComponent` `extends` a `React.FC` which is a functional component, then we can actually add a generic there and we can say `infer` the `Props`.

Then we can return the `Props` and otherwise, because this is a ternary and it needs to return something, we say `never`.

```typescript
type PropsFrom<TComponent> = TComponent extends React.FC<infer Props>
  ? Props
  : never
```

And now if we `PropsFrom` `MyComponent` we get `enabled: boolean`.

So for instance if I go and change the `enabled` prop in `MyComponent` to `true` and then set `enabled` in our `props` object to be false, then that's. going to fail because it's expecting `true`.

But what if you want to feed multiple types of things into this helper? For instance what if we also wanted to derive the prop types of a class component instead of a functional component.

```typescript
class MyOtherComponent extends React.Component<{
  enabled: boolean;
}> {}

...

const props: PropsFrom<MyOtherComponent> = {
  enabled: true,
};
```

To do this we'll need to add another layer to the `PropsFrom` ternary.

So here in the ternary, for the else case we'll check if the `TComponent` is a `React.Component` which is the type of a class component. From that we'll infer its `Props`.

```typescript
type PropsFrom<TComponent> = TComponent extends React.FC<infer Props>
  ? Props
  : TComponent extends React.Component<infer Props>
  ? Props
  : never
```

So this now is working both with react functional components and class components.

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

0:00 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.

0:26 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.

0:46 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.

1:07 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.

1:25 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.

A common pain point when using TypeScript is when you have this `Object.keys` function here. My object here has keys a b and c but when I try to iterate over its keys when I've extracted them from `Object.keys`, 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.

```typescript
export const myObject = {
  a: 1,
  b: 2,
  c: 3,
}

Object.keys(myObject).forEach((key) => {
  console.log(myObject[key])
})
```

So this really should be typed as `keyof myObject` and the way to get around this is to create your own `Object.keys` function.

So we'll create our function `objectKeys` which has a generic `Obj`. We'll set that as the type for our argument `obj` and then set the return type to be an array of `keyof Obj`.

```typescript
const objectKeys = <Obj>(obj: Obj): (keyof Obj)[] => {} 
```

Then we'll return `Object.keys(obj) as (keyof Obj)[]`. We are using the `as` to make a type assertion. This tells the compiler to infer the result of `Object.keys(obj)` to be an array of the objects keys as strings.

```typescript
const objectKeys = <Obj>(obj: Obj): (keyof Obj)[] => {
  return Object.keys(obj) as (keyof Obj)[]
}
```

So now if we go `objectKeys(myObject)` then key is typed as a b or c.

```typescript
objectKeys(myObject).forEach((key) => {
  console.log(myObject[key])
})
```

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.

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

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

0:00 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." 

0:23 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. 

0:47 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 might be used to using generics with functions but you can also use them with react components.

So here this `Table` component takes in an array of items which I've currently typed as just `id: string` and then it also takes a function to render the item which says `item: {id: string}`

```typescript
interface TableProps {
  items: { id: string }[]
  renderItem: (item: { id: string }) => React.ReactNode
}

export const Table = (props: TableProps) => {
  return null
}
```

What you want here is to be able to pass in any items and for that `id` string to then propagate through to the `renderItem`. You might try the following, using `TItem`, but this actually isn't valid.

```typescript
export const Table = <TItem>(props: TableProps) => {
  return null
}
```

What you need to do instead is you need to turn this `Table` into a standard `function`.

```typescript
export function Table<TItem>(props: TableProps) {
  return null
}
```

We need to make `TableProps` generic as well with `TItem`. Remember to use `TItem` in the `items` array and the `renderItem` function.

```typescript
interface TableProps<TItem> {
  items: TItem[]
  renderItem: (item: TItem) => React.ReactNode
}

export function Table<TItem>(props: TableProps<TItem>) {
  return null
}
```

And now anything we put in the `Component` props `items` will be propagated through to our `item` because it's generic.

If we ever want to pass the generic manually we specificy it with our `Table` instance. Now the example below will error out since `id` should be a number not a string.

```typescript
const Component = () => {
  return (
    <Table<{ id: number }>
      items={[{ id: "1", name: "Matt" }]}
      renderItem={(item) => <div>{item.id}</div>}
    ></Table>
  )
}
```

So it's a funny syntax and not a lot of people know about it. I kind of stumbled on it by accident and every time. But, every time I use it I think, "wow that's pretty cool!"

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

0:00 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.

0:16 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.

0:36 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.

0:51 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.

1:10 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 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 then add another one.

Here's what I mean by that. We want to make a function called `makeKeyRemover`. Now, `makeKeyRemover`, is going to return a function that removes keys from an object. 

```typescript
export const makeKeyRemover = () => () => {};

const keyRemover = makeKeyRemover(["a", "b"]);

const newObject = keyRemover({a: 1, b: 2, c: 3});
```

The expected case for `newObject` is that it's going to be an object with just the key of c. In `keyRemover`, we're making a function. In `newObject`, we're actually calling the function and using it.

To make this work, first of all, what we're going to do is say, `<Key extends string>` in `makeKeyRemover`. 

```typescript
export const makeKeyRemover = <Key extends string>() => () => {};
```

And then we're going to say that the argument `keys` is an array of keys. The key's generic has been locked in as a or b.

```typescript
export const makeKeyRemover = <Key extends string>(keys: Key[]) => () => {};
```

What we want to do next is take in the object, which is going to be the generic `Obj`. Then, I'll set the argument `obj` to `Obj`.

```typescript
export const makeKeyRemover = 
  <Key extends string>(keys: Key[]) => 
  <Obj>(obj: Obj) => {};
```

The generic is now locked in the `keyRemover`. That means that we need to just remove the keys from the object.

To do that we'll set the return type of this function to be `Omit<Obj, Key>`. Then we'll return that blank object and set the type to any to quite down an error. 

```typescript
export const makeKeyRemover = 
  <Key extends string>(keys: Key[]) => 
  <Obj>(obj: Obj): Omit<Obj, Key> => {
    return {} as any;
  };
```

What's going on here is that now we've got Omit, which removes keys from an object.

We're removing a and b, the `keyRemover` locks in that first generic, `Key`. Then `newObject`, when we instantiate the second function, locks in the generic, `Obj`. Now, `newObject` only has c available to it. 

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

0:00 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.

0:16 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.

0:38 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.

1:01 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.

1:23 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.

1:41 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.

You can use TimeScript to throw some absolutely crazy errors at the type level even without touching the runtime code at all.

Here in our `deepEqualCompare` function we use `a === b` which is really good for comparing primitives like two numbers or a string to another string but it's really not very good at comparing two arrays.

```typescript
export const deepEqualCompare = <Arg>(a: Arg, b: Arg): boolean => {
  if (Array.isArray(a) && Array.isArray(b)) {
    throw new Error("You cannot compare two arrays using deepEqualCompare")
  }
}

deepEqualCompare(1, 1)
deepEqualCompare([], ["a"])
```

The array comparison will always return false, because this first array is not the same element as the other array. We can actually move this to the type level.

first of all we're going to say check for bad args and we're going to say this is going to be. a generic and the arg is going to be like this. We're going to say arg extends any array and we're going to say you cannot compare two arrays using `deepEqualCompare`. We're just going to copy and. paste that in otherwise we're going to return the arg

```typescript
type CheckForBadArgs<Arg> = Arg extends any[]
  ? "You cannot compare two arrays using deepEqualCompare"
  : Arg
```

and we're going to use this in the function arguments of `deepEqualCompare`. Adding `CheckForBadArgs` to both `a` and `b`.

```typescript
export const deepEqualCompare = <Arg>(
  a: CheckForBadArgs<Arg>,
  b: CheckForBadArgs<Arg>
): boolean => {
  if (Array.isArray(a) && Array.isArray(b)) {
    throw new Error("You cannot compare two arrays using deepEqualCompare")
  }
}
```

And now what you'll see when we `deepEqualCompare` two arrays is an error saying, `"Argument of type 'never[]' is not assignable to parameter of type ''You cannot compare two arrays using deepEqualCompare'"`.

So we've actually successfully moved this error to the type level!

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

Using a crazy trick I picked up from <a href="https://twitter.com/AndaristRake" target="_blank" rel="noopener">@AndaristRake</a>, 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

0:00 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.

0:19 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."

0:39 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.

0:53 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.

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

Deep partials are incredibly useful. For very, very narrow use cases. For instance, if you're in a test file, writing a unit test or something, and you have an entity that you want to mock. Let's say it's a `Post`.

```typescript
interface Post {
  id: string
  comments: { value: string }[]
  meta: {
    name: string
    description: string
  }
}
```

You don't really want to have to go in and manually fill out every field, including the comments array, every single time. Usually what you want to do is just provide _just_ enough data to make the test run.

So what you can do there is you can use a **deep partial** for this.

Now, TypeScript does give you a `Partial`. But, if you were to wrap `Post` in just a `Partial`, you would still have to manually fill out all of the nested data since `Partial` only works one layer deep.

```typescript
const post: Partial<Post> = {
  id: "1",
  meta: {
    description: "123",
    name: "123",
  },
}
```

So a deep partial actually goes and makes every layer inside a `Partial`. So we don't have to provide a value to `comments` or `meta` for example.

```typescript
const post: Partial<Post> = {
  id: "1",
  comments: [{}],
  meta: {},
}
```

Again, this is _very_ useful for very narrow use cases. Let's break down how it works. We have a `DeepPartial` that has a `Thing`. If `Thing` returns a function then we just return the `Thing`, because there's nothing to make partial there.

If our `Thing` extends an array and we infer the `InferredArrayMember`, then we use `DeepPartialArray`, which basically just calls `DeepPartial` on the thing inside it.

Otherwise, if `Thing` is an object, we use `DeepPartialObject`, which goes through each unrequired key in `Thing` and makes a `DeepPartial` of the value.

```typescript
type DeepPartial<Thing> = Thing extends Function
  ? Thing
  : Thing extends Array<infer InferredArrayMember>
  ? DeepPartialArray<InferredArrayMember>
  : Thing extends object
  ? DeepPartialObject<Thing>
  : Thing | undefined

interface DeepPartialArray<Thing> extends Array<DeepPartial<Thing>> {}

type DeepPartialObject<Thing> = {
  [Key in keyof Thing]?: DeepPartial<Thing[Key]>
}
```

So you can see how it just recursively goes down and creates partials.

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

0:01 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.

0:28 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.

0:46 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.

1:10 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.

1:35 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.

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`. And this size `here` can be either `sm` or `xs`.

```tsx
export const Icon = (props: IconProps) => {
  return <></>
}

const Comp1 = () => {
  return (
    <>
      <Icon size="xs"></Icon>
      <Icon size="something"></Icon>
    </>
  )
}
```

But imagine that we design an API where you can either pass in `sm`, `xs`, or any arbitrary value. What you might think is the right thing to do is to add `string` to the `IconSize` union type.

```typescript
type IconSize = "sm" | "xs" | 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, and it tries to kind of 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.

```typescript
type IconSize = "sm" | "xs" | "xs" 
```

The reason this is happening with a string, is that TypeScript is reasoning since `xs` and `sm` are both strings, and you're also specifying `string`, that it means it should just removed `xs` and `sm` and only offer string. Preventing your from getting autocomplete.

The way we can get around this is we can actually use the `Omit` utility type, and we can omit `xs` or `sm` from the union. And now TypeScript won't collapse. these three things, and you'll have autocomplete again.

```typescript
type IconSize = "sm" | "xs" | Omit<string, "xs", "sm"> 
```

We can even turn this into a type helper if we want to.

```typescript
type LooseAutocomplete<T extends string> = T | Omit<string, T> 
```

This is a way of just taking this information up in our `IconSize` type and turning it into a type helper. And now we can just wrap `sm` and `xs` in this type helper.

```typescript
type IconSize = LooseAutocomplete<"sm" | "xs"> 
```

And it's gonna work for us. So again, `xs`, `sm`, and any arbitrary value.

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. 

Picked up this tip from <a href="https://twitter.com/GavinRayDev" target="_blank" rel="noopener">@GavinRayDev</a> - worth a follow!

Create autocomplete helper which allows for arbitrary values

0:00 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.

0:16 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.

0:41 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.

1:00 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.

1:19 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.

1:37 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.

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

Let's imagine that we've got a union type that looks like this.

```typescript
export type Action = "ADD_TODO" | "REMOVE_TODO" | "EDIT_TODO" 
```

This is a common pattern in older Redux applications. Now, we've actually got a constants.ts file which has all of the elements of the union. They're even inferred by TypeScript.

The exports are not actually inferred as strings. They're inferred as the literals "ADD_TODO", "REMOVE_TODO", and "EDIT_TODO".

```typescript
export const ADD_TODO = "ADD_TODO"
export const REMOVE_TODO = "REMOVE_TODO"
export const EDIT_TODO = "EDIT_TODO"
```

So there must be a way that we can extract this information and create the union type dynamically. Because otherwise, whenever we add a new element in `constants.ts`, we've also got to add it to the new place. It's just not very DRY.

So if we go to types, what we can do is we can say `export type ActionModule`. And we're going to use this funky little bits of TypeScript syntax.

```typescript
export type ActionModule = typeof import("./constants") 
```

You can use any kind of normal import that you would here, and it just grabs the information from constants and creates a new type out of it. So set something to the type of `ActionModule`, you would see that it has all of the elements in `constants.ts`.

in there. So if we remove one of the exports from `constants`, it won't be a part of these types anymore, which is quite clever.

Then we can use the trick we learned before to create a union type out of the keys of `ActionModule`. So we can say this:

```typescript
export type ActionModule = typeof import("./constants")

export type Action = ActionModule[keyof ActionModule]
```

What that does is it takes the exported keys of the `ActionModule`, and it sort of iterates over them. So we end up with `ADD_TODO`, `REMOVE_TODO`, and `EDIT_TODO` which stays in sync with our actual code.

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 `typeof import('./')` to grab the type of any module, even third-party ones. 

Here, we create a type from a `constants.ts` file, then map over the values to create a union.

Turn a module into a type

0:00 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.

0:23 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.

0:38 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.

0:57 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.

1:14 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.

1:33 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.

Let's talk about globals in TypeScript. Globals in TypeScript can be manipulated and used in really interesting ways.

Here we have a global reducer.

```typescript
export const todosReducer: GlobalReducer<{ todos: { id: string }[] }> = (
  state,
  event
) => {
  return state
}
```

And this global reducer has representation of state. We take in a state and have an event, and then we return the state, which is a typical pattern for a reducer.

Problem is, our event is typed as never. Let's fix that. We can access TypeScript's global scope using the `declare global` syntax. We'll use that then create a `GlobalReducerEvent` interface.

```typescript
declare global { interface GlobalReducerEvent {} } 
```

In it, we'll create some events

Let's say we have an add to-do event, where we can pass text with the `string` type.

```typescript
declare global {
  interface GlobalReducerEvent {
    ADD_TODO: { text: string }
  }
}
```

Now we can access that event in our global reducer.

```typescript
export const todosReducer: GlobalReducer<{ todos: { id: string }[] }> = (
  state,
  event
) => {
  // event.type = 'ADD_TODO'
  return state
}
```

So we've also got another reducer called the user reducer, which is another global reducer. This reducer also now receives the add to-do event type since we used `declare global`.

If we want to do the same thing here, then we would just copy and paste the `declare global` code over. and we would add some more events to the global scope.

For instance, we might have a log in function and need to support a log-in event, which all reducers can receive. That's usually how it works in something like Redux.

```typescript
declare global {
  interface GlobalReducerEvent {
    LOG_IN: { ... }
  }
}

export const userReducer: GlobalReducer<{ id: string }> = (
  state,
  event
) => {
  // event.type === 'LOG_IN'
  // event.type === 'ADD_TODO'
  return state
}
```

The way that this works is we have a types file. And in it, we declare an empty interface, `GlobalReducerEvent`. And then, there's a bit of a clever mapping type, which maps over all of the log in stuff, and then turns it into a union type.

```typescript
declare global {
  interface GlobalReducerEvent {
    LOG_IN: {}
  }
}

export type GlobalReducer<TState> = (
  state: TState,
  event: {
    [EventType in keyof GlobalReducerEvent]: {
      type: EventType
    } & GlobalReducerEvent[EventType]
  }[keyof GlobalReducerEvent]
) => TState
```

So here we're just saying `EventType in keyof GlobalReducerEvent`. And in that mapping, set the `type` to `EventType`. And then, we grab anything the user puts in their reducer events, and we append it to or intersect it with the event as well.

And this means that you can use globals. in really cool ways across your application.

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

Globals in TypeScript?! 🤯 

`declare global` is a super useful tool for when you want to allow types to cross module boundaries. Here, we create a `GlobalReducer` type, where you can add new event types as you create new reducers.

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

0:00 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.

0:15 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.

0:31 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.

0:53 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.

1:19 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.

1:38 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.

1:56 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 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, and an optional payload.

```typescript
export type Event =
  | {
      type: "LOG_IN"
      payload: {
        userId: string
      }
    }
  | {
      type: "SIGN_OUT"
    }

const sendEvent = (eventType: Event["type"], payload?: any) => {}
```

And this `payload` is not really optional because we need to pass it when we pass `LOG_IN`, but not pass it when we pass `SIGN_OUT`.

We also need a way to handle invalid payloads.

So how do we handle this?. How do we make the function arguments different case by case?

Check out this one I created earlier. This `sendEvent` now takes in a generic, which is the `Event` type. And here we do some crazy stuff based on that type.

```typescript
const sendEvent = <Type extends Event["type"]>(
  ...args: Extract<Event, { type: Type }> extends { payload: infer TPayload }
    ? [Type, TPayload]
    : [Type]
) => {}
```

We extract out the event and the ones matching `{ type: Type }`. So essentially we check if there's a payload there and we infer the payload.

And if there is a payload on the `Event` type that we've specified, we say these are the two arguments, `Type` and `TPayload`. Otherwise, it's just `Type`.

And this means that when we go to `sendEvent`, then we've got `LOG_IN` or `SIGN_OUT`. When we write another `sendEvent` we see that that we get that nice autocomplete for us.

```typescript
sendEvent("LOG_IN", {
  userId: "123",
})
```

But there's an issue here. On the auto-complete you actually have `arg0` and `arg1`, which you don't want. So you can actually use a named tuple here, and specify the names of the arguments.

```typescript
const sendEvent = <Type extends Event["type"]>(
  ...args: Extract<Event, { type: Type }> extends { payload: infer TPayload }
    ? [type: Type, payload: TPayload]
    : [type: Type]
) => {}
```

And what you'll see are the proper argument names registered. So it's kind of a verbose syntax, but it's very, very useful in some specific cases.

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

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

Here, we create a `sendEvent` 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

0:00 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.

0:16 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.

0:32 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.

0:49 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.

1:10 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.

1:31 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.

There are a couple of things about the TypeScript default config that let you do some quite unsafe things. In this case, we'll be checking out this one:

```typescript
export const myObj: Record<string, string[]> = {} 
```

This is where you have an object and your object has a key which is a string, and then every element of the object is an array of strings. And, let's imagine that you want to push something to this.

So let's try pushing "bar" to the array that's associated with the key "foo".

```typescript
myObj.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. TypeScript is not telling us we may get an error.

There happens to be a TypeScript config option for this! Go into your `tsconfig` and set `noUncheckedIndexedAccess` to `true` in your `compilerOptions`. By default this value is `false`.

```json
{
  "compilerOptions": {
    ...
    "noUncheckedIndexedAccess": true,
    ...
  },
  "include": ["./src"]
}
```

Let's go back into our file, and it says that object is "possibly undefined". Sadly, this won't actually have the result that we want.

```typescript
myObj.foo?.push("bar") 
```

It will check if `myObj.foo` exists, then push to it. But, actually what we want to do is if it doesn't exist already we want to create an empty array

So let's do that.

```typescript
if (!myObj.foo) {
  myObj.foo = []
}
```

TypeScript will stop erroring since TypeScript is smart enough to know now that `myObj.foo` has an array so you don't need to do any extra kind of generic stuff or any crazy helper function.

It just knows and it's wild that the inference is this smart

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.

Props to <a href="https://twitter.com/AndaristRake" target="_blank" rel="noopener">@AndaristRake</a> for this one.

Make accessing objects safer by enabling 'noUncheckedIndexedAccess' in tsconfig

0:00 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. 

0:18 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.

0:37 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. 

0:54 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." 

1:11 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. 

1:33 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.

I've got a puzzle for you!

```typescript
export type Letters = "a" | "b" | "c"

type RemoveC<TType> = any

type WowWithoutC = RemoveC<Letters>
```

I've got three letters at the top here that are all expressed as a union. So this can be either one of a b or c, and I want to create a type helper to remove one of the letters.

So how do I do that? You'd think of when something is an object or array you can usually kind of map over it.

But what's the iterator when it comes to unions? How do I map over each member of the union?

Well it turns out that typescript does this automatically. It's called **distributivity**. The way this works is we can actually treat these letters as though they were just one thing. For instance, we can treat them as just "c".

To do this, we're just going to check `TType`. We'll check if `TType` 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 the union and when you add `never` to a union. It just removes itself basically and then if it doesn't extend `"c"` we're going to return `TType`

```typescript
type RemoveC<TType> = TType extends "c" ? never : TType 
```

And now while without `c`, it's just `a` or `b`. That's unexpected because you would think that, like `TType`, `c` is part of these letters, so you would think `TType` does extend `c` because `c` is included so let's return `never`

But no. TypeScript actually automatically maps over each member of the union when it's doing a conditional type check.

This means that we can return different members of the union or manipulate them so we can actually just return d for instance

```typescript
type RemoveC<TType> = TType extends "c" ? "d" : TType 
```

So now, while without `c`, it is `a`, `b` or `d` and this is pretty exciting because it means that you can really tear into unions and do lots of really smart things with them.

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

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

Here, we create `RemoveC` - a type helper to remove `c` from a union of letters.

Map over a union type

0:00 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.

0:23 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.

0:46 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.

1:06 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."

1:27 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.

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

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 the elements known when I make the function? Here in this `getDisplayName` function we take in an `Animal` and we return a `displayName` based on the animal's name.

```typescript
interface Animal {
  name: string
}

interface Human {
  firstName: string
  lastName: string
}

export const getDisplayName = (item: Animal): { displayName: string } => {
  return {
    displayName: item.name,
  }
}
```

But what if we add a bit of dynamism here? Let's make it take in either an `Animal` or a `Human`

```typescript
export const getDisplayName = (
  item: Animal | Human
): { displayName: string } => {
  return {
    displayName: item.name,
  }
}
```

But really, we still know all the elements and their types before we get into the function call. So what you'd probably do is this:

```typescript
export const getDisplayName = (
  item: Animal | Human
): { displayName: string } => {
  if ("name" in item) {
    return {
      displayName: item.name,
    }
  }
}
```

And we'd do the same thing for the `Human` `firstName` and `lastName` and concatenate them together.

**When you start needing a generic is when you truly don't know what 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 in `getDisplayName`. We'll use `TItem` and extend `Animal` or `Human`.

```typescript
export const getDisplayName = <TItem extends Animal | Human>( 
```

Then in the return type we'll say `TItem` extends `Human` and returns a `humanName`. Otherwise, we'll return an `animalName`. And then inside the function body we'll return the `animalName`.

```typescript
export const getDisplayName = <TItem extends Animal | Human>(
  item: Animal | Human
): TItem extends Human ? { humanName: string } : { animal: string } => {
  if ("name" in item) {
    return {
      animalName: item.name,
    }
  }
}
```

What that means is we get a different return type based on what we pass in. So when we pass in a `name` we get an `animalName`, and when we pass in a `firtName` and `lastName` we get a `humanName` back.

This is where you actually need a generic. Inside the function it has to decide what it returns. If we just did a union type, it wouldn't repsond to what gets passed in.

So this is a way to really hack TypeScript's inference and get that information so you can use it in your return types.

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

0:00 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.

0:20 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.

0:35 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.

1:03 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.

1:18 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.

1:37 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.

1:51 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 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 wanna do is extract the values of the keys that start with `a` from this object. And so this union, `NewUnion` it's looking at the `a`, `a2`, `a3` in our `Obj`.

```typescript
export type Obj = {
  a: "a"
  a2: "a2"
  a3: "a3"
  b: "b"
  b1: "b1"
  b2: "b2"
}

type ValuesOfKeysStartingWithA<Obj> = {
  [K in Extract<keyof Obj, `a${string}`>]: Obj[k]
}[Extract<keyof Obj, `a${string}`>]

type NewUnion = ValuesOfKeysStartingWithA<Obj>
```

And if I change `a` to `"FOO"`, for example, it's extracting the values of those keys that start with A. But it's a pretty messy type signature because there's quite a bit of duplication here. In `ValuesOfKeysStartingWithA` we're extracting the key of the object, and we're saying we only want those keys that start with a.

```typescript
type ValuesOfKeysStartingWithA<Obj> = {
  [K in Extract<keyof Obj, `a${string}`>]: Obj[k]
}[Extract<keyof Obj, `a${string}`>]
```

And then we return the part of the object that corresponds to that key. And then we do it a second time because we need to map over the object in order to pull those values out.

We can actually reduce the duplication by saving it to a local variable.

And 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.

So to start, I'll add the `_ExtractedKeys` type variable to `ValuesOfKeysStartingWithA`. And TypeScript is yelling at me, because it wants two type parameters.

But, I can actually set a default type parameter to `_ExtractedKeys`, and I can set it to:

```typescript
Extract<keyof Obj, `a${string}`>
````

Now that our keys are extracted we can get rid of both instances of `Extract` and name them `_ExtractedKeys` instead.

```typescript
type ValuesOfKeysStartingWithA<
  Obj,
  _ExtractedKeys = Extract<keyof Obj, `a${string}`>
> = {
  [K in _ExtractedKeys]: Obj[k]
}[_ExtractedKeys]
```

But, we're going to get an error with our first use of `_ExtractedKeys` saying that it's is not assignable to type string or number or blah, blah, blah. That's because it takes the value from the type of the generic.

So if we add to our `_ExtractedKeys` generic and say it `extends keyof Obj`, then it starts working because we say `_ExtractedKeys` extends the key of the object.

```typescript
type ValuesOfKeysStartingWithA<
  Obj,
  _ExtractedKeys extends keyof Obj = Extract<keyof Obj, `a${string}`>
> = {
  [K in _ExtractedKeys]: Obj[k]
}[_ExtractedKeys]
```

This is now much easier to read and our union still stays the same.

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

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

0:00 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.

0:16 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.

0:43 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?"

0:59 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.

1:20 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.

1:36 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.

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

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

```typescript
export class SDK {
  constructor(public loggedInUserId?: string) {}

  createPost(title: string) {
    this.assertUserIsLoggedIn()

    createPost(this.loggedInUserId, title)
  }

  assertUserIsLoggedIn() {
    if (this.loggedInUserId) {
      throw new Error("User is not logged in")
    }
  }
}
```

It's kind of like if you imagine the back ends at a center point where you invoke class and you've got all your methods and stuff.

And here we've got a `loggedInUserId` 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.

But inside `createPost` we want to assert that the user is logged in and there we're going to use. the user ID. But the issue here is that we've got `string` or `undefined` in for the first argument of the call to `createPost` which is not good because actually we _need_ `string` and 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.loggedInUserId` is defined. If we were to move the if statement in our assertion to be inside `createPost` here then it would work.

```typescript
export class SDK {
  constructor(public loggedInUserId?: string) {}

  createPost(title: string) {
    this.assertUserIsLoggedIn()

    if (this.loggedInUserId) {
      throw new Error("User is not logged in")
    }

    createPost(this.loggedInUserId, title)
  }

  assertUserIsLoggedIn() {}
}
```

But how do we get this. kind of inference working? Well we can return `asserts this is this &`. Which means we are saying `assertUserIsLoggedIn` is an assertion function now and we're saying that `this is this` and something else and we can add `loggedInUserId: string`

```typescript
assertUserIsLoggedIn(): asserts this is this & {
  loggedInUserId: string
} {
  if (this.loggedInUserId) {
    throw new Error("User is not logged in")
  }
}
```

What this does is it basically just adds an intersection to the class. and matches them both together and `loggedInUserId: string` wins. So we get the string inside the SDK and now `this.loggedInUserId` is typed string.

We could probably do even something more in here. We could say `wow` which is a Boolean. And then use `this.wow` in `createPost`

```typescript
export class SDK {
  constructor(public loggedInUserId?: string) {}

  createPost(title: string) {
    this.assertUserIsLoggedIn()

    createPost(this.loggedInUserId, title)
    this.wow
  }

  assertUserIsLoggedIn(): asserts this is this & {
    loggedInUserId: string
    wow: boolean
  } {
    if (this.loggedInUserId) {
      throw new Error("User is not logged in")
    }
  }
}
```

So assertion functions are pretty useful. We 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 in a lot more of a reusable way.

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

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

0:00 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.

0:14 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.

0:28 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.

0:48 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.

1:13 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.

1:32 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 of deploying a TypeScript 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, which just is inside src.

```typescript
export const hello = () => {} 
```

And we've got our `package.json` here, which has a basic name, `"matt-preconstruct-example"`. This is not set up at all for deploying to NPM.

```json
{
  "name": "matt-preconstruct-example",
  "version": "1.0.0",
  "main": "index.js",
  "author": "Matt Pocock",
  "license": "MIT",
  "devDependencies": {
    "typescript": "^4.6.4"
  }
}
```

Let's see how quick it can go. Run the following command in your terminal.

```bash
yarn add -D @preconstruct/cli 
```

This is going to install a CLI that handles our building along with a bunch of other stuff.

And now we run this:

```bash
yarn preconstruct fix 
```

And Preconstruct is there because we've installed the CLI. You'll notice here in our `package.json`, that it's added `dist/matt-preconstruct-example.cjs.js` into our `main`.

```json
{
  "name": "matt-preconstruct-example",
  "version": "1.0.0",
  "main": "dist/matt-preconstruct-example.cjs.js",
  "author": "Matt Pocock",
  "license": "MIT",
  "devDependencies": {
    "@preconstruct/cli": "^2.1.5",
    "typescript": "^4.6.4"
  }
}
```

So we don't even need to think about our `main`. If we want to add bundling for ESM, we can just add `"module": true`, and run `yarn preconstruct fix` again, and it will go in and add the ESM version.

Now we can run the following:

```bash
yarn preconstruct build 
```

While this is running I'll go ahead and add that build command to my scripts in my `package.json`

```json
{
  "name": "matt-preconstruct-example",
  "version": "1.0.0",
  "main": "dist/matt-preconstruct-example.cjs.js",
  "author": "Matt Pocock",
  "license": "MIT",
  "scripts": {
    "build": "yarn preconstruct build"
  },
  "devDependencies": {
    "@preconstruct/cli": "^2.1.5",
    "typescript": "^4.6.4"
  }
}
```

And now we've got a dist file with all of the correct stuff in there. We can just ignore it for now.

And we've got cgs.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.

And from here, you could just run `yarn publish` or `npm publish`, send this up to the cloud, and it'll be ready for you to use in any of your apps.

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

0:00 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. 

0:37 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.

0:52 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.

1:16 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. 

1:35 From here, I could just run yarn publish, or NPM publish and send this up to the cloud and it's ready for you to use in any of your apps.

It's really important to get a good mental model for things that the TypeScript compiler does. And, that's especially true for read-only properties. So up top here we've got this `age` variable. `age` here is inferred as a number.

```typescript
export let age = 31

export const name = "Matt"

const tsPeople = ["Andarist", "Titian", "Devansh", "Anurag"]
```

So if I reassign `age` to another number, it's going to work because `age` is declared with a `let` and it's saying that `age` can change over time. Whereas, if I put `age` as a `const`, then I can't reassign to it.

So, `age` instead of just being inferred as a `number`, it's actually inferred as its **literal type as 31** which is really interesting.

```typescript
export const age = 31 
```

I can sort of force this on the `let` by saying age is 31 and then it gets inferred. And then, if I try to reassign to it, it's not going to let me because 31 is not assignable to type 32.

```typescript
export let age: 31 = 31

// type 31 is not assignable to type 32
age = 32
```

The same is true for strings too so the constant `name` `"Matt"` is actually being inferred as `"Matt"`, but it gets more complicated when you go to arrays and objects.

Even though I'm declaring the `tsPeople` array as a const, members of the array can be manipulated. So I can say this for instance:

```typescript
const tsPeople = ["Andarist", "Titian", "Devansh", "Anurag"]

tsPeople[0] = "Eddy"
```

So here it's being declared as `string` inside the member, whereas if I say `as const` to `tsPeople`, I'm not going to be able to reassign to it, and this is now going to be declared as its literal so it's going to be inferred all the way down.

```typescript
const tsPeople = ["Andarist", "Titian", "Devansh", "Anurag"] as const

// Cannot assign to '0' because it is a read-only property
tsPeople[0] = "Eddy"
```

The same is true for objects too. I can say `as const` and now everything is inferred all the way down.

```typescript
const moreTsPeople = {
  Andarist: "Andarist",
  Titian: "Titian",
  Devansh: "Devansh",
  Anurag: "Anurag",
} as const
```

This is really critical if you want like type checking or you want inference based on the members of the array that you're passing in, or the values of the objects that you're passing in.

Getting this mental model solid is going to help you in a ton of different places.

This mental model is INCREDIBLY useful for all sorts of intermediate-advanced typings.

This mental model is INCREDIBLY useful for all sorts of intermediate-advanced typings: 

If TypeScript knows a value can't change, it'll infer it to its literal type.

Understand how TypeScript infers literal types

0:00 It's really important to get a good mental model for things that the TypeScript compiler does. That's especially true for read only properties. Here, we've got this age property up top here, or variable. Age here is inferred as a number.   
[0:00]   
  
0:16 If I reassign age here, it's going to work because age is declared with a let. It's saying that this age can change over time. Whereas if I put this as a const, then I can't reassign to it. Age, instead of just being inferred as a number, it's actually inferred as its literal type as 31. Which is really interesting.   
  
0:37 I can force this on the let by saying age is 31 and then it gets inferred. Then if I try to reassign to it, then it's not going to let me, because 31 is not assignable to type 32. The same is true for strings too. Name: "Matt" is actually being inferred as Matt.   
  
0:55 It gets more complicated when you go to raise an object. Here, even though I'm declaring the array as a string, or rather as const, members of the array can be manipulated. I can say tsPeople [] = "Eddy";. Here, it's being declared as string inside the member.   
  
1:15 Whereas if I say it as const;, then first of all, I'm not going to be able to reassign to it. Also, this is now going to be declared as it's literal. It's going to be inferred all the way down. The same is true for objects too.   
  
1:28 Here I can say moreTsPeople. Andarist = 'whatever'. In here, I can say as const, and now everything is inferred all the way down. This is really critical. If you want like type checking or you want inference based on the members of the array that you're passing in, or the values of the objects that you're passing in.   
  
1:50 This is where TypeScript, getting that mental model really solid is going to help you in a ton of different places.

Folks, this one simple trick will improve your refactoring whenever you need to use an undefined value in TypeScript.

Here, I've got a `createUser` function where I'm creating a bunch of different users. But, I've now got a new requirement here, which is I also need to add a role to some users and some not.

```typescript
interface UserInfo {
  name: string
}

export const createUser = (userInfo: UserInfo) => {}
```

So here, what I could do is I could say for some users, I'm gonna pass them the `admin` role like this.

```typescript
interface UserInfo {
  name: string
  role?: "admin"
}
```

except I really need to go through every bit of my code base. Imagine these are all spread out over different files, and I need to check who I need to make an admin and who I don't.

```typescript
createuser({
  name: "Matt",
})
createUser({
  name: "David",
})
createUser({
  name: "Laura",
})
createUser({
  name: "Andarist",
})
createUser({
  name: "Farzad",
})
createUser({
  name: "Jenny",
})
```

So, I know that for instance that I need to make Matt an admin, I need to make David an admin, but Laura is not an admin. So the way that I like to do this is I like to add an in-between step here, which I can either pass role or `undefined` like this.

```typescript
interface UserInfo {
  name: string
  role?: "admin" | undefined
}
```

And this adds a different behavior here. It's saying we need to pass the property role or we can pass undefined there. So even though technically this is undefined here, we still need to add role as undefined.

```typescript
createUser({
  name: "Laura",
  role: undefined,
})
```

And that means that I do get all of the inference and the auto completes that I'm looking for. And it means that I can just go back later and just remove all of these `undefined` roles.

So that's really useful. And it's sometimes even desirable to keep this type signature if you do want to allow passing of undefined, but you want to make it really visible to the user that they've done that.

So again, this is a really nice little syntax switch that you can do moving from either "you don't need to pass this property" or "you do need to pass this property, but you can still pass undefined".

This one little tip has saved me hours of refactoring time. Passing string | undefined instead of ?: string ensures that ALL call sites must be given a value.

This one little tip has saved me hours of refactoring time. Passing `string | undefined` instead of `?: string` ensures that ALL call sites must be given a value - amazing when you need to check every case in your repo.

Ensure that all call sites must be given value

0:00 Folks, this one simple trick will improve your refactoring whenever you need to use an undefined value in TypeScript. Here, I've got createUser function where I'm creating a bunch of different users, but I've now got a new requirement here, which is, I also need to add a role to some users and some not. 

0:18 Here, what I could do is I could say for some users, I'm going to pass them a role, which is going to be admin like this role?: "admin". Except I really need to go through every bit of my code base. Imagine these are all spread out of different files. There's 40 of them. I need to check who I need to make an admin and who I don't. 

0:36 Here, I know that for instance I need to make Matt an admin, I need to make David an admin. Laura is not an admin for instance. The way that I like to do this is I like to add an in between step here, which I can either pass role, or undefined like this. 

0:53 This adds a different behavior here. It's saying we need to pass the property role or we can pass undefined them. Even though technically this is undefined here, we still need to add role as undefined. That means that I do get all of the inference and the auto completes that I'm looking for. 

1:14 It means that I can just go back later and just remove all of these role undefined like so. Bam. That's really useful and it's sometimes even desirable to keep this type signature, if you do want to allow passing of undefined, but you want to make it really visible to the user that they've done that. 

1:33 This again is a really nice little syntax switch that you can do moving from either you don't need to pass this property, or you do need to pass this property, but you can still pass undefined.

You can do really interesting things with TypeScript using indexed access types, which gives you access to deeper parts of an object or an array. Here we're accessing the primary color just by passing. in primary into this access point here.

```typescript
type PrimaryColor = ColorVariants["primary"] 
```

And we can also access it via a union too. Where we can say color variants secondary or tertiary and get a union back from here too.

```typescript
type NonPrimaryColor = ColorVariants["secondary" | "tertiary"] 
```

We can even pass in a bigger union where we say the `keyof` the `ColorVariants`, passing all of them in, and then we suddenly get every single color there too.

```typescript
type EveryColor = ColorVariants[keyof ColorVariants] 
```

We can do the same thing with tuples where we have this array of letters. And, then we have `AOrB`, where we pass in an array of or a union of numbers. And then we have `Letter`, which is now just a union of all of the numbers, so we get every member of the array back.

```typescript
type Letters = ["a", "b", "c"]:

type AOrB = Letters[0 | 1];
type Letter = Letters[number];
```

Finally we can do this with deep accessed objects and we can combine them. So here a `Role` is a `UserRoleConfig` where we pass in a `keyof UserRoleConfig`,which accesses both `user` and `superAdmin`. And then, `[number]`, which returns all of the members of each array.

```typescript
interface UserRoleConfig {
  user: ["view", "create", "update"]
  superAdmin: ["view", "create", "update", "delete"]
}

type Role = UserRoleConfig[keyof UserRoleConfig][number]
```

You can imagine this going further and further down. TypeScript is so incredibly powerful here and we end up with just a simple union of numbers.

Accessing object values and array members is MUCH more powerful in the type world than it is in the runtime world.

Accessing object values and array members is MUCH more powerful in the type world than it is in the runtime world. 

Passing a union... RETURNS a union!

Access deeper parts of objects and arrays

0:00 You can do really interesting things with TypeScript, with indexed access types, which gives you access to deeper parts of an object or an array. Here, we're accessing the PrimaryColor, just by passing in primary into this like access point here. We can also access it via a union too, where we can say, ColorVariants, secondary or tertiary, and we get a union back from here too.

0:24 We can even pass in a bigger union, where we say, the keyof the ColorVariants, we pass all of them in, and then we suddenly get every single color there too.

0:33 We can do the same thing with tuples, where we have this array of letters here, and then we have AOrB where we pass in an array or a union of numbers, and then we have Letter here which is now just a union of all of the numbers. We get every member of the array back.

0:51 Finally, we can do this with deep accessed objects and we can combine them. Here, a Role is UserRoleConfig, where we pass in a keyof UserRoleConfig, which accesses both user and super admin, and then number here which returns all of the members of each of the array, and you can imagine this going further and further down.

1:13 TypeScript is so incredibly powerful here, and we end up with just a simple union of members.

We're getting this really weird data shape back from our API where it's prefixing everything with maps. That's kind of annoying.

```typescript
interface ApiData {
  "maps:longitude": string
  "maps:latitude": string
}
```

Ideally, we would be able to just remove maps from all of these attributes and just have `longitude` and `latitude`. So we've got a type helper here called `RemoveMapsFromObj`, but it's not actually doing the thing.

```typescript
type RemoveMapsFromObj<T> = {
  [K in keyof T]: T[K]
}
```

So we need to somehow strip `maps` from all of these prefixes. We can do that with a type helper. We'll make a type called `RemoveMaps` that takes `T`. We then check if `T` extends the interpolated string, `maps:${string}`, if it does we return `'blah'`, otherwise we return `T`.

```typescript
type RemoveMaps<T> = T extends `maps:${string}` ? "blah" : T 
```

Now inside of `RemoveMapsFromObj` we can do some remapping. We can say `K in keyof T as RemoveMaps<K>`.

```typescript
type RemoveMapsFromObj<T> = {
  [K in keyof T as RemoveMaps<K>]: T[K]
}
```

It's actually going to be remapped to `RemoveMaps` from `K` because `K` is going to be, as we're iterating over `ApiData` object, the maps longitude maps latitude. But, there's an issue here, which is we're now just getting back `"blah"`, right?.

So if I add something else to `ApiData`

```typescript
interface ApiData {
  "maps:longitude": string
  "maps:latitude": string
  awesome: boolean
}
```

That `awesome` boolean would be added because that doesn't contain `maps` so it doesn't trigger this `blah` thing in `RemoveMaps`. But we need to somehow extract the suffix of this maps section and return it where `blah` is currently being returned.

We can do that with `infer`. We'll say `infer U` which is going to infer the rest of the string at that position.

```typescript
type RemoveMaps<T> = T extends `maps:${infer U}` ? U : T 
```

And suddenly we end up with longitude and latitude as we're expecting!

Still struggling with infer? How about this - you can use it in combination with string literals to manipulate keys of objects.

Still struggling with infer? How about this - you can use it in combination with string literals to manipulate keys of objects. 

SUPER useful when you've got an external API you can't control giving you weird, non-JavaScripty keys.

Use infer in combination with string literals to manipulate keys of objects

0:00 We're getting this really weird data shape back from our API where it's prefixing everything with maps, that's annoying. Ideally, we would be able to just remove maps from all of these attributes and just have longitude and latitude.

0:12 We've got a type helper here called RemoveMapsFromObj, but it's not actually doing the thing. It's just saying type design shape is "maps;longitude", "maps;latitude". We need to somehow strip maps from all of these prefixes. We can do that with a type helper.

0:27 We can say type RemoveMaps. We're first going to check if T extends 'maps;${string} ' ? 'blah'. Otherwise we'll return T. Now what we can do is inside RemoveMapsFromObj we can do some remapping here.

0:53 We can say (K in keyof T as RemoveMaps); because K is going to be as we're iterating over this object, this is going to be the "maps;longitude", "maps;latitude". There's an issue here, which is we're now just getting back 'blah'.

1:09 If I add something else in here, we would have something like awesome; boolean for instance. This would be added, because that doesn't contain maps. It doesn't trigger this 'blah' thing here, but we need to somehow extract the suffix of this maps section and return it here.

1:28 We can do that with infer. Infer, we're going to infer U, which is going to infer the rest of the string at that position. Suddenly we end up with longitude and latitude as we're expecting.

Here, I've got a function called `returnWhatIPassIn`, and it takes an `input` of `unknown` and returns an input of unknown so whatever I pass in here it's going to return unknown.

```typescript
export function returnwWhatIPassIn(input: unknown): unknown {
  return input
}
```

I'm not really fulfilling the promise of this function's name. I can fulfill it by using a function overload for each member of the thing that I want to do.

So I can do `export function` and have `input` be a `string` and suddenly I can pass in strings now. And that will return me a string.

```typescript
export function returnwWhatIPassIn(input: string): string 
```

I can also add another overload here which will be a `number`. So if I pass `12` to `returnWhatIPassIn` then it will return me a `number`.

```typescript
export function returnwWhatIPassIn(input: number): number
...
const result = returnWhatIPassIn(12)
```

The issue here is that I'm going to have to add an overload for everything I can possibly imagine using this function for, which is a little bit tricky. If you have a set number of things that you want to pass in and return then that might be useful, but the real way to do this is with a generic.

So I can add `TInput` to `returnWhatIPassIn`. I replace all the unknowns with `TInput` and just return the `input` in the function body.

```typescript
export function returnwWhatIPassIn<TInput>(input: TInput): TInput {
  return input
}
```

Now, whatever I pass in is going to get returned to me. So I can pass in literally anything and it's all going to get returned to me. This is a good way of thinking about the difference between function overloads and generics.

A simple function - returnWhatIPassIn - can be enough to stump many newbie TypeScript devs.

A simple function - `returnWhatIPassIn` - can be enough to stump many newbie TypeScript devs.

Here, I compare two approaches - function overloads and generics - to see which one works best.

Compare function overloads and generics

0:00 Here, I've got a function called returnWhatIPassIn. It takes an input of unknown and returns an input of unknown. Whatever I pass in here, it's going to return unknown. I'm not really fulfilling the promise of this function's name. I can fulfill it by using a function overload, if I want to, for each member of the thing that I want to do.

0:20 I can do export function and have this be a string. Suddenly, I can pass in strings now, which is good, and that will return me a string. I can also add another overload here, which will be a number, for instance. If I add in 12 here, then it will return me a number. Great.

0:37 The issue here is that I'm going to have to add an overload for everything I can possibly imagine using this function for, which is a little bit tricky. If you have a set number of things that you want to pass in and return, then that might be useful. The real way to do this is with a generic. I can add just T in here, or let's say TInput.

0:58 TInput is going to be...I'm just going to replace all the pieces with this and I'm just returning the input. Now, whatever I pass in, I'm going to get returned to in here. I can pass in an object. I can say blah, blah, blah, blah, blah, blah, blah, and that's all going to be returned to me like this. This is a good way of thinking about the difference between function overloads and generics.

This piece of code might look completely confusing to you.

```typescript
type Name = string
type GoodName = VeryGoodName | "fred"
type VeryGoodName = "matt"

const isGoodName = (name: GoodName) => {}

isGoodName("matt")

export type Result = Name extends GoodName ? true : false
```

`Name extends GoodName`, if it does, return `true`, if it doesn't, return `false`. What, okay, and you'd expect name,

Now you'd think this would return `true` right? `Name` is a string, `VeryGoodName` is the string `"matt"` and `GoodName` is a union between `VeryGoodName` and `"fred"`. All strings.

So it'd make sense for `Name extends GoodName` to be true, but it's not. **It's actually false.** That's interesting!

To understand this, we need to understand assignability.

```typescript
class Animal {
  isAnimal() {
    return true
  }
}

class Dog extends Anigal {
  isDog() {
    return true
  }
}

class Labrador extends Dog {
  isLabrador() {
    return true
  }
}
```

Here we have kind of like the traditional object oriented classes thing. And we can take our 'thing' for a walk. We can say that we can take any dog for a walk, but `Animal` is not assignable to dog.

```typescript
const takeForWalk = (dog: Dog) => {}

takeForWalk(new Animal()) // error
```

We can take our `Labrador` for a walk. That's absolutely fine. We can take our `Dog` for a walk, but we can't take our `Animal` for a walk. The reason for that even though a `Dog` is an `Animal`, an `Animal` is a wider version of that.

Whereas a `Labrador` is a narrower version of a `Dog`. So you can take your `Labrador` for a walk because it's a narrow version of a `Dog`. It's still a `Dog`, right?.

And so we can look back on our `Result` type and see that what we are really checking here with the `extends` is if `Name` is a narrower version of `GoodName`. And it's not.

```typescript
type Name = string
type GoodName = VeryGoodName | "fred"
type VeryGoodName = "matt"

const isGoodName = (name: GoodName) => {}

isGoodName("matt")

export type Result = Name extends GoodName ? true : false // false
```

And so we can acually swap them and it will be `true` since `GoodName` is the narrower version of `Name`.

```typescript
export type Result = GoodName extends Name ? true : false // true 
```

`VeryGoodName` is also a narrower version of name, and it's also a narrower version of `GoodName`, because it's part of that union too.

```typescript
export type Result1 = VeryGoodName extends Name ? true : false // true
export type Result2 = VeryGoodName extends GoodName ? true : false // true
```

That should give you a good idea about what assignability means, and about what this `extends` keyword is doing in this conditional check.

I often find conditional types SUPER hard to read. Here's how to get a better mental model for assignability in TypeScript.

```typescript
export type Result = string extends "matt" ? true : false;

```

I always find these conditional types SUPER hard to read. If you think Result is true, you might need a better mental model for assignability in TypeScript.

Understand assignability in TypeScript

0:00 This piece of code might look completely confusing to you. Name extends GoodName. If it does, return true. If it doesn't, return . You'd expect Name is a string up here. GoodName is either VeryGoodName or Fred here. The VeryGoodName is Matt. This is a string union. It should be related to string, so this should be returning true, right? No, it returns . That's interesting.

0:26 To understand this, we need to understand assignability. We're going to go back a little bit to do that. Here, we've got an Animal, we've got a Dog which extends Animal, and we got a Labrador which extends Dog. Here, that's like the traditional object-oriented classes thing.

0:40 We can take our thing for a walk. We can say, "OK, we can take any dog for a walk," but Animal is not assignable to Dog. We can take our Labrador for a walk, that's absolutely fine. We can take our Dog for a walk, but we can't take our Animal for a walk. We can't take our goldfish for a walk.

0:58 The reason for that is the animal, even though a dog is an animal, an animal is a wider version of that, whereas a Labrador is a narrower version of a dog. You can take your Labrador for a walk because it's a narrow version of a dog. It's still a dog.

1:13 We can look back on this and think Name extends GoodName. What we're checking here is, is Name a narrower version of GoodName, just like an animal is a dog is a narrower version of an animal? We notice that we can actually swap these guys over.

1:33 GoodName extends Name, and it will return true because GoodName is a narrower version of Name. VeryGoodName is also a narrower version of Name and it's a narrower version of GoodName as well because it's part of that union, too.

1:47 We get the same thing in this isGoodName thing here, where we can pass in either Fred or Matt. If we change this to VeryGoodName, then it's still going to work but we can't pass in Fred anymore. That should give you a good idea about what assignability means and about what this extends keyword is doing in this conditional check.

## No argument, no type argument

```typescript
const [undefinedThing, setUndefinedThing] = useState() 
```

The problem with this code is that when you don't set the type argument and you don't pass anything in, the thing you create will be undefined. What this means is that you won't ever to be able to set undefinedThing to anything at all.

## No argument, type argument

```typescript
const [stringThing, setStringThing] = useState<string>() 
```

The type for this will actually be set as either string or undefined since the argument is undefined. This does have some valid use-cases.

## Argument, no type argument

```typescript
const [emptyArray, setEmptyArray] = useState([]) 
```

When you pass an argument, but don't set a type argument, you might run into the problem of the type being set incorrectly. It does work, and if you pass something like a string it will behave as expected.

But, if you pass an empty array as the initial state, it's going to set the type to be an array of never. So you won't ever be able to add anything to your array.

## Argument, type argument

```typescript
const [arrayOfIds, setArrayOfIds] = useState<{ id: string }[]>([]) 
```

And here I have a proper instance of useState with an initial argument and a type argument set.

You will want to do this when you are passing empty objects and arrays as the initial state.

React's useState can behave in slightly unexpected ways in TypeScript - sometimes giving you undefined when you least expect it.

React's useState can behave in slightly unexpected ways in TypeScript - sometimes giving you 'undefined' when you least expect it. 

Here's a failsafe mental model you can use to never get burned again.

Avoid unexpected behavior of React’s useState

0:00 Let's talk about useState, because useState in react has some interesting behaviors depending on what you pass it, and there's four configurations.

0:08 If you pass useState nothing and you don't pass a type argument either, then the thing that it creates will be undefined. You can't set anything else to it. You can say setUndefinedThing as 123 or something. This actually will work surprisingly, but it's not going to do what you want it to do. This thing is always going to be undefined.

0:29 If you don't pass it an argument but you do pass it a type argument, then this is going to be typed as string or undefined, because technically the thing that you've passed in here is undefined. If you pass it in here, then it's not going to work. If you don't pass anything it will be string or undefined, which is useful for a lot of cases.

0:47 If you pass it just an argument but with no type argument then it might infer it incorrectly. If you pass it like a string, if you say this, this, this whatever, then it will infer correctly because it's time to string and that's the thing you passed in. Whereas if you pass in just emptyArray, it's not going to have fun.

1:07 If you try to set anything to it, so setEmptyArray like with an array of id '123', this is first of all going to error because it's not assignable to type 'never' because this array should never contain anything according to your types. You're still going to get never array for it.

1:24 With arrays especially, or objects, or things that don't contain anything yet, you need to pass in a type argument and a real argument. This means that then arrayOfIds is typed as array string, and you can set the arrayOfIds properly.

Deriving vs Declaring is key to getting the most inference out of your types with as few lines of code as possible.

But sometimes, you want to _ensure_ that some code conforms to a type without losing its literal values.

Enter satisfies()() 👀

Conform a Derived Type Without Losing Its Literal Values

0:00 A golden rule of effective TypeScript is you should always try and derive types instead of declare types. Here, we're creating this user actions array, where we already typed the enum for the type of actions that the user can do, and the type of role that you need in order to do them.

0:16 I think there's a better way to do this. Here, we've started obeying the golden rule, which is we're now declaring the user actions as a const, which means they're not going to change. There's a static configuration. We're now deriving the action and the role from the data structure that we have already.

0:34 There's a problem here, though. With user actions declared the way it is, it's not actually enforced what type this configuration should be. This type can technically be anything, and if I accidentally add this as a role here, then we're going to get this obscure type error down at the bottom here.

0:48 The issue is, if I add a type annotation up here saying what sort of vague type I want it to be, we first of all get an error up here, but we also get errors down here in that they're now typed as string instead of the actual const values that should be there.

1:03 We can do something really smart to cover this. I've created this satisfies function here. What this allows me to do is pass in a generic to say, "This is the kind of thing I want to accept." Then, when I actually call the function, it allows me to pass in a narrow version of that generic.

1:20 What it's going to do is it's not going to return a number here. It's going to return two, but it enforces that two is at least a number. For instance, if I pass this in here, then it's saying it's not assignable to type number. What this means is that I get the best of both worlds. I get to vaguely say what I want in this slot, and then also get the narrow inference here.

1:41 With the config that we defined before, we can say this very loose shape of generic here, and then we still get all of the deep inference right there. If I delete one of these things, it's going to give me a type error, because I didn't add the roles property.

TypeScript 5.0 beta brings a bunch of exciting features, including const annotations, decorators, speed improvements and a new option for resolving modules in TS.

TypeScript 5.0 beta brings a bunch of exciting features, including const annotations and decorators.

TypeScript 5.0 beta is out! Here's a breakdown of all the most important features.

TypeScript 5.0 Beta Deep Dive

[0:00] What's up wizards? TypeScript 5. Beta just dropped. It brings in a whole load of new functionality and new toys that we can play with. I'm going to be talking about the headline items and showing you exactly what you need to know for the upcoming 5.. Let's go.

[0:13] To get started, you can add TypeScript at the beta version to your package.json. Then when you're inside a TypeScript file, you can run Command + Shift + P and select your TypeScript version. You should use the Workspace Version 5. Beta. I'm going to go quick fire through some of the small changes and we're going to see the big changes at the end.

[0:29] They've added a new option here to moduleResolution called bundler. We had some options called node16 and nodenext before, but this meant that you had to add the file extension to things that you imported.

[0:38] Using "moduleResolution": bundler now means that TypeScript is going to map up to your modern bundler like Vite, esbuild, swc, Webpack. This is an extremely welcome change, but probably, your framework is just going to handle it and it's all going to be fine.

[0:50] Another small change they've made is they've slightly improved enums. I'm on record with my thoughts about enums, you can take a look here. Let's say we have an enum called LogLevel with DEBUG, WARN, and ERROR. We have a function called log which takes in a level and a message. In previous versions of TypeScript, you could pass any number into here and it would work.

[1:09] TypeScript wouldn't give you an error message here, but now you can pass in zero for DEBUG, one for WARN, and two for ERROR, if you really want to. If you pass something that isn't represented by the enum, then it's going to error at you.

[1:20] If you use literals instead, then this will have the same behavior as before. It will still force you to pass in LogLevel.DEBUG here, instead of the literal value. This is another extremely welcome change, but I don't think it changes my overall idea about enums, but you know, safety is good.

[1:36] The other welcome change here is some speed optimizations in TypeScript itself. This means that the actual package size of TypeScript is now only 58 percent of what it was. If you're using TypeScript to build your application or your library, then you're going to see some speed improvements.

[1:49] I imagine you're also going to see some speed improvements if you run TypeScript on CI to lint your project, which is what most people do. Without any changes, this is a massive win and I'm keen to hear in the comments if you found any improvements.

[2:01] Let's talk about the two big headline items from this release. Number one is const annotations. Const annotations give you a new tool with generics in order to improve the inference that you get when you call functions.

[2:12] Let's say we have a function called routes. The routes parameter takes in an array of T, which is going to be a set of routes. We create a function called addRedirect, which is going to redirect from one route to another route. Let's call this routes function with /users, /posts, and /admin/users, and we get back a router at the end of it.

[2:31] Now, let's use the addRedirect function on that router to redirect from /admin/users to /users. This code doesn't do anything, of course. We could add some implementation inside here, if we wanted to, but I'm going to use it to explain how TypeScript infers this T.

[2:44] You notice that even though we've added these three routes here, I can add anything to addRedirect and it won't yell at me. That's because if we hover over routes, you can see that it's inferred as an array of strings instead of the literal values I've passed in. Which means that addRedirect down here is from: string and to: string, meaning that it accepts any string.

[3:03] This is quite a difficult problem to solve. There are some tricks to do it, but in TypeScript 5., you can just add a const T to the start here. Now, the things that you pass into routes are going to be inferred as their literal. We get /users or /posts or /admin/users. This means that addRedirect down here has from the route and to the route as well.

[3:22] That means that when we change this, we're going to get autocomplete for the options that we have here. I can either add /admin/users or /posts or /users. Quietly, I think this is one of the most important features TypeScript has shipped for a while, because I'm starting to see how much easier it makes handling these generics when you care about the literal values.

[3:41] Finally, let's look at decorators. Decorators have been around in TypeScript for a while under an experimental flag, but 5. brings them up to speed with the ECMAScript Proposal. Which is now in stage three, meaning it's in the stage where it gets added to TypeScript.

[3:55] Let's imagine I create a class called SDK. I'm going to add a bunch of methods to this SDK, including getUser and getPost. I've stubbed them out with different methods, but you could imagine these would go and fetch the post and the user from a database.

[4:06] Let's imagine that I want to log the getUser and getPost functions. I want to log when the method is called. I also want to log when the method resolves. For this, I'd need to make getUser async, I'd need to capture the result of Promise.resolve, add in a log, and then return the result.

[4:20] I'm then going to have to copy this logic for every single method I have here. If only there were an abstraction where I could just wrap these methods and add some logging to them. This is where decorators come in. They allow you to wrap methods and entire classes in order to add functionality.

[4:35] Let's create a function called log. It's going to take in the originalMethod, which is typed as a function that can take in anything and return anything. As a second parameter here, we're going to add underscore context, which is a ClassMethodDecoratorContext.

[4:47] Next, we're going to return another function, which is going to be the method. Just like in getUser, I'm going to save the results here by calling the originalMethod using originalMethod.call. This lets us pass this into the originalMethod, meaning it doesn't lose the context of where it's called, in this case, in the SDK. Next, we can return the results.

[5:05] Now, let's do the logging that we want to do from this decorator. Instead of hard coding getUser, we can replace it with _context.name. This is going to be the name of the method that we've called. We can replace the ID by JSON.stringify in the args that we get. Next, let's log when the function completes too. All the code that we need for our decorator is complete.

[5:23] Instead of having all of this complicated code down here in repeated code, we can just decorate the functions with log. When getUser is called, log will be called and it will call the underlying method itself. This means you get a really beautiful descriptive syntax, which can abstract away some horrible complicated code.

[5:41] There's a lot more to talk about with decorators and I think I'll do a separate video on typing them properly, because as you saw, there was quite a lot of any's in my code. I'm really excited to see where they go and I feel like this might rejuvenate classes in the JavaScript community a little bit.

[5:53] Since function components took over React, classes have been on the out. Being able to capture abstractions and decorators seems like a really, really nice feature for TypeScript and JavaScript as a whole. I'm excited, bring the classes back. Let's have them. It's been lovely seeing you as always and I'll see you very soon.

Your default attitude towards return types should be 'don't use them', unless one of three things are true:

* You're writing a function with multiple branches
* You're building a library
* You have a specific TS perf concern and you're banging your head against the wall

When should you use return types in TypeScript? The use cases are narrower than you might think...

When should you use return types? The use cases are narrower than you might think...

Don't use return types, unless...

[0:00] What's up, wizards? We are going to be looking at return types today. Return types in TypeScript give you the ability to specify what you think a function should return. Here, we have a function called makeId. This returns a string of ID with a random number of length 16 appended to the end of it.  
  
[0:16] If we want to, we can guarantee that this function returns a string by adding string here. Now we can see that result is result string. We could force makeId to return a number instead by changing this to number. Now we get an error here saying, "Type string is not assignable to type number."  
  
[0:30] The result down here changes its type to match the return type. This means you can use a return type to force a function to return a certain thing. If we remove this number, you can see that result still gets inferred properly. That's because TypeScript is smart enough to understand that this returns a string.  
  
[0:47] The question is, should we add the return type or should we not? Most of the time, you should not be using return types. In simple functions like makeId, TypeScript knows what you're returning. You don't need to tell it something that it already knows. This return type ends up just being extra code that you need to maintain.  
  
[1:04] The rule of thumb should be not to use return types and let TypeScript infer the result on its own. This changes, though, when you have multiple branches inside your function. What do I mean by a branch? Let's imagine we have a function called handleNewState where we're taking in two different types of events. We have a window focused event and a window blurred event.  
  
[1:22] This handleNewState function is going to return a new state based on the event that's been passed. In window blurred, we return one state. In window focused, we return another state. Let's take a look at the new state that we get when we handle the window blurred event.  
  
[1:35] This new state is pretty messy. We've got what looks like latestUpdate with an uppercase U and latestupdate with a lowercase u defined here. This looks really, really fishy to me. The only things that we intended to return were isFocused Boolean and latestUpdate number. Let's create a new type that describes that.  
  
[1:52] Now we'll mark handleNewState return type as state. You can see that in one of the branches here, latestupdate is with a lowercase. We can fix that by changing it to uppercase. Because of this return type, we're now sure that handleNewState will return what we want it to.  
  
[2:04] If we add a new event called window closed, then we can be sure that this function still returns what we want it to, making this code easier to extend. If you have more than one branch in your function, then you should be using a return type. That means an if statement. That means a switch statement. That probably also means a ternary as well.  
  
[2:22] By default, don't require your devs to mark every function with a return type. There's an ESLint rule for that, and it's my least favorite one. I hate it. Some devs in some projects have it turned on. There is an exception to this, though. If you're writing library code, you should always declare return types.  
  
[2:38] Let's say that we wanted to bundle our handleNewState function into a library. We should add an export to every type that that function consumes. Let's say we're inside an application that wants to consume from this library. We can create a function called wrapHandleNewState, which just takes handleNewState and passes an event to it.  
  
[2:54] The issue is, how do we type this event? We can just use the type that we get from the library. If we want to handle our own logic inside here, then we probably also want to add a state return type here, too. This means that consumers of your library can use the types that you've used to type your functions.  
  
[3:10] There's also some stuff in the TypeScript Performance Wiki about libraries using return types. If, as a library, you use return types, you're going to see a faster bundle speed, because these types are easier to emit from TypeScript than anonymous ones.  
  
[3:22] For the folks saying, "I use TypeScript return types because of performance," that's really only for when you're printing declaration files in a library setting, which is a legit use case, but it doesn't really map up to application code.  
  
[3:34] I have been proved wrong on that point before. I've had people bring to me TypeScript performance problems where just a return type was the solution for some magical reason. If you're getting some really, really slow TypeScript compilation in your application, you may want to consider adding return types if the return type is really, really complicated.  
  
[3:53] To sum up, in application code, don't by default use return types. Use them if your function has multiple branches. Use them if you're writing a library, definitely. Use them if you have any weird niche performance concerns to do with really big objects being passed and inferred through your code. You can turn that ESLint rule off that forces you to have return types, please.

Here are my top 4 rules for how to name your types.

**Never pluralize**: Unless your type is an array type, you should make it singular - even if it's a union of members.

**Casing**: Choose a different casing between your values and your types. This helps stop syntax highlighting getting confused.

**Type Parameters**: prefix your type arguments with T. If you've got only one type argument, you can use T. Otherwise, be more descriptive with your parameter names.

**Avoid Unnecessary Prefixes**: Prefixes like `IUser` and `TOrganization` might feel useful, but they're mostly just holdovers from the Java days.

How to name your types in TypeScript can be a tricky business. Matt takes you through his opinionated heuristics for how to decide.

How to Name your Types

Matt Pocock: [0:00] What's up, wizards? Today, we're going to be looking at how you should name your types. Every time you create a type, you're going to have to be thinking, "What do I name this? What rules do I use?" I've got a bunch of little heuristics that I use when I'm naming types, and I'm going to show you some optional stuff that you can maybe adopt if you want to.  
  
[0:14] The first rule is never pluralize. Let's imagine that we've got a union type like this. We have three routes, user, admin/user, and admin. It feels natural, because these are a collection of routes, to name it routes. Let's imagine that we have a function called goToRoute. This route parameter here only ever represents one route, and so we've got this weird mismatch between the routes and the route.  
  
[0:34] If you think about it, this union type up here only ever represents one route. Sure, these are a collection of different routes, but really, it's only describing the possibility of a single route. The correct way to name these is route, not routes.  
  
[0:47] Let's imagine that we had to make an array of these routes. You can define it as route array, like this. If this was written as routes array, it sort of reads OK, but it kind of indicates that maybe routes is itself an array. Naming everything as a singular is a lot cleaner.  
  
[1:01] If you wanted to, you could turn routes into an array itself. Now, routes represents an array of route. This, I think, is pretty clean too. There you go. Rule number one, make sure everything is singular except for array types. Yes, in the king's English, it's pronounced root, not rout, you heathens.  
  
[1:18] Next up, always use a different case between your variables and your types. Let's go back to our goToRoute example. It is perfectly valid to rename this as lowercase. Because TypeScript understands that this route is on the runtime and this route is on the type level, it doesn't conflict.  
  
[1:32] You can even declare a variable in the same scope as the route, but here you can see that the syntax highlight starts getting confused. If we change this back to Pascal case, you can see that the syntax highlighting on the variable now looks correct.  
  
[1:43] It works in reverse too. If I name this uppercase Route, then it turns green. Where you can, you should use a different casing for your variables and your types.  
  
[1:50] Let's look at generic type parameters now. Let's imagine that I've got this generic type called response. We have a data in T and we have an error, which is always an error. For simple types like this, I will generally keep this as a single letter T, but changing it to TData is also perfectly valid.  
  
[2:05] In general, I'll always prefix it with a T because data doesn't look like a generic to me, so T or TData are both perfectly valid. One place I will never use T is if this contains multiple type arguments. This T, U thing up here is actually a convention. You can keep going T, U, V, etc, but here, it starts to look like pure maths instead of maintainable code.  
  
[2:26] What I prefer to do is rename this as TError and this one as TData. This means that the signature of the type is a lot easier to read. You may want to be a bit stricter and force your team to give these more descriptive names. That's totally fine too. For me, as long as they're prefixed with T or they are T itself, then it's fine, but T, U, V, W, X, Y Z, that can go to hell.  
  
[2:44] This final one is one that I don't really recommend that you do. Let's imagine that we have two types here. We have a user type and an organization interface here. In some places, I will see people at TUser and IOrganization. This indicates that this is a type and this is an interface.  
  
[2:59] I don't really see the point in this, especially not if you're using I and T here. It seems strange. If you eventually want to change this over to a type, then you'll also need to change the name and everywhere it's used. I don't see what benefit you're getting from seeing it's an interface from the name.  
  
[3:13] I think this is another convention carried over from the Java days. Personally, I don't see why it's still relevant. You can just hover over the name of the thing to figure out if it's an interface or a type anyway.  
  
[3:22] There you go, folks. Those are my rules for how to name your types. Keep things singular. Use a different case from your variables. Prefix type arguments with T, and be sensible. Hopefully, you know that one already.  
  
[3:34] Thanks for watching, folks. I have a beginner's TypeScript tutorial that is free on totaltypescript.com. It is an absolute banger. It will take you through everything you need to know in order to get a job with TypeScript. Go and check it out.  
  
[3:45] I'll have another video that you can watch here and a little face that you can subscribe to here. What did you think of this video? What rules did I miss? What do you do in your team that you think is a little bit weird? What do you want me to diagnose next? What should I make a video on next? Too many questions. I'll see you very soon.

TypeScript 5.1 unblocks React Server components, brings some nice usability updates to functions returning undefined, and some perf improvements.

TypeScript 5.1 is out! With important updates to React Server Components and some small usability updates.

TypeScript 5.1 Beta is OUT!

[0:00] What's up, Wizards? The TypeScript 5.1 Beta is out. My neighbors are building something in their back garden, so apologies for the noise, but I have to get this out right now. There are two main things that come from this release. The first one is undefined-returning functions.  
  
[0:14] Functions that don't return anything in JavaScript just return undefined. In TypeScript, they're inferred as void. This one here, for instance, this function that's just returning absolutely nothing, is inferred as a function with no parameters that just returns void.  
  
[0:28] What if the type of the function that you're passing in or the type that's expected actually returns undefined? This, currently, in TypeScript 5., will be an error. There are a bunch of these different cases here. This actually makes it less usable than you expect.  
  
[0:42] Now, in TypeScript 5.1, it would just be absolutely fine. TypeScript has now got its ideas or got the right idea into his head, that functions that return nothing actually return undefined. I think it will still infer it as void, but it will just loosen up that little bit of tightness and restriction that it previously placed on it.  
  
[1:03] This is the big headline item, decoupled type-checking between JSX elements and JSX tag types. What does that mean? They unblocked React Server Components. React Server Components broke some of the assumptions that TypeScript had previously made about components in React.  
  
[1:21] You would previously have thought that components could basically only be a function that is a sync function, not that returns a promise or anything, that just returns some JSX or perhaps , but React Server Components can use async functions.  
  
[1:37] Foo, it's basically like here, if you have...Oh God. The syntax highlighting in dark mode is awful. They've got async function Foo returns div. It basically says, "Foo cannot be used as a JSX component. Its return type Promise Element is not a valid JSX element."  
  
[1:53] Now, TypeScript has gotten smarter, so that you can actually specify the types that are allowed as an ElementType. Inside this global JSX namespace, you can specify ElementType and add all of the different ones to a union. This one, keyof IntrinsicAttributes, this is like div, span, a, whatever. We've got function. Components. We've got class components.  
  
[2:12] Now, when you ship React Server Components or you adopt them, React types can specify that promises are allowed. This means that React or TypeScript 5.1 is an absolute must upgrade for anyone using React. I've been testing it on Total TypeScript. It seems to be absolutely fine. You should be trying it out by installing the beta here and telling them if you run into any issues.  
  
[2:37] Otherwise, you should check out this next video that I've got here, which is another little tiny tip on all the cool things happening in the TypeScript ecosystem. I've been Matt. You should check out my TypeScript course on totaltypescript.com. I will see you very soon.

Understand how Type Predicates work in TypeScript, using an example of filtering a mixed array of elements.