Forem: typescript

Type | Treat 2021 - Wrap-up

Orta — Sat, 30 Oct 2021 14:31:39 +0000

Type | Treat Challenge Wrap-up

That's all the challenges done! If you missed any of the challenges they're all available in the Playground here. Let's talk through the final answers to day 5's challenges.

Yesterday's Solution

Beginner/Learner Challenge

In this challenge we were working with an existing object literal which had been as constd. The goal was to use keyof and typeof to extract interesting sets of strings from the object. The first being the keys in the object:

- type SchemeNames = "background" | "textColor" | "highlightOne"
+ type SchemaNames = keyof typeof scheme

Idealy you might have noticed the 'key of' in the comment, which could have led you to keyof, from there you needed to re-use typeof to extract the type from scheme. This gets all of the keys from that constant.

Next, we asked if you could improve

function possibleSchemeItems(colors: any): string[] {
    const keys = Object.keys(colors) as string[]
    return keys
}

In this case, you can switch string to SchemeNames - this example was made so that there was an interesting function to play around with. You could switch colors to typeof schema but nothing you do around Object.keys would keep the types retained. This is kind of interesting, the reasoning is that TypeScript cannot make reasonable guarantees that the return value of Object.keys actually is keyof typeof colors (because of JavaScript prototype chaining) and so you have to re-type that line. Interesting.

function possibleSchemeItems(colors: typeof scheme): SchemaNames[] {
    const keys = Object.keys(colors) as SchemaNames[]
    return keys
}

Next we had you figure out how to get the values of schema as a union:

- type PossibleColors = '#242424' | '#ffa52d' | '#cafe37'
+ type PossibleColors = typeof scheme[SchemaNames]

We tried to be quite explicit in the clue leading up to this one, because jumping to an indexed type might not be instinctive for beginners. This we considered to be the trickiest part of the challenge.

Then to wrap up the challenge, and to make sure the types you are creating are constructive in a real world-ish scenario, we presented a Record to see if you knew that the first parameter can be a list of keys:

- type Scheme = Record<string, string>;
+ type Scheme = Record<SchemaNames, string>;

Which would cause a compiler error with previousScheme - letting you know it worked.

Our answer

Intermediate/Advanced Challenge

For this challenge, we started with the type we wanted you to write, and then tried to find incremental steps which built up in complexity till you hit it.

The total change we were looking for was this:

function handleSale(events: Record<string, (e: Books) => void>) {
  // ... 
}

To:

function handleSale(events: { [Book in Books as `on${Book["genre"]}`]?: (e: Book) => void }) {
  // ... 
}

Getting there is a bit of a jump!

We first asked you to switch the string in the Record to be Books:

