Everybody seems to be talking about "types" these days. From the TypeScript language to type description utilities such as prop-types and Zod, developers expect clear descriptions of the shapes of their React components, data, and hooks. Let's talk about the mindset shift that's happened over the last decade, and where types are taking us over the next one.

Brief foundations: what is TypeScript, what "type safety" means, and setting up TypeScript in a React (Next.js) projectA history of how type safety has worked in React, starting with class components

Thinking in Type(s|Script): How modeling value shapes helps raise predictability and understandability, especially in the wildest and wackiest of React architectures.

TypeScript's Limitations: By design, TypeScript can only act as a development-time type system and enforce what that system can represent. We'll want to go over what can't and/or shouldn't be represented in that type system.

Raising the Runtime: Moving those type thoughts into your React runtime with programmatic frameworks or libraries such as tRPC and Zod - especially as they integrate with React metaframeworks like Next.js and Remix.

React Specifics: How this "types-first" theory works helps improve common parts of projects in the React ecosystem: from prop-types back in the day to REST or RPC endpoints, testing, and documentation today.

ESLint lint rules to catch common async and React code bugs - and why the language is designed to let you do those dangerous things in the first place.

Ecosystem future: where the TC39 types-as-comments proposal will -and won't- take types at a language-level for JavaScript in general and React apps specifically.

By allowing our types to be a reflection of the runtime reality, we embrace types-first thinking in designing code - making our code more clear to read and update. These better-define boundaries help in everything from better-defined React component boundaries to auto-generated client<>server API bridges. Hooray, types!

Pre-Events