In this exercise, we will review a couple things we learned about identity functions.

 function takes an array of fruits, each with a name and a price, and returns an object with a 

 function takes in the fruit name and returns the fruit object that matches the name:

 in VS Code, we should expect autocomplete to display either "banana" or "apple", which are the available fruit names.

As seen in the tests, it should not be possible to pass in an unknown fruit.

Also, the expected return type should be the exact same type as the input, including the 

Your challenge is to update the code so the tests pass as expected.

To do this, you will need to figure out the types for the 

You'll need to use generics, and may find 

Practice typing a TypeScript wrapper function for a fruit array that returns a fruit object based on name. Use generics and ts-toolbelt

Let's start by capturing what we get inside the 

 , and then create an array called fruits that's going to be a 

 function relies on the inferred literal value of the 

This is a bit tricky because we are not currently inferring from the deeply inferred literals here.

 to create a union of the members of the 

 array which is inferred to their literals:

 is like a discriminated union that always has a 

 property that can be indexed and extracted. 

For example, we could create a `Whatever` union and extract the names into a `Discriminator` that supports autocomplete.

While things are working, we have an issue with 

 slightly wrong, which is blowing out its internals into our type signature:

 method at the highest possible level instead of being inside an array.

This means that we need to have a plural 

 variable will be inferred properly as a tuple with 

, but fruit is now being inferred properly.

Also now instead of capturing just the individual members of 

 inside a type argument, we now capture the entire thing and end up with a tuple with all the members inside it.

This means our discriminated union trick to extract names won't work anymore.

In order to extract the members of the fruit, we'll add 

In order to get the specific thing that comes back, the 

For the return type, we'll need to go inside of 

 and extract a member from the union that matches an object with the name we've just inferred.

In order to break down what's happening in `getFruit`, let's create a `Fruits` type with names and prices for an apple and banana:

, we'll end up with a union type of all members:

 to pull out the member with a name of "apple", we'll see just that member:

This is the logic that we are using in our generic function.

If you're ever deep into a generic type, try extracting it and messing around with it!

Even though the tests are passing, there is one last error in getFruit:

Type Fruit | undefined is not assignable to Extract<TFruits[number]>... 

We get this error because we're doing something clever with TypeScript, where we know that we're going to be able to get the thing that's passed in by name and returning something that's never going to be undefined.

This is great for users, but TypeScript doesn't understand it.

To fix this, we can add `as` before our `Extract` in the return.

Then we can simplify the code further by deleting the return type. This will keep our inference, even with only one source of truth.

That was a lot! Let's summarize our solution.

First we use an outer generic to represent the entire array of fruits, and use 

Finally we do this same process runtime inside the type level to extract out 

