Effective TypeScript Book Cover

TypeScript is a typed superset of JavaScript with the potential to solve many of the headaches for which JavaScript is famous. But TypeScript has a learning curve of its own, and understanding how to use it effectively can take time.

Effective TypeScript guides you through 62 specific ways to improve your use of TypeScript, following the format popularized by Effective C++ and Effective Java. You’ll advance from a beginning or intermediate user familiar with the basics to an advanced user who knows how to use the language well.

Already have the Book? Visit the GitHub project to see all of the code snippets from the book in one place. You can also report any errors you've found.

Buy the Book Buy the eBook

Praise for Effective TypeScript

Effective TypeScript explores the most common questions we see when working with TypeScript and provides practical, results-oriented advice. Regardless of your level of TypeScript experience, you can learn something from this book.

Ryan Cavanaugh, Engineering Lead for TypeScript at Microsoft

This book is packed with practical recipes and must be kept on the desk of every TypeScript eveloper. Even if you think you know TypeScript already, get this book and you won't regret it.

Yakov Fain, Java Champion

I have been working with TypeScript for two years, and with Flow for five. And it happens that I provided technical feedback for this book. It was a joy read. The items in the book provide specific, actionable advice that will help to deepen your understanding of TypeScript, and Dan's explanations are clear and concise. There is a lot of useful information, but my favorite part is Chapter 4, Type Design. Even as an experienced hotshot I learned a number of new things. And the advice sticks with me in my day-to-day work. For example I make an effort to apply types to entire function expressions, and in some cases I do so by using specialized React event handler types that this book pointed me to. Plus Dan convinced me to switch my @type dependencies to devDependencies.

Jesse Hallett, Senior Software Engineer, Originate, Inc.

The book hit me in exactly the right spot. I'm an experienced developer and I've worked with JS on and off for many years, but my structured TS education is limited to the official tutorial. I was able to figure out most of it along the way (TS is intuitive if you have good JS knowledge and realize how it works, Google and SO helped a lot too), but this approach also left me with a lot of gaps in my knowledge, many of which I don't even realize I have. This book excels at plugging such gaps.

Now I have to go and refactor some of my code in the light of what I've learned.

Matěj Zábský

Read more reviews on Goodreads and Amazon.

Recent Blog Posts

Finding dead code (and dead types) in TypeScript

Software engineering is a battle against complexity. Without any planning or care, it's easy to build programs where everything interacts with everything else (the "big ball of yarn" model). With a ball of yarn, if you double the number of components, you quadruple the number of interactions:

Complexity increases with the number of interactions, i.e. quadratically

One of the best ways to fight against this ramp-up of complexity is to simply reduce N, i.e. to write fewer lines of code. Using a higher level programming language or depending on well-tested third-party libraries are common ways to do this. But one of the easiest ways is to find code you don't need any more and delete it.

Continue reading »

Repeat yourself a little less: Strategies for mitigating prop drilling with React and TypeScript

I have a new post up on the LogRocket blog this week: Repeat yourself a little less: Strategies for mitigating prop drilling with React and TypeScript.

It presents the problem of "prop drilling" in React, where you want to add a prop to a component somewhere deep down in your hierarchy and you have to add it in ten other places to get it there. It then looks at five different solutions, all of which work in TypeScript. Give it a read and let me know what you think!

TypeScript Exercises

I'd never describe problem sets as "fun," but there's a reason teachers assign them. It's one thing to nod your head as you read a book ("yes, that makes sense") but quite another to apply what you've learned. Software is very much a "learn by doing" field. You retain knowledge better when you actively use it.

I would have liked to include exercises in Effective TypeScript but never quite got around to it. Fortunately, there are several excellent sources of TypeScript exercises and puzzles online. Here are a few:

Continue reading »

The Golden Rule of Generics

Golden Ruler

The New TypeScript Handbook has some real gems in it. Here's what it has to say about generics:

Writing generic functions is fun, and it can be easy to get carried away with type parameters. Having too many type parameters or using constraints where they aren't needed can make inference less successful, frustrating callers of your function.

It goes on to offer a few specific pieces of advice about how to use generics, including one that I've started to think of as the "Golden Rule of Generics":

Type Parameters Should Appear Twice

Type parameters are for relating the types of multiple values. If a type parameter is only used once in the function signature, it's not relating anything.

Rule: If a type parameter only appears in one location, strongly reconsider if you actually need it.

I love this rule because it's so concrete. It gives you a specific way to tell whether any use of generics is good or bad.

Continue reading »

Writing a safe querySelector: the one-way street from values to types

