I've made a small alteration to this file based on the previous exercise's solution, and now the code is not working as expected:

```typescript
class TypeSafeStringMap<TMap extends Record<string, string>> {
  private map: TMap;
  constructor() {
    this.map = {} as TMap;
  }

  get(key: keyof TMap): string {
    return this.map[key];
  }

  set<K extends string>(
    key: K,
    value: string,
  ): TypeSafeStringMap<TMap & Record<K, string>> {
    (this.map[key] as any) = value;

    return this;
  }
}
```

The `set` function still has a return type of `TypeSafeStringMap<TMap & Record<K, string>`, but autocomplete doesn't work inside of `get`.

## Challenge

You need to find the breaking change inside of the `TypeSafeStringMap` class, and fix it.

Hint: There's only a few characters difference. Look at the type level, not the runtime level!

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

The thing I removed was the default generic from the `TypeSafeStringMap`.

## Without the Default Generic

Without the default of an empty object, hovering over the `new TypeSafeStringMap` in the example `map` shows us this:

```typescript
constructor TypeSafeStringMap<Record<string, string>>(): TypeSafeStringMap<Record<string, string>> 
```

If we call `.set("matt", "pocock")`, we'll end up with `Record<string, string>` and `Record<"matt", string>` being generated:

```typescript
// hovering over set
const map = new TypeSafeStringMap().set("matt", "pocock")

// shows
(method) TypeSafeStringMap<Record<string, string>>(key: "matt", value: string): TypeSafeStringMap<Record<string, string> & Record<"matt", string>>
```

Because the `get` has a key of `keyof TMap`, and the default of `TMap` is a `Record<string, string>`, we lose the `"matt"`.

```typescript
get(key: keyof TMap): string {
  return this.map[key];
}
```

This means the `get` does not have type safety.

## Adding the Default Empty Object

To fix this issue, the class needs a default generic of an empty object.

Here's what it should look like:

```typescript
class TypeSafeStringMap<TMap extends Record<string, string> = {}> {
  private map: TMap;
  ...
```

Now when we we hover over the `TypeSafeStringMap` from the map, the first thing we'll see is the empty object:

```typescript
// hovering over `TypeSafeStringMap
const map = new TypeSafeStringMap().set("matt", "pocock")

// shows
constructor TypeSafeStringMap<{}>(): TypeSafeStringMap<{}>
```

With the empty object, if we don't `set` anything then calling the `get` method will be `key: never`.

```typescript
// hovering over get
const result = map.get("");

// shows
(method) TypeSafeStringMap<{}>.get(key: never): string
```

The `keyof` an empty object is `never`, but would lose to a `keyof` of other types like string.

For example, if we had this `Example`:

```typescript
type Example = keyof {} | keyof { matt: string }; 
```

The type would return in `type Example = "matt"`.

If we added an additional type to the `Example`, the `never` disappears from the union:

```typescript
type Example = keyof {} | keyof { matt: string } | keyof {brandi: string};