Narrowing with Arrays and Generics

 Let's do this. We know that we're going to need to capture the thing that we get inside wrapFruit in some sort of generic. Let's do that first. We're going to say, "TFruit." I'm not going to put a constraint on it yet. Let's just say fruits is going to be TFruit array.

 Now what we've got here is we've got wrapFruit. This has been captured in name string, price number. We don't quite have enough information here because fruits currently could be anything. TFruit could be a string, could be a number, could be unknown, whatever. It doesn't have a name property on it.

 We need to say, "TFruit extends Fruit." Now we know that Fruit is going to be...It's going to have a name property. It's going to have a price property as well. That's going pretty well.

 Now we need to figure out this getFruit thing. getFruit, it's going to rely on the exact inferred literal value of the name property of all of these, like of TFruit here. This gets tricky because we're not currently inferring the deep inferred literals here. We're just grabbing -- what is it -- name string and price number.

 Let's do that. We can do that with F.Narrow. If we say, "import from ts-tool belt" -- let's grab the F -- now we can say...On here, we're going to say, "F.Narrow TFruit." This is good because what we get here is we get a union of the members of the array, which is inferred to their literals.

 That's really, really useful because what we can do now is we can then say this name is going to be TFruit name. Very, very cool. This TFruit name, TFruit is now basically a discriminated union that always has a name property on it. What that means is we can index into it and just grab out the name property from that union.

 If I copy this out and if I say, "type Whatever =" this...I can say type, let's say, Discriminator is Whatever. Then I index into it and get the name. By doing that, I end up with apple or banana here. If I change one of these to orange, then I get orange or banana instead. That's really good. I now get autocomplete based on the things that I pass in to the fruits.

 There's a weird issue with this though, which is with fruit.name here, you can see that fruit is like, "Oh my God. What is this type signature? Something really crazy is going on here." What we're looking at here is actually the internals of F.Narrow. F.Narrow is being blown out, beyond its boundaries. That's because we're using it slightly wrong.

 What we should be doing here is F.Narrow should actually be applied at the highest possible level. You shouldn't be doing F.Narrow TFruit inside an array and then putting that inside an array. I think what we're going to need to do instead is say TFruits extends an array of Fruit. Then the fruits here is going to be F.Narrow TFruits.

 Now what happens is we've got an error here, but fruit is now inferred properly. This is going to be name string, price number. This is a good tip with F.Narrow, is to always apply it at the top level. Don't be doing like -- I don't know -- obj, whatever, something, and then F.Narrow inside here. It might not work very well, or at least it doesn't work very well when it comes to arrays.

 Now, instead of capturing the individual members of the Fruit inside the type argument, we're now capturing the entire thing. You see that. It's now a tuple with all of the members inside it. This discriminated union trick no longer works.

 What we need to do first is extract out the members here. We can do that with number. TFruit is not going to be TFruit, but TFruits, so TFruits number name. Now e get our beautiful inference back, where we can say, "apple, banana." That's working great, except that the thing that we're getting back isn't very happy. It's still typed as unknown.

 What we're going to need to do is, because we need to grab the specific thing that comes back, we're going to need to actually make this a generic function again. getFruit itself is going to be generic because we need to capture the thing that's being passed in here. Let's say we've got TName. That's going to extend this constraint. Let's do that now. Then name is TName.

 Now, when we go down here, then getFruit is being captured inside that. That's great. apple is being captured. banana is being captured. Fabulous.

 Now we need to figure out this return type. The return type is going to be...We're basically going to need to go inside TFruits number and extract out a member from that union that matches an object with the name that we've just inferred. The way to do that is with an extract. We can Extract TFruits number and then name TName.

 What? Let's actually just break this down a little bit. We can say type Fruits is going to be...I'm going to just grab the thing that's being inferred from here. This is a nice little way to do it. We've got our fruits then. Now what we can do is we can say, "type Result =." We're going to Extract. Actually, we'll just call it, "Fruits number." This ends up as a union type of all of the members.

 Now what we can do is we can Extract from there name and, let's say, apple. Now what we end up with is apple, price 1. If we change this to banana, then we end up with banana, price 2. Beautiful. That's the logic that we're going to be using inside our generic function.

 Great tip, by the way. If you're ever deep in the rabbit hole with a generic type and you need to just pull it out, just see what's being inferred, pull it out into its own types, and mess about with it.

 This is now working beautifully because banana is being inferred as name banana, price 2, and name apple, price one. All our tests are passing, except that there's an error inside here.

 What's the error? Type Fruit or undefined is not assignable to Extract TFruits number name, name, name. We're doing something really, really clever with TypeScript, which is we're saying we know that the thing that's being passed in, we're going to be able to get it by name.

 We're then returning something that's never going to be undefined. It's always going to be the thing that we're passing in. That's going to be really nice for our users to use, but TypeScript doesn't really get it.

 We could say, "as" this. In fact, that works really nicely. There we go. What I like to do in these situations where I'm doing an as which is exactly the same as the return type, I just like to delete the return type. This means that you only need to have one single source of truth here. It means that TypeScript infers this properly, and our inference is still really good.

 We're using an as here because we know a little bit better than TypeScript what's going on. We're forcing it to basically say this is the thing that we understand it to be. We know better than you, TS. Hopefully, that makes sense as an explanation.

 We have an outer generic that we use to represent the entire array of Fruit. We use F.Narrow on that to grab out the values. We use a generic on getFruit itself, based on the name. We use the name in the argument itself.

 Then we do a find. Then we basically do the find on the Extract here as well. We're replicating the runtime inside the type level to Extract out TFruits number and pull out the name there.