The DOM's document.querySelector method is ubiquitious in JavaScript but somewhat tricky to type in a safe way. This post walks through how you can create a safe querySelector for use in TypeScript code and explains how this is an example of a general pattern of using values (which exist at runtime) as a source of truth, rather than types (which don't). Continue reading »

Type-safe blogs and books with literate-ts

Years ago when Brett Slatkin wrote Effective Python, he blogged about creating a tool call pyliterate to run all the code samples in his book and verify that their output matched what he'd written in the text. The idea stuck with me and when I started writing Effective TypeScript in early 2019, I thought I'd do something similar. If nothing else, static analysis of a book seems very much in the spirit of TypeScript. Creating literate-ts wound up being a lot of work, but in the end I think it more justified itself, though not quite for the reasons I expected!

Continue reading »

Use typed identity functions to guide type inference

TypeScript tends to do a very good job of inferring types when you leave off explicit annotations. (Chapter 3 of Effective TypeScript is devoted to this topic.) But when you use tuples or string literal types, this will sometimes go wrong. This post explores using identity functions with carefully constructed type signatures to guide inference towards alternative types. Continue reading »

Item 54: Know How to Iterate Over Objects

Iterating over the keys and values in an object is a common operation that's surprisingly hard to write without type assertions in TypeScript. This item explains why the types you get from Object.keys or a for-in loop aren't quite what you'd expect, and what your available workarounds are. Continue reading »

Unionize and Objectify: A Trick for Applying Conditional Types to Objects

Conditional types are the most powerful weapon TypeScript gives us for mapping between types. They do their best work on union types, so sometimes it pays to apply slightly counterintuitive transformations to get a union of types, rather than an object. This post presents Unionize and Objectify, two tools I've found extremely helpful for constructing complex mappings between object types. Continue reading »

Item 19: Avoid Cluttering Your Code with Inferable Types

The first thing that many new TypeScript developers do when they convert a codebase from JavaScript is fill it with type annotations. TypeScript is about types, after all! But in TypeScript many annotations are unnecessary. Declaring types for all your variables is counterproductive and is considered poor style. Continue reading »

For new TypeScript content every ~2 weeks, including new examples, sample items, videos and book updates, choose one of these ways to stay in touch:

Subscribe to the Newsletter Follow @danvdk RSS

Table of Contents

In an Effective-style book, the title of each item is a specific piece of advice. This means that the Table of Contents forms a summary of all the advice in the book. If any item piques your curiosity and you want to learn more, order a copy.

Chapter 1: Getting to Know TypeScript

Before we dive into the details, this chapter helps you understand the big picture of TypeScript. What is it and how should you think about it? How does it relate to JavaScript? Are its types nullable or are they not? What's this about any? And ducks?

  1. Understand the Relationship Between TypeScript and JavaScript
  2. Know Which TypeScript Options You’re Using
  3. Understand That Code Generation Is Independent of Types
  4. Get Comfortable with Structural Typing
  5. Limit Use of the any Type

Chapter 2: TypeScript’s Type System

This chapter walks you through the nuts and bolts of TypeScript's type system: how to think about it, how to use it, choices you'll need to make, and features you should avoid. TypeScript's type system is surprisingly powerful and able to express things you might not expect a type system to be able to. The items in this chapter will give you a solid foundation to build upon as you write TypeScript and read the rest of this book.

  1. Use Your Editor to Interrogate and Explore the Type System
  2. Think of Types as Sets of Values
  3. Know How to Tell Whether a Symbol Is in the Type Space or Value Space
  4. Prefer Type Declarations to Type Assertions
  5. Avoid Object Wrapper Types (String, Number, Boolean, Symbol, BigInt)
  6. Recognize the Limits of Excess Property Checking
  7. Apply Types to Entire Function Expressions When Possible
  8. Know the Differences Between type and interface
  9. Use Type Operations and Generics to Avoid Repeating Yourself
  10. Use Index Signatures for Dynamic Data
  11. Prefer Arrays, Tuples, and ArrayLike to number Index Signatures
  12. Use readonly to Avoid Errors Associated with Mutation
  13. Use Mapped Types to Keep Values in Sync

Chapter 3: Type Inference

This chapter shows you some of the problems that can arise with type inference and how to fix them. After reading it, you should have a good understanding of how TypeScript infers types, when you still need to write type declarations, and when it's a good idea to write type declarations even when a type can be inferred.

  1. Avoid Cluttering Your Code with Inferable Types
  2. Use Different Variables for Different Types
  3. Understand Type Widening
  4. Understand Type Narrowing
  5. Create Objects All at Once
  6. Be Consistent in Your Use of Aliases
  7. Use async Functions Instead of Callbacks for Asynchronous Code
  8. Understand How Context Is Used in Type Inference
  9. Use Functional Constructs and Libraries to Help Types Flow