- function handleSale(events: Record<string, (e: Books) => void>) {
+ function handleSale(events: Record<keyof IncomingBookMap, (e: Books) => void>) {

The next step was to remove the Record and replace it with its underlaying mapped type:

- function handleSale(events: Record<string, (e: Books) => void>) {
+ function handleSale(events: { [Book in keyof IncomingBookMap]?: (e: Books) => void }) {

The ? being the key that if you searched the TypeScript documentation for "mapping modifier" you'd see the documentation around mapped types which we also improved in the process of making this challenge.

We thought that could be enough for some folk, and that was a good pausing point and thus classed the final change as a bonus. That jump revolved around using key remapping via as in the mapped type.

- function handleSale(events: { [Book in keyof IncomingBookMap]?: (e: Books) => void }) {
+ function handleSale(events: { [Book in Books as `on${Book["genre"]}`]?: (e: Book) => void }) {

The IncomingBookMap existed specifically to add the prefix on to the genre of each book, which is handled by template string literals. All of the documentation for these concepts are in the same page, so after a few reads it should hopefully all make sense.

This system is more or less how the DOM's event system works, and is what the idea is loosely based on, from lib.dom.d.ts:

interface DocumentAndElementEventHandlersEventMap {
    "copy": ClipboardEvent;
    "cut": ClipboardEvent;
    "paste": ClipboardEvent;
}

interface DocumentAndElementEventHandlers {
        addEventListener<K extends keyof DocumentAndElementEventHandlersEventMap>(type: K, listener: (this: DocumentAndElementEventHandlers, ev: DocumentAndElementEventHandlersEventMap[K]) => any, options?: boolean | AddEventListenerOptions): void;
}

Roughly translates to english as "DocumentAndElementEventHandlersEventMap" shows how to handle document.addEventListener("copy", (evt) => { ... }) and what to map the first argument of that function to. The DOM types can't really switch to use a template literal because not all properties have an on prefix, but it's a pretty logical expansion of the idea in specific cases.

Our answer.

Thanks!

There are a few people involved in getting Types | Treat running whose name you don't see on the masthead: Gabriella and Daniel on the TypeScript team, and the folks in the TypeScript Community Discord - especially webstrand and michael. My wife, Danger, should probably also get a shout for helping to provide themes - we've done 40 challenges so far and have to dig pretty deep occasionally to be fun and topical.

Feedback

If you gave Types | Treat a shot, we love for you to run through our 6 question survey which help us figure out how to change and improve. Feedback on Twitter is useful, but there's only so much context you can gve in 280 characters!

From here?

If you've not done the 2020 Type | Treat, it's also good!

If you want to challenge yourself further, check out types-challenges this clever system of type challenges goes all the way up to "very challenging for the TypeScript team" and also run entirely in the TypeScript Playgound. It's great work.

Type | Treat 2021 - Day 5

Orta — Fri, 29 Oct 2021 19:59:59 +0000

Type | Treat Challenge 5

Welcome to the fifth, and last, Type | Treat challenge! These challenges are a series of blog posts which have 2 code challenges in, one for beginners and one for intermediate TypeScript programmers. We're on day five, which means going over the answers from yesterday and have 2 new challenges.

Yesterday's Solution

Beginner/Learner Challenge

This challenge aimed to be generics 101, first introducing the concept of making your function pass a type from the function to the argument:

-  function getBowl(items: any) {
+  function getBowl<T>(items: T) {
      return { items }
  }

The any acted as hint clue about where to look, and this example is almost the first code sample on the Generics chapter in the Handbook, so it felt like a good intro.

The second part involved understanding generic constraints, these are essential tools in helping you define the baselines for types which can be used in your function. In this case we didn't provide the word "constraints" but opted for a more cryptic clue by setting up the function most of the way, then saying you only needed two words:

-  function fillBowl<T>(candy: T) {
+  function fillBowl<T extends string>(candy: T) {
      return { candy }
  }

By saying that T extended string then the string literals are correctly passed through the function - which removes all the compiler errors.

Our answer

Intermediate/Advanced Challenge

The intermediate challenge also invovled generic constraints, so if you had just finished the beginner's then you were in a good place to figure this challenge. The key is to make a

- const check = (data: Competitor[]) => {
+ const check = <Type extends Competitor> (data: Type[]) => {
      return data.map(competitor => {
          if (competitor.weight > 2121.5) throw new Error("Stop the show, world record hit!")
          return { ...competitor, judge: (...args: unknown[]) => { } }
      })
  }

This is testing a few different things:

Writing generics with an arrow function
Using an extends constraint for the interface subtypes
Re-using the type parameter inside the array

We left a tricky problem with this challenge, but explicitly didn't call it out. The function judge: (...args: unknown[]) is a types gap. There is no validating that the judge function actually works like expected. There are two approaches for handling this:

- return { ...competitor, judge: (...args: unknown[]) => { } }
+ return { ...competitor, judge: (...args: Array<T[keyof T]>) => { } }

This version from @faridz974 would ensure that the right values were used in the function (e.g. you couldn't accidentally put in an object to something which could only accept string and numbers) but it ignored the order. An accurate, but whole-heartedly not recommended for production version which does take order into account comes from converting an interface to a tuple on GitHub which is a bit too long to print in here, but here's a working implementation in the playground.

Our answer.

The Challenge

Beginner/Learner Challenge

Update your website's color scheme for Halloween and tidy the codebase up a bit.

Intermediate/Advanced Challenge

Handle a book stores halloween discount event

How To Share Your Solution

Once you feel you have completed the challenge, you will need to select the Share button in the playground. This will automatically copy a playground URL to your clipboard.

Then either:

Go to Twitter, and create a tweet about the challenge, add the link to your code and mention the @TypeScript Twitter account with the hashtag #TypeOrTreat.
Leave us a comment with your feedback on the dev.to post, or in this post.

Best Resources for Additional Help

If you need additional help you can utilize the following:

The New TypeScript Handbook
The TypeScript Community Discord
The comments on each Dev.to post!
Our previous Type | Treat 2020 challenges

Happy Typing :)

Type | Treat 2021 - Day 3

Orta — Wed, 27 Oct 2021 20:25:16 +0000

Type | Treat Challenge 3

Welcome to the third Type | Treat challenge! These challenges are a series of blog posts which have 2 code challenges in, one for beginners and one for intermediate TypeScript programmers. We're on day three, which means going over the answers from yesterday and have 2 new challenges.

Yesterday's Solution

Beginner/Learner Challenge

There is many ways to decide how to type existing data, you could use literal types when you're sure of the exact formats - or be more liberal and use string when you expect a variety. We opted for literals, but using string is totally cool too.

type UnderripePumpkin = {
    color: "green",
    soundWhenHit: "dull thud"
}
type RipePumpkin = {
    color: "purple" | "orange" | "blue",
    soundWhenHit: "echo-y"
}
type OverripePumpkin = {
    color: "green" | "white",
    soundWhenHit: "squishy"
}

The second part of the challenge used type predicates (or type guards) annotates a function which returns a booleon with narrowing information about the paramters. This means we can tell TypeScript that when the return values to isRipeis true, then the argument pumpkin is of the type RipePumpkin:

- function isRipe(pumpkin: any) {
+ function isRipe(pumpkin: any): pumpkin is RipePumpkin {
       return "soundWhenHit" in pumpkin && pumpkin.soundWhenHit === "echo-y"
  }

Successfully completing this challenge would have no errors, and the type for.

Our answer.

Intermediate/Advanced Challenge

This challenge was first about understanding different read vs write properties available in both classes and interface/typed objects. Personally, I've seen this with document.location a lot where you always get a rich object when you read but can write to that property with a string. We wanted a similar concept, but using punch which for me is generally a 'throw it all in and see what happens' style of drink.

class PunchMixer {
  #punch: Punch = {flavour: '', ingredients: []};

  public get punch(): Punch {
      return this.#punch;
  }

  public set punch(punch: Punch | Punch['ingredients'][number]) {
      if (typeof punch === 'string') {
          this.#punch.ingredients.push(punch);
      } else if ('flavour' in punch) {
          this.#punch = punch;
      } else {
          this.#punch.ingredients.push(punch);
      }
  }
}

This solution uses a mix of private class fields, indexed types and type narrowing to set up a local punch object which is always returned.

The next step was to make this class generic in some form so that a type parameter passed in to the class would dictate what the return value of a vend function was.

- class PunchMixer {
+ class PunchMixer<MixerType> {
+    mixer!: MixerType;

  // ...
+   public vend(): MixerType {
+        return this.mixer;
+    }
  }

We were not too worried about how you passed back the MixerType - our first draft had return {} as MixerType but a private field feels nicer.

Our Answer.

The Challenge

Beginner/Learner Challenge

Figure out how to stop people giving you bad strings for your custom lengths.

Intermediate/Advanced Challenge

Stop losing your literals in Halloween posters

How To Share Your Solution

Once you feel you have completed the challenge, you will need to select the Share button in the playground. This will automatically copy a playground URL to your clipboard.

Then either:

Go to Twitter, and create a tweet about the challenge, add the link to your code and mention the @TypeScript Twitter account with the hashtag #TypeOrTreat.
Leave us a comment with your feedback on the dev.to post, or in this post.

Best Resources for Additional Help

If you need additional help you can utilize the following:

The New TypeScript Handbook
The TypeScript Community Discord
The comments on each Dev.to post!
Our previous Type | Treat 2020 challenges

Happy Typing :)

Type | Treat 2021 - Day 2

Orta — Tue, 26 Oct 2021 19:35:06 +0000

Type | Treat Challenge 2

Welcome to the second Type | Treat challenge! These challenges are a series of blog posts which have 2 code challenges in, one for beginners and one for intermediate TypeScript programmers. We're on day two, which means going over the answers from yesterday and 2 new challenges.

Yesterday's Solution

Beginner/Learner Challenge

The first part of the solution for this challenge used as const to trigger "Literal Inference" - basically telling TypeScript "Don't convert the array to string[] but consider it a constant set of string literals. This meant that playlist[0] stopped returning string and started returning "The Legend of Sleepy Hollow by The Monotones.mp3".

  const playlist = [
      "The Legend of Sleepy Hollow by The Monotones.mp3",
      ...
- ]
+ ] as const

The second part of the challenge used typeof types to extract the type from the playlist array. Without the first change, this would be string but after the change this meant the full array of different types. You then needed to use the type index syntax [number] to declare that you want any potential string from that array.

- function playSong(song: string) {
+ function playSong(song: typeof playlist[number]) {
      api.play(song)
  }

Successfully completing this challenge would raise an error in the final code samples due to a subtle typo.

Our answer.

Intermediate/Advanced Challenge

This pattern is quite common in code we write in TypeScript codebases, you create one function which takes the result of another and keeps passing objects between functions in a pipeline. One of the best techniques for simplifying this design pattern is to use ReturnType with typeof myFunc to map the return type of one function to the paramter of another. This removes the need for intermediary types which need to be updated when the functions change.

  const findOldCostume = () => {
      // ...
      return { jumpSuit, estimate }
  }

- const createNewMask = (costume: any) => {
+ const createNewMask = (costume: ReturnType<typeof findOldCostume>) => {
      // ...
      return { ...costume, mask }
  }

The little extra step at the end was a small reminder that you can use this technique to provide a type which can be re-used everywhere.

type Costume = ReturnType<typeof assembleCostume>

Our Answer.

The Challenge

Beginner/Learner Challenge

Help sort out a large array of pumpkins, and then get cooking soup.

Intermediate/Advanced Challenge

Fresh back from robotics camp, can you make the perfect punch mixer bot?

How To Share Your Solution

Once you feel you have completed the challenge, you will need to select the Share button in the playground. This will automatically copy a playground URL to your clipboard.

Then either:

Go to Twitter, and create a tweet about the challenge, add the link to your code and mention the @TypeScript Twitter account with the hashtag #TypeOrTreat.
Leave us a comment with your feedback on the dev.to post, or in this post.

Best Resources for Additional Help

If you need additional help you can utilize the following:

The New TypeScript Handbook
The TypeScript Community Discord
The comments on each Dev.to post!
Our previous Type | Treat 2020 challenges

Happy Typing :)

Type | Treat 2021 - Day 1

Orta — Tue, 26 Oct 2021 07:09:21 +0000

Type or Treat Challenges

Today we're starting up our second year of Type | Treat (or "Type or Treat".) We will be presenting some "spooky" code challenges that will allow you to dig deeper into the TypeScript language in a fun way.

Starting right now, a new code challenge will be posted every weekday, along with its solution the day after. The last solution will be posted on the weekend.

How To Participate

In order to participate you only need to be able to access the TypeScript website. Though ideally, you share with us your answers via our dev.to blog post mirrors, here, or via Twitter to @TypeScript.

You will want to start here on the blog to find the details on the code challenges for the day. Each post contains 2 links to different challenges which run in the TypeScript playground. Via the playground, you can work on the challenge in your browser and you will be able to test your code live to see if it properly passes the challenge.

How To Share Your Solution

Once you feel you have completed the challenge, you will need to select the Share button in the playground. This will automatically copy a playground URL to your clipboard.

Then either:

Go to Twitter, and create a tweet about the challenge, add the link to your code and mention the @TypeScript Twitter account with the hashtag #TypeOrTreat.
Leave us a comment with your feedback on the dev.to post, or in this post.

Best Resources for Additional Help

If you need additional help you can utilize the following:

The New TypeScript Handbook
The TypeScript Community Discord
The comments on each Dev.to post!
Our previous Type | Treat 2020 challenges

Day 1 Challenges

Beginner/Learner Challenge

Using the new music streaming service from the TypeScript team, Typify, set up and share your halloween playlist with your friends.

Head to this link and help us figure out the best type to use in one of our function parameters!

Intermediate/Advanced Challenge

You've figured out your costume, but making it is a bit of a process. Can you figure out how to make all of the parts come together in a type-safe way?

Head over to start sorting.

Announcing TypeScript 4.1

Daniel Rosenwasser — Sat, 21 Nov 2020 00:50:31 +0000

Today we're proud to release TypeScript 4.1!

If you're unfamiliar with TypeScript, it's a language that builds on JavaScript by adding syntax for type declarations and annotations. This syntax can be used by the TypeScript compiler to type-check our code, and then output clean readable JavaScript that runs on lots of different runtimes. Static type-checking can tell us about errors in our code before we even run it, or before we even save our files thanks to TypeScript's rich editing functionality across editors. But beyond error-checking, TypeScript powers things like completions, quick fixes, and refactorings for both TypeScript and JavaScript in some of your favorite editors. In fact, if you already use Visual Studio or Visual Studio Code, you might already be using TypeScript when you write JavaScript code!
So if you're interested in learning more, check out our website!

But if you're already using TypeScript in your project, you can either get it through NuGet or use npm with the following command:

npm install -D typescript

You can also get editor support by

Downloading for Visual Studio 2019/2017
Installing the Insiders Version of Visual Studio Code or following directions to use a newer version of TypeScript

For this release, we have some exciting new features, new checking flags, editor productivity updates, and speed improvements. Let's get a look at what 4.1 brings!

Template Literal Types
Key Remapping in Mapped Types
Recursive Conditional Types
--noUncheckedIndexedAccess
paths without baseUrl
checkJs Implies allowJs
React 17 JSX Factories
Editor Support for the JSDoc @see Tag
Breaking Changes

Template Literal Types

String literal types in TypeScript allow us to model functions and APIs that expect a set of specific strings.

function setVerticalAlignment(pos: "top" | "middle" | "bottom") {
    // ...
}

setVerticalAlignment("middel");
//                   ~~~~~~~~
// error: Argument of type '"middel"' is not assignable to
//        parameter of type '"top" | "middle" | "bottom"'.

This is pretty nice because string literal types can basically spell-check our string values.

We also like that string literals can be used as property names in mapped types. In this sense, they're also usable as building blocks.

type Options = {
    [K in "noImplicitAny" | "strictNullChecks" | "strictFunctionTypes"]?: boolean
};
// same as
//   type Options = {
//       noImplicitAny?: boolean,
//       strictNullChecks?: boolean,
//       strictFunctionTypes?: boolean
//   };

But there's another place that that string literal types could be used as building blocks: building other string literal types.

That's why TypeScript 4.1 brings the template literal string type. It has the same syntax as template literal strings in JavaScript, but is used in type positions. When you use it with concrete literal types, it produces a new string literal type by concatenating the contents.

type World = "world";

type Greeting = `hello ${World}`;
// same as
//   type Greeting = "hello world";

What happens when you have unions in substitution positions?
It produces the set of every possible string literal that could be represented by each union member.

type Color = "red" | "blue";
type Quantity = "one" | "two";

type SeussFish = `${Quantity | Color} fish`;
// same as
//   type SeussFish = "one fish" | "two fish"
//                  | "red fish" | "blue fish";

This can be used beyond cute examples in release notes. For example, several libraries for UI components have a way to specify both vertical and horizontal alignment in their APIs, often with both at once using a single string like "bottom-right". Between vertically aligning with "top", "middle", and "bottom", and horizontally aligning with "left", "center", and "right", there are 9 possible strings where each of the former strings is connected with each of the latter strings using a dash.

type VerticalAlignment = "top" | "middle" | "bottom";
type HorizontalAlignment = "left" | "center" | "right";

// Takes
//   | "top-left"    | "top-center"    | "top-right"
//   | "middle-left" | "middle-center" | "middle-right"
//   | "bottom-left" | "bottom-center" | "bottom-right"
declare function setAlignment(value: `${VerticalAlignment}-${HorizontalAlignment}`): void;

setAlignment("top-left");   // works!
setAlignment("top-middel"); // error!
setAlignment("top-pot");    // error! but good doughnuts if you're ever in Seattle

While there are lots of examples of this sort of API in the wild, this is still a bit of a toy example since we could write these out manually. In fact, for 9 strings, this is likely fine; but when you need a ton of strings, you should consider automatically generating them ahead of time to save work on every type-check (or just use string, which will be much simpler to comprehend).

Some of the real value comes from dynamically creating new string literals. For example, imagine a makeWatchedObject API that takes an object and produces a mostly identical object, but with a new on method to detect for changes to the properties.

let person = makeWatchedObject({
    firstName: "Homer",
    age: 42, // give-or-take
    location: "Springfield",
});

person.on("firstNameChanged", () => {
    console.log(`firstName was changed!`);
});

Notice that on listens on the event "firstNameChanged", not just "firstName". How would we type this?

type PropEventSource<T> = {
    on(eventName: `${string & keyof T}Changed`, callback: () => void): void;
};

/// Create a "watched object" with an 'on' method
/// so that you can watch for changes to properties.
declare function makeWatchedObject<T>(obj: T): T & PropEventSource<T>;

With this, we can build something that errors when we give the wrong property!

// error!
person.on("firstName", () => {
});

// error!
person.on("frstNameChanged", () => {
});

We can also do something special in template literal types: we can infer from substitution positions. We can make our last example generic to infer from parts of the eventName string to figure out the associated property.

type PropEventSource<T> = {
    on<K extends string & keyof T>
        (eventName: `${K}Changed`, callback: (newValue: T[K]) => void ): void;
};

declare function makeWatchedObject<T>(obj: T): T & PropEventSource<T>;

let person = makeWatchedObject({
    firstName: "Homer",
    age: 42,
    location: "Springfield",
});

// works! 'newName' is typed as 'string'
person.on("firstNameChanged", newName => {
    // 'newName' has the type of 'firstName'
    console.log(`new name is ${newName.toUpperCase()}`);
});

// works! 'newAge' is typed as 'number'
person.on("ageChanged", newAge => {
    if (newAge < 0) {
        console.log("warning! negative age");
    }
})

Here we made on into a generic method. When a user calls with the string "firstNameChanged', TypeScript will try to infer the right type for K. To do that, it will match K against the content prior to "Changed" and infer the string "firstName". Once TypeScript figures that out, the on method can fetch the type of firstName on the original object, which is string in this case. Similarly, when we call with "ageChanged", it finds the type for the property age which is number).

Inference can be combined in different ways, often to deconstruct strings, and reconstruct them in different ways. In fact, to help with modifying these string literal types, we've added a few new utility type aliases for modifying casing in letters (i.e. converting to lowercase and uppercase characters).

type EnthusiasticGreeting<T extends string> = `${Uppercase<T>}`

type HELLO = EnthusiasticGreeting<"hello">;
// same as
//   type HELLO = "HELLO";

The new type aliases are Uppercase, Lowercase, Capitalize and Uncapitalize. The first two transform every character in a string, and the latter two transform only the first character in a string.

For more details, see the original pull request and the in-progress pull request to switch to type alias helpers.

Key Remapping in Mapped Types

Just as a refresher, a mapped type can create new object types based on arbitrary keys

type Options = {
    [K in "noImplicitAny" | "strictNullChecks" | "strictFunctionTypes"]?: boolean
};
// same as
//   type Options = {
//       noImplicitAny?: boolean,
//       strictNullChecks?: boolean,
//       strictFunctionTypes?: boolean
//   };

or new object types based on other object types.

/// 'Partial<T>' is the same as 'T', but with each property marked optional.
type Partial<T> = {
    [K in keyof T]?: T[K]
};

Until now, mapped types could only produce new object types with keys that you provided them; however, lots of the time you want to be able to create new keys, or filter out keys, based on the inputs.

That's why TypeScript 4.1 allows you to re-map keys in mapped types with a new as clause.

type MappedTypeWithNewKeys<T> = {
    [K in keyof T as NewKeyType]: T[K]
    //            ^^^^^^^^^^^^^
    //            This is the new syntax!
}

With this new as clause, you can leverage features like template literal types to easily create property names based off of old ones.

type Getters<T> = {
    [K in keyof T as `get${Capitalize<string & K>}`]: () => T[K]
};

interface Person {
    name: string;
    age: number;
    location: string;
}

type LazyPerson = Getters<Person>;

and you can even filter out keys by producing never. That means you don't have to use an extra Omit helper type in some cases.

// Remove the 'kind' property
type RemoveKindField<T> = {
    [K in keyof T as Exclude<K, "kind">]: T[K]
};

interface Circle {
    kind: "circle";
    radius: number;
}

type KindlessCircle = RemoveKindField<Circle>;
// same as
//   type KindlessCircle = {
//       radius: number;
//   };

For more information, take a look at the original pull request over on GitHub.

Recursive Conditional Types

In JavaScript it's fairly common to see functions that can flatten and build up container types at arbitrary levels. For example, consider the .then() method on instances of Promise.
.then(...) unwraps each promise until it finds a value that's not "promise-like", and passes that value to a callback. There's also a relatively new flat method on Arrays that can take a depth of how deep to flatten.

Expressing this in TypeScript's type system was, for all practical intents and purposes, not possible. While there were hacks to achieve this, the types ended up looking very unreasonable.

That's why TypeScript 4.1 eases some restrictions on conditional types - so that they can model these patterns. In TypeScript 4.1, conditional types can now immediately reference themselves within their branches, making it easier to write recursive type aliases.

For example, if we wanted to write a type to get the element types of nested arrays, we could write the following deepFlatten type.

type ElementType<T> =
    T extends ReadonlyArray<infer U> ? ElementType<U> : T;

function deepFlatten<T extends readonly unknown[]>(x: T): ElementType<T>[] {
    throw "not implemented";
}

// All of these return the type 'number[]':
deepFlatten([1, 2, 3]);
deepFlatten([[1], [2, 3]]);
deepFlatten([[1], [[2]], [[[3]]]]);

Similarly, in TypeScript 4.1 we can write an Awaited type to deeply unwrap Promises.

type Awaited<T> = T extends PromiseLike<infer U> ? Awaited<U> : T;

/// Like `promise.then(...)`, but more accurate in types.
declare function customThen<T, U>(
    p: Promise<T>,
    onFulfilled: (value: Awaited<T>) => U
): Promise<Awaited<U>>;

Keep in mind that while these recursive types are powerful, but they should be used responsibly and sparingly.

First off, these types can do a lot of work which means that they can increase type-checking time. Trying to model numbers in the Collatz conjecture or Fibonacci sequence might be fun, but don't ship that in .d.ts files on npm.

But apart from being computationally intensive, these types can hit an internal recursion depth limit on sufficiently-complex inputs. When that recursion limit is hit, that results in a compile-time error. In general, it's better not to use these types at all than to write something that fails on more realistic examples.

See more at the implementation.

Checked Indexed Accesses (`--noUncheckedIndexedAccess`)

TypeScript has a feature called index signatures. These signatures are a way to signal to the type system that users can access arbitrarily-named properties.

interface Options {
    path: string;
    permissions: number;

    // Extra properties are caught by this index signature.
    [propName: string]: string | number;
}

function checkOptions(opts: Options) {
    opts.path // string
    opts.permissions // number

    // These are all allowed too!
    // They have the type 'string | number'.
    opts.yadda.toString();
    opts["foo bar baz"].toString();
    opts[Math.random()].toString();
}

In the above example, Options has an index signature that says any accessed property that's not already listed should have the type string | number. This is often convenient for optimistic code that assumes you know what you're doing, but the truth is that most values in JavaScript do not support every potential property name. Most types will not, for example, have a value for a property key created by Math.random() like in the previous example. For many users, this behavior was undesirable, and felt like it wasn't leveraging the full strict-checking of --strictNullChecks.

That's why TypeScript 4.1 ships with a new flag called --noUncheckedIndexedAccess. Under this new mode, every property access (like foo.bar) or indexed access (like foo["bar"]) is considered potentially undefined. That means that in our last example, opts.yadda will have the type string | number | undefined as opposed to just string | number. If you need to access that property, you'll either have to check for its existence first or use a non-null assertion operator (the postfix ! character).

// Checking if it's really there first.
if (opts.yadda) {
    console.log(opts.yadda.toString());
}


// Basically saying "trust me I know what I'm doing"
// with the '!' non-null assertion operator.
opts.yadda!.toString();

One consequence of using --noUncheckedIndexedAccess is that indexing into an array is also more strictly checked, even in a bounds-checked loop.

function screamLines(strs: string[]) {
    // this will have issues
    for (let i = 0; i < strs.length; i++) {
        console.log(strs[i].toUpperCase());
        //          ~~~~~~~
        // error! Object is possibly 'undefined'.
    }
}

If you don't need the indexes, you can iterate over individual elements by using a for-of loop or a forEach call.

function screamLines(strs: string[]) {
    // this works fine
    for (const str of strs) {
        console.log(str.toUpperCase());
    }

    // this works fine
    strs.forEach(str => {
        console.log(str.toUpperCase());
    });
}

This flag can be handy for catching out-of-bounds errors, but it might be noisy for a lot of code, so it is not automatically enabled by the --strict flag; however, if this feature is interesting to you, you should feel free to try it and determine whether it makes sense for your team's codebase!

You can learn more at the implementing pull request.

`paths` without `baseUrl`

Using path-mapping is fairly common - often it's to have nicer imports, often it's to simulate monorepo linking behavior.

Unfortunately, specifying paths to enable path-mapping required also specifying an option called baseUrl, which allows bare specifier paths to be reached relative to the baseUrl too. This also often caused poor paths to be used by auto-imports.

In TypeScript 4.1, the paths option can be used without baseUrl. This helps avoid some of these issues.

`checkJs` Implies `allowJs`

Previously if you were starting a checked JavaScript project, you had to set both allowJs and checkJs. This was a slightly annoying bit of friction in the experience, so checkJs now implies allowJs by default.

See more details at the pull request.

React 17 JSX Factories

TypeScript 4.1 supports React 17's upcoming jsx and jsxs factory functions through two new options for the jsx compiler option:

react-jsx
react-jsxdev

These options are intended for production and development compiles respectively. Often, the options from one can extend from the other. For example, a tsconfig.json for production builds might look like the following:

// ./src/tsconfig.json
{
    "compilerOptions": {
        "module": "esnext",
        "target": "es2015",
        "jsx": "react-jsx",
        "strict": true
    },
    "include": [
        "./**/*"
    ]
}

and one for development builds might look like the following:

// ./src/tsconfig.dev.json
{
    "extends": "./tsconfig.json",
    "compilerOptions": {
        "jsx": "react-jsxdev"
    }
}

For more information, check out the corresponding PR.

Editor Support for the JSDoc `@see` Tag

The JSDoc tag @see tag now has better support in editors for TypeScript and JavaScript. This allows you to use functionality like go-to-definition in a dotted name following the tag. For example, going to definition on first or C in the JSDoc comment just works in the following example:

// @filename: first.ts
export class C { }

// @filename: main.ts
import * as first from './first';

/**
 * @see first.C
 */
function related() { }

Thanks to frequent contributor Wenlu Wang for implementing this!

Breaking Changes

`lib.d.ts` Changes

lib.d.ts may have a set of changed APIs, potentially in part due to how the DOM types are automatically generated. One specific change is that Reflect.enumerate has been removed, as it was removed from ES2016.

`abstract` Members Can't Be Marked `async`

Members marked as abstract can no longer be marked as async. The fix here is to remove the async keyword, since callers are only concerned with the return type.

`any`/`unknown` Are Propagated in Falsy Positions

Previously, for an expression like foo && somethingElse, the type of foo was any or unknown, the type of the whole that expression would be the type of somethingElse.

For example, previously the type for x here was { someProp: string }.

declare let foo: unknown;
declare let somethingElse: { someProp: string };

let x = foo && somethingElse;

However, in TypeScript 4.1, we are more careful about how we determine this type. Since nothing is known about the type on the left side of the &&, we propagate any and unknown outward instead of the type on the right side.

The most common pattern we saw of this tended to be when checking compatibility with booleans, especially in predicate functions.

function isThing(x: any): boolean {
    return x && typeof x === 'object' && x.blah === 'foo';
}

Often the appropriate fix is to switch from foo && someExpression to !!foo && someExpression.

`resolve`'s Parameters Are No Longer Optional in `Promise`s

When writing code like the following

new Promise(resolve => {
    doSomethingAsync(() => {
        doSomething();
        resolve();
    })
})

You may get an error like the following:

  resolve()

error TS2554: Expected 1 arguments, but got 0.
An argument for 'value' was not provided.




This is because `resolve` no longer has an optional parameter, so by default, it must now be passed a value. Often this catches legitimate bugs with using `Promise`s. The typical fix is to pass it the correct argument, and sometimes to add an explicit type argument.



```ts
new Promise<number>(resolve => {
    //     ^^^^^^^^
    doSomethingAsync(value => {
        doSomething();
        resolve(value);
        //      ^^^^^
    })
})

However, sometimes resolve() really does need to be called without an argument. In these cases, we can give Promise an explicit void generic type argument (i.e. write it out as Promise<void>). This leverages new functionality in TypeScript 4.1 where a potentially-void trailing parameter can become optional.

new Promise<void>(resolve => {
    //     ^^^^^^
    doSomethingAsync(() => {
        doSomething();
        resolve();
    })
})

TypeScript 4.1 ships with a quick fix to help fix this break.

Conditional Spreads Create Optional Properties

In JavaScript, object spreads (like { ...foo }) don't operate over falsy values. So in code like { ...foo }, foo will be skipped over if it's null or undefined.

Many users take advantage of this to spread in properties "conditionally".

interface Person {
    name: string;
    age: number;
    location: string;
}

interface Animal {
    name: string;
    owner: Person;
}

function copyOwner(pet?: Animal) {
    return {
        ...(pet && pet.owner),
        otherStuff: 123
    }
}

// We could also use optional chaining here:

function copyOwner(pet?: Animal) {
    return {
        ...(pet?.owner),
        otherStuff: 123
    }
}

Here, if pet is defined, the properties of pet.owner will be spread in - otherwise, no properties will be spread into the returned object.

The return type of copyOwner was previously a union type based on each spread:

{ x: number } | { x: number, name: string, age: number, location: string }

This modeled exactly how the operation would occur: if pet was defined, all the properties from Person would be present; otherwise, none of them would be defined on the result. It was an all-or-nothing operation.

However, we've seen this pattern taken to the extreme, with hundreds of spreads in a single object, each spread potentially adding in hundreds or thousands of properties. It turns out that for various reasons, this ends up being extremely expensive, and usually for not much benefit.

In TypeScript 4.1, the returned type sometimes uses all-optional properties.

{
    x: number;
    name?: string;
    age?: number;
    location?: string;
}

This ends up performing better and generally displaying better too.

For more details, see the original change. While this behavior is not entirely consistent right now, we expect a future release will produce cleaner and more predictable results.

Unmatched parameters are no longer related

TypeScript would previously relate parameters that didn't correspond to each other by relating them to the type any. With changes in TypeScript 4.1, the language now skips this process entirely. This means that some cases of assignability will now fail, but it also means that some cases of overload resolution can fail as well. For example, overload resolution on util.promisify in Node.js may select a different overload in TypeScript 4.1, sometimes causing new or different errors downstream.

As a workaround, you may be best using a type assertion to squelch errors.

What's Next?

We hope that TypeScript 4.1 makes coding feel perfectly splendid. To stay in the loop on our next version, you can track the 4.2 Iteration Plan and our Feature Roadmap as it comes together.

Happy Hacking!

- Daniel Rosenwasser and the TypeScript Team

Type | Treat The Finale

Gabrielle Crevecoeur — Sat, 31 Oct 2020 18:50:09 +0000

Thank you so much for participating in TypeScript's Type | Treat coding challenges! Unfortunately, we have come to the end of our spooky journey but no worries, there will be more challenges to come in the future!

Beginner/Learner Challenges

Intermediate/Advanced Challenges

Yesterday's Solution

Beginner/Learner Challenge

Like many challenges, you answer to this depends on how thorough you wanted to type the houses.
The in-challenge text tries to guide you to answer with a single generic type which passes the first argument to both trickOrTreat and restock.

type House<Candy> = {
  doorNumber: number
  trickOrTreat(): Candy;
  restock(items: Candy): void;
}

type FirstHouse = House<"book" | "candy">

type SecondHouse = House<"toothbrush" | "mints">

// ... same pattern for the rest

This could be enough, and that's totally enough type safety for cases like this. This does lose the doorNumber being exact though. So, here are two different routes to give the doorNumber to each house:

// Via a 2nd generic argument
type House<DoorNumber, Candy> = {
  doorNumber: DoorNumber
  trickOrTreat(): Candy;
  restock(items: Candy): void;
}

type FirstHouse = House<1, "book" | "candy">

type SecondHouse = House<2, "toothbrush" | "mints">

// ... same pattern for the rest

and

type House<Candy> = {
  doorNumber: number
  trickOrTreat(): Candy;
  restock(items: Candy): void;
}

// Via intersection types:
type FirstHouse = House<"book" | "candy"> & { doorNumber: 1 }

type SecondHouse = House<"toothbrush" | "mints"> & { doorNumber: 2 }

Our answer.

Intermediate/Advanced Challenge

OK, this one is tricky. It's based on this Playground example.

We started out by making types for passing the data around

type Movies = typeof moviesToShow
type Movie = { forKids: boolean }

// Template strings literals to describe each task
type Get<T extends string> = `getVHSFor${capitalize T}`
type MakePopcorn<T extends string> = `makePopcornFor${capitalize T}`
type Play<T extends string> = `play${capitalize T }`

// A union of the above literal types
type Tasks<T extends string> = Get<T> | MakePopcorn<T> | Play<T>

These gave us a set of primitives which could work together to create this whopper:

type MakeScheduler<Type> = {
  [Field in keyof Type as Tasks<Field extends string ? Field : never>]: () => void;
};

This type uses the new as syntax for mapped types in TypeScript 4.1 to essentially map each field (Field) from the keys in the input type (Type) to the union Tasks above. This means that each field is converted into three templated literals:

input: `"halloween"` turns to:
  ├─ Get<"halloween"> -> `getVHSForHalloween`
  ├─ MakePopcorn<"halloween"> -> `makePopcornForHalloween`
  └─ Play<"halloween"> -> `playHalloween`

Which is declared to be a function which returns void.

This type is then used as the return type for the makeScheduler function:

function makeScheduler(movies: Movies): MakeScheduler<Movies> {

For simplicities sake, we skipped typing the inside of the function - though the folks who did that, good work!

The second part added one simple constraint, but one that requires some work to get right. We wanted to take into account whether a movie was for kids of not inside the type system.

Our answer for this was to recreate the scheduler function above, and to add the logic for removing those types during the type mapping process.

type MakeKidsScheduler<Type> = {
  [Field in keyof Type as Tasks<Field extends string ? Field : never>]:
    Type[Field] extends { forKids: true } ?  () => void : never;
};

Instead of returning a () => void, we inserted a conditional type in the return position which first checked if forKids is true in the original type. If it was, then it returned the function - otherwise it returned never. Returning never here would mean that the function would not exist - removing them from the mapping process.

The community came up with quite a few alternative takes which provided type safety inside the functions and used different routes like removing the non-kids movie keys ahead of time.

Our answer

Share Your Experience

We would love to hear your feedback on this weeks challenges whether good or a bad! If you can please take our quick 4 question survey that can be found here

Want More?!

If you want to learn more about TypeScript, check out some of our best resources:

Happy Typing :)

Type | Treat Challenge 5

Gabrielle Crevecoeur — Fri, 30 Oct 2020 21:06:05 +0000

Welcome to the final Type | Treat challenge! Today we will be restocking Halloween candy and identifying Halloween movies

Yesterday's Solution

Beginner/Learner Challenge

We were looking for using the Readonly utility type to force the type to not allow poltergeists to make changes to your rooms.

- type Rectory = {
+ type Rectory = Readonly<{
    rooms: Room[]
    noises: any[]
- }
+ }>

- type Room = {
+ type Room = Readonly<{
    name: string
    doors: number
    windows: number
    ghost?: any
- }
+ }>

It's worth remembering that JavaScript doesn't have immutability like this, so this really only affects the type system. You'll get a compiler error, but people can still work around that.

Our answer

Intermediate/Advanced Challenge

This challenge evolved quite naturally from the third challenge with the addition of 4.1's heading feature Template Literals.

The most elegant answer moved the return type into the object const winners which would then be inferred as the return type of tallyPopularWinners:

const breeds = ["Hound" , "Corgi" , "Pomeranian"] as const
const costumes = ["Pumpkin" , "Hot Dog" , "Bumble Bee"] as const

+ type Breed = typeof breeds[number]
+ type Costume = typeof costumes[number]
+ type BreedCostumeCombination = `${lowercase typeof breeds[number]}-${lowercase typeof costumes[number]}`

function tallyPopularWinners(_breeds: typeof breeds, _costumes: typeof costumes) {
-  const winners = {} as any
+  const winners: Record<BreedCostumeCombination, ReturnType<typeof decideWinner>> = {} as any

Our answer Also, we watched the full two hours of that video, and it's a great background video while you're working.

The Challenge

Beginner/Learner Challenge

You're in charge of restocking the houses on your street, can you find a way to reduce the duplication in your notes by generically declaring a house?

Help keep those houses DRY

Intermediate/Advanced Challenge

You're working on a horror movie night. You've skipped the types because you figured it'd be simple to work with but someone put the wrong movie in and The Nightmare Before Christmas is not a halloween movie. It's in the name. Anyway. To avoid this happening again, you figure it's time to add types to the function. Once, you got that down then you wonder if you can do the same thing for the kids schedule?

Help type the scheduler

Be sure to submit your solution by using the Share button in the TypeScript playground.

Then go to Twitter, and create a tweet about the challenge, add the link to your code and mention the TypeScript page (@typescript)

Need Extra Help?

If you need additional help you can utilize the following:

The TypeScript Handbook
TypeScript Discord Page
The comments on each Dev.to posts!

Happy Typing :)

Type | Treat Challenge 4

Gabrielle Crevecoeur — Thu, 29 Oct 2020 20:27:38 +0000

Type | Treat Challenge 4

Welcome to the fourth Type | Treat challenge! Today we will be stopping hauntings and putting puppies in their place.

Yesterday's Solution

Beginner/Learner Challenge

We were looking for some pretty simple types in this challenge:

type Treat = { 
  location: string
  result: "treat",
  treat: { candy: string, baked?: string } 
}

type Trick = {
  location: string
  result: "trick",
  trick: string
}

type NoShow = {
  location: string
 result: "no-show"
}

We can safely and efficiently reuse the properties in each field by extending them with an interface.

type House = {
  location: string
  result: "treat" | "trick" | "no-show"
}

interface Treat extends House { treat: { candy: string, baked?: string } }
interface Trick extends House  { trick: string }
interface NoShow extends House { trick: string }

We can specialize each result property with the specific value a Trick, Treat, or NoShow will hold by re-declaring it.

interface Treat extends House { result: "treat", treat: { candy: string, baked?: string } }
interface Trick extends House { result: "trick", trick: string }
interface NoShow extends House { result: "no-show" }

Which would give the exact string value for result in each type.

Our answer.

Intermediate/Advanced Challenge

This one either stumped people for ten minutes or was considered a breeze. We had a few different answers in the TypeScript team, but we think this one is the most elegant.

type Result = {
    done: boolean,
    who: string,
    loot: Record<string, any>
}

type TrunkOrTreatResults = Record<typeof trunkOrTreatSpots[number], Result>

This challenge was a great reminder that a Record is simply a type-alias to a conditional type:

type Record<K extends string | number | symbol, T> = { [P in K]: T; }

Which can convert the original answer:

type Result = {
    done: boolean,
    who: string,
    loot: Record<string, any>
}

type ResultMapper<P extends readonly string[]> = {
    [K in P[number]]: Result
};

type TrunkOrTreatResults = ResultMapper<typeof trunkOrTreatSpots>;

into code which is both easier to read, and requires knowing less language concepts. Kudos to the folks who made it seem very easy!

Here's our answer. Bonus: the weirdest answer.

The Challenge

Beginner/Learner Challenge

Don't freak out... Ok freak out a little bit cause WE ARE BEING HAUNTED! And they are after our code! We have tried everything but we cant seem to get it right!

Somehow they keep manipulating the objects set this snippet of code. Take a look and see if you can force the ghosts to stop moving things around.

Intermediate/Advanced Challenge

You've been roped into helping out the halloween puppy parade, it was such a distracting even that you did the minimum possible to spend as much time watching the show.

Now it's over, you figure it's time to clean up your code and try get it type-safe.

Submissions

Be sure to submit your solution by using the Share button in the TypeScript playground.

Then go to Twitter, and create a tweet about the challenge, add the link to your code and mention the TypeScript page (@typescript)

Need Extra Help?

If you need additional help you can utilize the following:

The TypeScript Handbook
TypeScript Discord Page
The comments on each Dev.to posts!

Happy Typing :)

Type | Treat Challenge 3

Gabrielle Crevecoeur — Wed, 28 Oct 2020 20:00:36 +0000

Welcome to the third Type | Treat challenge! Today we will be going over yesterday's answers and diving into some new problems to solve.

Yesterday's Solution

Beginner/Learner Challenge

The typeof operator is one of those small tools which helps you avoid duplication, if you already have the type in the runtime - why not re-use it?

- type Pumpkin = any
+ type Pumpkin = typeof pumpkin

- type PumpkinFromFunction = any
+ type PumpkinFromFunction = ReturnType<typeof Pumpkin>

Intermediate/Advanced Challenge

This one is a tricky one. Made a bit harder by an accident of not including every ghost in the Ghosts type.

The challenge aimed give a subtle nod to day 1's question, where the rest of the challenge becomes easier if you first make a set of types via conditionals or Extract.

type Gods = Extract<Ghosts, { god: true }>;
type Demons = Extract<Ghosts, { demon: true }>;
type EctoPlasmics = Extract<Ghosts, { ectoplasmic: true }>;

This does actually work in the current challenge, even though it's not quite right. From there, you can create user-defined type guards to change the code flow in the main algorithm to work as expected.

function areGods(ghosts: Ghosts[]): ghosts is Gods[] {
  return ghosts.every(ghost => "god" in ghost);
}

function areDemons(ghosts: Ghosts[]): ghosts is Demons[] {
  return ghosts.every(ghost => "demon" in ghost);
}

function areEctoPlasmic(ghosts: Ghosts[]): ghosts is EctoPlasmics[] {
  return ghosts.every(ghost => "ectoplasmic" in ghost);
}

That said, let's try work within the constraint of 'maybe the TypeScript team know what they are doing, and this challenge is meant to be this way?!' - which is kinda provably false from this challenge.

In the TypeScript structural type system, you don't really need to know much more than is required, and you could safely create a singular type for God, Demon and EctoPlasmics, then declare an array of those types:

type God = Ghosts & { god: true };
type Demon = Ghosts & { demon: true, sendBackToHell(): void };
type EctoPlasmic = Ghosts &  { ectoplasmic: true };

function areGods(ghosts: Ghosts[]): ghosts is God[] {
  return ghosts.every(ghost => "god" in ghost);
}

function areEctoPlasmic(ghosts: Ghosts[]): ghosts is EctoPlasmic[] {
  return ghosts.every(ghost => "ectoplasmic" in ghost);
}

function areDemons(ghosts: Ghosts[]): ghosts is Demon[] {
  return ghosts.every(ghost => "demon" in ghost);
}

That type-safety is enough for the algorithm, but could bite you later on because Ghosts & [x] makes any other property optional.
If you are going for minimalism, here's a terse answer in 3 one-liners which takes into account usage inside the algorithm:

const areDemons = (ghosts: Ghosts[]): ghosts is Extract<Ghosts, { demon: true }>[] => ghosts.every(ghost => "demon" in ghost);
const areEctoPlasmic = (ghosts: Ghosts[]): ghosts is Extract<Ghosts, { ectoplasmic: true }>[] => ghosts.every(ghost => "ectoplasmic" in ghost);
const areGods = (ghosts: Ghosts[]): boolean => ghosts.every(ghost => "god" in ghost);

@igorbek managed to get it to two lines!

The Challenge

Beginner/Learner Challenge

You've been keeping tally of how the houses on your street respond to trick-or-treaters. Can you reduce duplication from the types needed to describe the results?

Help out here

Intermediate/Advanced Challenge

You have a list of trunk or treat spots, in your rush you hardcoded the result of your map function to convert it from an array to an object.
Now the list is longer than three items, it's time to map that hardcoded result into a type. Can you refactor this TODO list function?

Refactor

Be sure to submit your solution by using the Share button in the TypeScript playground.

Then go to Twitter, and create a tweet about the challenge, add the link to your code and mention the TypeScript page (@typescript)

Need Extra Help?

If you need additional help you can utilize the following:

The TypeScript Handbook
TypeScript Discord Page
The comments on each Dev.to posts!

Happy Typing :)

Type | Treat Challenge 2

Gabrielle Crevecoeur — Tue, 27 Oct 2020 22:56:59 +0000

Welcome to the second Type | Treat challenge! Today we will be deriving the types of pumpkins and busting ghosts!

Yesterday's Solution

Beginner/Learner Challenge

The solution for this challenge used indexed types to extract a part of an existing type to avoid duplication. The need to use [number] is an interesting twist, because [0] or [1] (or any number) would have worked just as well too. Doing this right would also have raised the typo in the original code.

// Your goal: remove this any, without changing GhostAPIResponse
- const displayHauntings = (haunting: any) => {
+ const displayHauntings = (haunting: GhostAPIResponse["hauntings"][number]) => {
  console.log(` - Title: ${haunting.title}`)

Link

Intermediate/Advanced Challenge

// You're first going to need to separate out the candy from the treats,
// you can do that via conditional types.

- // type AllCandies = ...
+ type IsCandy<A> = A extends { candy: true } ? A : never;
+ type AllCandies = IsCandy<ResultsFromHalloween>

- // type AllTricks = ...
+ type IsTrick<A> = A extends { trick: true } ? A : never;
+ type AllTricks = IsTrick<ResultsFromHalloween>

// Almost there, but little 'Bobby Tables' cannot have peanuts. Can
// you make a list of candies just for him?

- // type AllCandiesWithoutPeanuts = ...
type HasPeanuts<A> = A extends { peanuts: true } ? A : never;
type AllCandiesWithoutPeanuts = HasPeanuts<AllCandies>

Our original answer relied on using Conditional Types to narrow the union, however we got a lot of responses using the Exclude utility type to make it a single liner:

type AllCandies = Exclude<ResultsFromHalloween, { candy: true }>

Which is a great solution. Full link

The Challenge

Beginner/Learner Challenge

Lets take a trip to the pumpkin patch and try to find the perfect one for our Jack O'Lantern. But in order to make sure we have located the right type of pumpkin, we need your help in identifying pumpkin types.

We created some starter code you can find here, lets see if you can finish it.

Intermediate/Advanced Challenge

Your job busting ghosts just got real tricky. Before you head in to guard Manhattan, you need to assert to those ghosts who is boss. Help finalize the ghost-busting algorithm because who else are you gonna call?

Sharing

Be sure to submit your solution by using the Share button in the TypeScript playground.

Then go to Twitter, and create a tweet about the challenge, add the link to your code and mention the TypeScript page (@typescript)

Need Extra Help?

If you need additional help you can utilize the following:

The TypeScript Handbook
TypeScript Discord Page
The comments on each Dev.to posts!

Happy Typing :)

Type | Treat Challenge 1

Gabrielle Crevecoeur — Mon, 26 Oct 2020 18:09:01 +0000

Welcome to the first Type | Treat challenge! Today we will be extracting haunting data from ghosts and sorting Halloween candy!

The Challenge

Beginner/Learner Challenge

So the TypeScript team is being hired to investigate recent hauntings in the community, and we are trying to figure which ghost is the trouble-maker!

We found an API that will allow us to get data on the ghosts however, out code isn't fully optimized. So we need your help.

Head to this link and help us figure out the best type to use in one of our function parameters!

Intermediate/Advanced Challenge

Your kids have come back from trick or treating with a lot of loot. Someone's going to have to sort this pile, and it looks like that job has fallen to you. Can you conditionally filter the pile into manageable lists?

Head over to start sorting.

Share Your Code

Be sure to submit your solution by using the Share button in the TypeScript playground to copy the link to your clipboard.

Next go to Twitter, and create a tweet about the challenge, add the paste the link to your code and mention the TypeScript page (@typescript) !

Need Extra Help?

If you need additional help you can utilize the following:

The TypeScript Handbook
TypeScript Discord Page
The comments on each Dev.to posts!
Beginners may want to check out this page from the TypeScript Handbook

Happy Typing :)

Forem: typescript

Type | Treat 2021 - Wrap-up

Type | Treat Challenge Wrap-up

Yesterday's Solution

Beginner/Learner Challenge

Intermediate/Advanced Challenge

Thanks!

Feedback

From here?

Type | Treat 2021 - Day 5

Type | Treat Challenge 5

Yesterday's Solution

Beginner/Learner Challenge

Intermediate/Advanced Challenge

The Challenge

Beginner/Learner Challenge

Intermediate/Advanced Challenge

How To Share Your Solution

Best Resources for Additional Help

Type | Treat 2021 - Day 3

Type | Treat Challenge 3

Yesterday's Solution

Beginner/Learner Challenge

Intermediate/Advanced Challenge

The Challenge

Beginner/Learner Challenge

Intermediate/Advanced Challenge

How To Share Your Solution

Best Resources for Additional Help

Type | Treat 2021 - Day 2

Type | Treat Challenge 2

Yesterday's Solution

Beginner/Learner Challenge

Intermediate/Advanced Challenge

The Challenge

Beginner/Learner Challenge

Intermediate/Advanced Challenge

How To Share Your Solution

Best Resources for Additional Help

Type | Treat 2021 - Day 1

Type or Treat Challenges

How To Participate

How To Share Your Solution

Best Resources for Additional Help

Day 1 Challenges

Beginner/Learner Challenge

Intermediate/Advanced Challenge

Announcing TypeScript 4.1

Template Literal Types

Key Remapping in Mapped Types

Recursive Conditional Types

Checked Indexed Accesses (--noUncheckedIndexedAccess)

paths without baseUrl

checkJs Implies allowJs

React 17 JSX Factories

Editor Support for the JSDoc @see Tag

Breaking Changes

lib.d.ts Changes

abstract Members Can't Be Marked async

any/unknown Are Propagated in Falsy Positions

resolve's Parameters Are No Longer Optional in Promises

Conditional Spreads Create Optional Properties

Unmatched parameters are no longer related

What's Next?

Type | Treat The Finale

Beginner/Learner Challenges

Intermediate/Advanced Challenges

Yesterday's Solution

Beginner/Learner Challenge

Intermediate/Advanced Challenge

Share Your Experience

Want More?!

Type | Treat Challenge 5

Yesterday's Solution

Beginner/Learner Challenge

Intermediate/Advanced Challenge

The Challenge

Beginner/Learner Challenge

Intermediate/Advanced Challenge

Share

Checked Indexed Accesses (`--noUncheckedIndexedAccess`)

`paths` without `baseUrl`

`checkJs` Implies `allowJs`

Editor Support for the JSDoc `@see` Tag

`lib.d.ts` Changes

`abstract` Members Can't Be Marked `async`

`any`/`unknown` Are Propagated in Falsy Positions

`resolve`'s Parameters Are No Longer Optional in `Promise`s