z.strict() fixed a nasty bug for me this morning.

You should probably be using it on most of the schemas that handle outside data.

Here's the bug 🧵 I had a form where I was marking the date a post was posted. I was expecting a key of `postedAt`, with an optional datetime.

Narrowing down the types of values is key knowledge for any TypeScript dev.

Here's 11 different ways you can do it. I bet you won't know 2 or 3 of them!

🧵 Narrowing with typeof:

So many folks don't know about structuredClone.

It's awesome, built-in, and supported in all major browsers.

Let's learn 🧵 A common pattern in JavaScript is to create an immutable clone of an object. This is useful when you want to make mutations to it without changing the original.

For that, you'll often see code using the spread operator: `{ ...obj }`.

I'm starting to think that library types in TypeScript are all wrong.

Instead of top-level types, they should be available right on the functions that use them.

Brief thread 🧵 How is this possible? Well, it's due to a trick in the way namespaces work in TypeScript.

When you export a namespace with the same name as a function, TypeScript combines the two:

I've changed my mind on .d.ts files.

If you're writing application code, you should NEVER use them.

Let me explain 🧵 Declaration files are files that only contain types.

They've got two purposes - providing types for JavaScript files, and augmenting types in the global scope.

Here's the section on them in my book:

buff.ly/3SDoL6p

Sometimes, TypeScript's narrowing kind of sucks.

The prime suspect? Boolean.

Let's take a look at why. 🧵 Let's explain the code above. `myFunc` takes in a string or null. We want to ensure it's not null for some reason.

So, we can use an if statement to check if it's truthy. If it's truthy, it ain't null.

We can do that in MANY different ways:

In celebration of my free book coming out, here's a massive thread of all my best free TypeScript resources.

I guarantee that if you work through this list, you'll be the top TypeScript wizard at your company.

🧵 We've got to start with the book. It's 16 chapters of totally free written content.

It goes from first principles all the way up to the bottom end of advanced.

It's the no-brainer place to start.

totaltypescript.com/books/total-ty…

After all the chat about typing event handlers in React, I figured I'd write down all the suggestions folks gave.

Quick 🧵 The most popular solution is to hover the onChange attribute in the JSX, then use that to type your handler.

But this creates an astonishingly long type - very intimidating for newbies.

How should you type React Props?

You've got three options. type, interface or an inline object literal.

Inline object literals might be fast to write, but it means you can't extract the type out for use elsewhere in your codebase:
This makes them hard to recommend.

So, interface vs type again. As I've said before, I prefer type.

But let's say you're building an input that needs to take all the props of 'input', but with an extra label.

For those cases, you must use interfaces:
Using an intersection here will slow down TypeScript on the scale of a large codebase. interface extends is the way to go.

This means that it's a good idea to get into the habit of using interfaces for each prop declaration.

I recommend using a code snippet to declare the interface for you:
All the speed of an object literal, but all the reusability and TS performance of an interface.

Want to share outside of X? Head to Total TypeScript:

totaltypescript.com/react-props-ty…

If you don't understand generics in TypeScript, I think there's something you've misunderstood.

There is no such thing as a 'generic'.

🧵 There are generic types, generic functions, and generic classes.

There are type arguments, and type parameters.

You cannot 'pass' a generic, 'declare' it, or 'infer' it.

In other words, 'generic' is not a noun, it's an adjective.

totaltypescript.com/no-such-thing-…

Lazy Dev Twitter:

Anyone know if it's possible to detect a QR code (or even just a fiducial) from a video using ffmpeg? I'm asking for a slightly hilarious reason.

I use ffmpeg for automatically editing my videos. When I screw up a take, I want to be able to hold up a QR code on a paddle to tell my editing software to discard that take.

Why any's happen, how to stop them, and why unknown isn't necessarily a better solution 🧵

Any 'any' in a codebase is a cause for concern. That's because it disables typechecking on the thing it's assigned to.

Pass it to a function parameter? You then can't guarantee anything about that function parameter.

Working with mocks in TS sucks.

The only way you can make it work is by slapping 'as' on everything - which can make the tests hard to maintain.

What if you had a simple set of functions that could let you pass whatever you wanted, but with perfect autocomplete? This feels pretty simple on the surface - many of you might have tried to make these kinds of abstractions before.

But it's harder than you think - you need a bit of wizardry. Let's take partial().

Why isn't the code below working?

satisfies in TypeScript has been out for a little while now.

Overall, it's been a success - but it's starting to cause some confusion.

Let's clear it up. satisfies has added yet another tool to the TypeScript user's toolkit.

There are now _three_ ways to assign types to values.

https://twitter.com/stolinski/status/1630671037363879936

Today's the day.

Total TypeScript is ready. 🧙 Hundreds of videos over three modules
🔥 The deepest exploration of Generics on the market
❤️ Interactive editors, transcripts, and thousands of words of accompanying articles
🪄 Perfect if you've used TS for a while, but want to achieve mastery

totaltypescript.com

TypeScript annoys me sometimes.

So, I decided to do something about it... It's always bugged me that JSON.parse returns 'any'.

It means that, just by using an extremely common JS method, you're introducing a dangerous type into your codebase.

👀 👀👀

An extremely incomplete TypeScript features type-safety tier list.

🧵 F-tier

as any
as unknown as X
// @ts-ignore
// @ts-expect-error

In application code, these should be avoided at all costs. You pretty much always have a better option.

Just made three pull requests to @calcom to improve their types in small, subtle ways.

Take a look! You might learn something. github.com/calcom/cal.com…

Here, there were some globals being stored for safekeeping in the global scope.

I added their types using a declare global, meaning they could be safely accessed (and spotted a subtle bug in the process).

If you don't know generics, I promise you'll understand them by the end of this thread.

I like a challenge. What you might think of as generics in TypeScript is actually three separate concepts:

- Passing types to types
- Passing types to functions
- Inferring types from arguments passed to functions

Let's talk about branded types.

If I were building an app where security was critical, I'd use the crap out of them. A Brand type lets you use a bit of 'nominal' typing inside TypeScript.

By declaring a unique symbol, 'brand', we can use this Brand type helper to create types with 'names'.