Chapter 4: Type Design

Code is difficult to understand if you can't see the data or data types on which it operates. This is one of the great advantages of a type system: by writing out types, you make them visible to readers of your code. And this makes your code understandable. Other chapters cover the nuts and bolts of TypeScript types: using them, inferring them, and writing declarations with them. This chapter discusses the design of the types themselves. The examples in this chapter are all written with TypeScript in mind, but most of the ideas are more broadly applicable.

  1. Prefer Types That Always Represent Valid States
  2. Be Liberal in What You Accept and Strict in What You Produce
  3. Don’t Repeat Type Information in Documentation
  4. Push Null Values to the Perimeter of Your Types
  5. Prefer Unions of Interfaces to Interfaces of Unions
  6. Prefer More Precise Alternatives to String Types
  7. Prefer Incomplete Types to Inaccurate Types
  8. Generate Types from APIs and Specs, Not Data
  9. Name Types Using the Language of Your Problem Domain
  10. Consider “Brands” for Nominal Typing

Chapter 5: Working with any

Type systems were traditionally binary affairs: either a language had a fully static type system or a fully dynamic one. TypeScript blurs the line, because its type system is optional and gradual. You can add types to parts of your program but not others. This is essential for migrating existing JavaScript codebases to TypeScript bit by bit. Key to this is the any type, which effectively disables type checking for parts of your code. It is both powerful and prone to abuse. Learning to use any wisely is essential for writing effective TypeScript. This chapter walks you through how to limit the downsides of any while still retaining its benefits.

  1. Use the Narrowest Possible Scope for any Types
  2. Prefer More Precise Variants of any to Plain any
  3. Hide Unsafe Type Assertions in Well-Typed Functions
  4. Understand Evolving any
  5. Use unknown Instead of any for Values with an Unknown Type
  6. Prefer Type-Safe Approaches to Monkey Patching
  7. Track Your Type Coverage to Prevent Regressions in Type Safety

Chapter 6: Types Declarations and @types

Dependency management can be confusing in any language, and TypeScript is no exception. This chapter will help you build a mental model for how dependencies work in TypeScript and show you how to work through some of the issues that can come up with them. It will also help you craft your own type declaration files to publish and share with others. By writing great type declarations, you can help not just your own project but the entire TypeScript community.

  1. Put TypeScript and @types in devDependencies
  2. Understand the Three Versions Involved in Type Declarations
  3. Export All Types That Appear in Public APIs
  4. Use TSDoc for API Comments
  5. Provide a Type for this in Callbacks
  6. Prefer Conditional Types to Overloaded Declarations
  7. Mirror Types to Sever Dependencies
  8. Be Aware of the Pitfalls of Testing Types

Chapter 7: Writing and Running Your Code

This chapter is a bit of a grab bag: it covers some issues that come up in writing code (not types) as well as issues you may run into when you run your code.

  1. Prefer ECMAScript Features to TypeScript Features
  2. Know How to Iterate Over Objects
  3. Understand the DOM hierarchy
  4. Don’t Rely on Private to Hide Information
  5. Use Source Maps to Debug TypeScript

Chapter 8. Migrating to TypeScript

You've heard that TypeScript is great. You also know from painful experience that maintaining your 15-year-old, 100,000-line JavaScript library isn't. If only it could become a TypeScript library! This chapter offers some advice about migrating your JavaScript project to TypeScript without losing your sanity and abandoning the effort.

  1. Write Modern JavaScript
  2. Use @ts-check and JSDoc to Experiment with TypeScript
  3. Use allowJs to Mix TypeScript and JavaScript
  4. Convert Module by Module Up Your Dependency Graph
  5. Don’t Consider Migration Complete Until You Enable noImplicitAny

About the Author

Dan Vanderkam

Dan Vanderkam is a principal software engineer at Sidewalk Labs, where he's built engineering teams and processes for all of its products and spinouts, all of which use TypeScript. He previously worked on open source genome visualizations at Mt. Sinai's Icahn School of Medicine and on Google search features used by billions of people (search for sunset nyc or population of france). He has a long history of working on open source projects, including the popular dygraphs library and source-map-explorer, a tool for visualizing JavaScript code size. He is also a co-founder of the NYC TypeScript Meetup.

When he's not programming, Dan enjoys climbing rocks and playing bridge. He writes on Medium and at danvk.org. He earned his bachelor's in computer science from Rice University in Houston, Texas, and lives in Brooklyn, New York.

Follow @danvdk Visit danvk.org