Narrowing with an Array

 In this exercise, we're going to review a couple of things we learned in the identity functions module. We have this wrapFruit function. It takes in an array of fruits here, which each have a name and a price.

 What we're going to do is we're going to say when we call this function, we're going to get back an object which has getFruit on it. This is going to be a method that takes in name unknown and returns unknown, currently, but it finds the fruit which has the same name as the one that you passed in.

 What we're doing here is we're saying, "fruits.getFruit." We're expecting autocomplete here. When we say like...It should say banana or apple because we've got apple or banana being mixed in here. We shouldn't be able to pass in something that isn't allowed here, so something that's not been specified there.

 In these tests, the thing that's returned here should be the exact type that we passed in here, so literals and all, so like name apple, price 1, instead of it being name string, price number, let's say.

 That's your challenge, is to work out how you can figure out the types for this and how you can type this getFruit function. You're definitely going to need some generics here. You might need something from the ts-toolbelt library. Good luck.

The Advanced Patterns workshop is a primer on several patterns that emerge from TypeScript's primitives. We'll build on the generics and type transformations work we've done so far - extracting methods for architecting them into novel solutions.

Most of these patterns aren't documented by TypeScript - they've been discovered and iterated on by the TypeScript community. Each section focuses on a different pattern via interactive exercises.

This workshop is not appropriate for beginners.

Branded types (sometimes known as nominal types) let you break the rules of TypeScript by 'naming' types. This opens up a 

 of possibilities for using the type system to ensure your app's logic is robust.

The often-feared global scope is a necessary part of most applications. Whether you're importing a library via CDN that attaches to 

, or relying on environment variables, you'll need to know how to strongly type the global scope.

Type predicates and assertion functions give you the power to customize TypeScript's control flow. When used in combination with 

 statements, they can help improve inference and make your code easier to reason about.

This section builds on the Generics work we did in the previous workshop. We'll use classes and generics to perform ridiculous feats of inference - building up entire data structures in TypeScript without a single type annotation from the user.

Diving into external libraries is extremely complex. But it's often necessary to debug complicated type errors. Understanding the flow of generics through an external library can be critical to quickly fixing red lines. We'll look at several popular libraries.

Sometimes in TypeScript, you just need a function. Some generic inference isn't possible without an identity function. We'll learn when and where to use them, as well as some powerful type helpers to assist their inference.

Advanced Patterns Workshop

Take your coding skills to the next level with this workshop and learn how to use type predicates, assertion functions, branded types, and more.

Advanced Workshop Welcome 

Branded types allow us to enforce certain logic on the type level so we can write safer code and impose constraints that aren't available in regular TypeScript.

What is a Branded Type?

Branded types can validate raw value data into types that will be correct no matter where they are passed in your application.

Assigning Branded Types to Values

Form Validation with Branded Types

Branded types can be used to confidently fetch data of a specific type. This is great for working with complicated data structures.

Add Branded Types to Functions and  Models

Using Branded Types as Entity Id’s

Using type helpers along with branded types provides a more reusable way of marking things as valid or invalid.

Combine Type Helpers with Branded Types

Creating Reusable Validity Checks with Branded Types and Type Helpers

Unit tests are great, but adding branded types provides another way to test validity on the type level.

Using Branded Types to Validate Code Logic

Creating Validation Boundaries with Branded Types

Here you'll learn an interesting property present when combining index signatures and branded types. 

Indexing an Object with Branded Types

Using Index Signatures with Branded Types

Covers three patterns used by the TypeScript community.

Nominal Typing from Basarat's TypeScript Deep Dive

How opaque types in Flow and TypeScript can make your code better, faster, more secure and easier to refactor.

Stronger JavaScript with Opaque Types by Charles Pick

Reference unique symbols in the TypeScript Handbook

unique symbol from the TypeScript Docs

Refresh yourself on type helpers with the Type Helpers section of the Type Transformations workshop.

Type Helpers from Total TypeScripts

Reference for Index Signatures in the TypeScript Handbook

Index Signatures from the TypeScript Docs

Branded Types

Functions in global scope can be accessed across projects. Use them carefully, as globals should be avoided when possible.

Add a Function to the Global Scope

TypeScript's Global Scope