// results in
type Example = "matt" | "brandi"
```

This exercise shows the importance of the default generic for giving the building pattern a type safe place to start from.

Be sure to add a default when using the pattern, as it can be tricky to debug!

Default Generics in the Builder Pattern

0:01 The thing that I changed was I changed this default generic. In other words, I removed it. When I removed it, some interesting things happened.

0:12 We have this map here. If I just remove all of this guff here, this map is now typed as TypeSafeStringMap and the default is Record, string, string. When you don't provide a default, it defaults to this. Now, this type here is tricky, because what we can do is we can set('matt', 'pocock') again.

0:34 This, what it ends up with is Record, string, string and Record, "matt", string. What this means is because keyof TMap is being called here. What you get is, if we say, const result = map.get. Let's say, blah blah blah. The key is typed as string.

0:59 If we have type, let's say, Example = 'matt' or string, then this is going to be resolved as string. The matt disappears inside here. Because get(key: keyof TMap) and the default is a Record string, that little string just there ruins the whole thing, because it means that we don't get typesafety on the get.

1:28 The way to solve this is by adding back that default generic. Now, the first thing that's here will be an empty object. Meaning that, if we don't set anything, then this will be never. This method will be key never because if we look at type Example = keyof this, the keyof empty object is never.

1:55 When you have like this or keyof { matt: string }, for instance, then that's going to win out. The never is going to disappear from the union and you end up with matt here, keyof this. If we go, keyof { brandi: string }, then brandi is going to be added to the thing as well.

2:24 This is basically the importance of this default generic. It gives your builder pattern a TypeSafe place to start. It means that you have to be really, really careful, because that error is pretty hard to debug and it shows how important this default generic is.

Debugging the Builder Pattern

0:00 I've made a small alteration to this file based on the previous exercise's solution. It's basically exactly the same, but I've made a small error and now it's not working anymore. Now we're getting map is record string string and record string.

0:19 We're not getting autocomplete inside Get anymore even though the set thing looks completely fine. Your job is to work out how I've broken this class here. It's only at the type level. I haven't changed much. In fact, it's only like three or four character's difference.

0:38 Good luck debugging this.

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.



Intermediate to advanced workshop: Boost app logic, type global scopes, and debug with external libraries.

Advanced Patterns Workshop

Total TypeScript Complete Volume is a set of five full TypeScript workshops for the advanced-beginner to expert professional TypeScript programmer that wants to take their skills to the next level. This bundle includes all of the Total TypeScript self-paced workshops.

TypeScript Pro Essentials

Type Transformations

TypeScript Generics

Advanced TypeScript Patterns

Advanced React with TypeScript

TypeScript Expert Interviews

TypeScript Pro Complete

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

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.

Passing Type Arguments with Lodash

Finding Proper Type Arguments and Generics with Lodash

The Express types from Definitely Typed ensure that the REST APIs you build are generic and type safe.

Navigating Express's Type Definitions

By making a request function generic, we can effectively handle the query params.

Make an Express Request Function Generic

Add Query Params to an Express Request

Zod is a TypeScript library created with the goal of validating data types. Let's read through its type definitions to better understand the flow of generics.

Browsing Zod's Types

Using Zod allows you to create functions that are both runtime and type safe. This lets you accept different types of input without the need for casting.

Infer Runtime Arguments from a Zod Schema

Create a Runtime and Type Safe Function with Generics and Zod

Sometimes you need to add or override types from an external library. This can be done by using a declaration file.

Create a Declarations File to Override Types

Override External Library Types

The Lodash common module in the DefinitelyTyped repository.

Lodash Types from Definitely Typed on GitHub

See how types are defined for the popular library Express in the DefinitelyTyped project. 

Express Types from Definitely Typed on GitHub

See how the types for Arrays are defined in TypeScript's own source code.

Array from TypeScript's Types on GitHub

Build a deeper expertise with Zod in this free tutorial here on Total TypeScript.

Zod Tutorial on Total TypeScript

See how the Zod library defines its own types.

Zod's Types on GitHub

External Libraries

as const asserts type, but isn't always available. Identity functions with F.Narrow from ts-toolbelt improve inference in these cases.





Using const type parameters For Better Inference

Identity Functions as an Alternative to the `as const`

Constraining and Narrowing an Identity Function

Add Constraints to an Identity Function

Sometimes TypeScript infers when we don't want it to. The `NoInfer` type helps us avoid this problem.

Fix Inference Issues with the NoInfer Type

Specifying Where Inference Should Not Happen

Avoid Duplicate Code in an Identity Function with Generics

Find the Generic Flow of an Identity Function

Reverse mapped types allow changing inference in identity functions to infer from input, rather than output. Mind-bending, but cool!





Inference Inception in an Identity Function

Reverse Mapped Types

ts-toolbelt offers advanced utility types & functions for TypeScript that aren't available in the standard library, helping to write more type-safe code.








ts-toolbelt GitHub Repository

The Narrow utility type from ts-toolbelt can be helpful for narrowing union types in TypeScript, leading to more precise type checking.





F.Narrow from ts-toolbelt on GitHub

ts-toolbelt's NoInfer type prevents unwanted inference, leading to more precise and flexible type definitions in TypeScript.








F.NoInfer from ts-toolbelt on GitHub

TypeScript 5.0's const type parameters can be helpful for enforcing constant values in type definitions, leading to more reliable code.





Microsoft's announcement for TypeScript 5.0 Beta

Mapping over a union to create an object using TypeScript's mapped types can be helpful for generating complex types with ease and flexibility.





The Mapped Types Module of the Type Transformations Workshop

Identity Functions

Add Objects to the Global Scope Dynamically

Merge Dynamic Objects with Global Objects

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

Narrowing with Arrays and Generics

Narrowing with an Array

Type-Safe Request Handlers with Zod and Express

Create a Type-Safe Request Handler with Zod and Express

Dynamic Reducer with Generic Types

Building a Dynamic Reducer

 Explore React typings to add a custom element to JSX.IntrinsicElements, defining required props and children, and utilizing HTML props.

Transcript

Debugging the Builder Pattern

Transcript