It is possible to add functionality to existing TypeScript globals by taking advantage of declaration merging.

Use Declaration Merging to Add Functionality to the Global Window

Add Functionality to Existing Global Interfaces

Adding types to properties of global interfaces allows for autocompletion across your  project's files, even when they are within namespaces.

Typing process.env in the NodeJS Namespace

Add Types to Properties of Global Namespaced Interfaces

Globals can be used to communicate between files that don't necessarily import or export to each other. 

Solving the Colocation Problem with Globals

Colocating Types for Global Interfaces

A reference for Global Declarations in the TypeScript Handbook

Global Declarations from the TypeScript Docs

A reference for Declaration Merging in the TypeScript Handbook

Declaration Merging from the TypeScript Docs

See where window is declared in TypeScript's definition file for the DOM.

lib.dom.d.ts in the TypeScript Source on GitHub

The TypeScript definition file for the Node.js process object.

process.d.ts from @types/node on GitHub

Globals

Type predicates provide a useful way for ensuring types are what we expect them to be. 

Use a Type Predicate to Filter Types

Filtering with Type Predicates

Assertion functions make sure if types are valid or assignable to other types. They are great for writing clever checks.

Ensure Valid Types with an Assertion Function

Checking Types with Assertion Functions

There is a gotcha to assertion functions that can lead to TypeScript worst error message. Luckily, it's easy to avoid once you know the rule.

Declare Assertion Functions Properly to Avoid Confusing Errors

Avoiding TypeScript's Most Confusing Error 

Generics and type predicates make a powerful combination for getting good inference from TypeScript.

Filtering with Type Predicates and Generics

Combining Type Predicates with Generics

Using brands with type predicates provide an alternative to assertions, casting, and other type adjustments when checking for validity.

Checking for Validity with Brands and Type Predicates

Combining Brands and Type Predicates

Using brands with assertions produces a nice validation API with readable error messages.

Validate Types with Brands and Assertions

Combining Brands with Assertion Functions

Reference Type Predicates in the TypeScript Handbook

Type Predicates from the TypeScript Docs

Reference Assertion Functions in the TypeScript Handbook

Assertion Functions from the TypeScript Docs

Type Predicates and Assertion Functions

TypeScript allows for classes to be used as types or values. They are able to cross the boundary between the runtime world and the type world.

Using Classes in TypeScript

Classes as Types and Values

Learn how to use type predicates in TypeScript classes to improve type safety and streamline your code.

Type predicates can simplify your TypeScript code and make it more maintainable.

Simplifying TypeScript with Type Predicates

Dive into Classes with Type Predicates 

Type predicates and assertion functions can bring amazing inference to classes in TypeScript.

Leverage Assertion Functions for Better Inference in Classes

Assertion Functions and Classes

The builder pattern provides a powerful way to construct APIs that fit nicely with TypeScript.

Class Implementation Following the Builder Pattern

Alex, the creator of the TRPC library, walks through an example of the builder pattern.

TRPC's Creator on the Builder Pattern

The builder pattern can be used to remove unknowns and add type safety and  autocompletion by building upon generics.

Getters and Setters in the Builder Pattern

Create a Type Safe Map with the Builder Pattern

One small change can drastically change the behavior of your code and lose your type safety.

Default Generics in the Builder Pattern

Debugging the Builder Pattern

Combining generics with the builder pattern allows you to create chainable functions that work through dynamic inference of inputs and outputs.

The Power of Generics and the Builder Pattern

Building Chainable Middleware with the Builder Pattern

Colin, the creator of Zod, presents examples of subclassing in the library.

Subclassing in Zod

Build high-performance, scalable, and easy-to-use APIs for your applications.

TRPC's Documentation

Classes

Orta Therox, a former member of the core TypeScript team,  discusses how types that you don't define can make their way into your application code.

Where Do External Types Come From?

With some clever type transformations it's possible to extract and extend types from an external library that you don't control.

Retrieve Function Parameters from an External Library

Extract Types to Extend an External Library

Navigating Lodash's Type Definitions

It's important to use proper type arguments and generics when using library functions. Let's practice type definitions to determine what to use and their order.

Transcript

Narrowing with an Array

Transcript