Josh Goldberg

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 componentsThinking 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!

TypeScript's type system is incredibly powerful. It can represent bizarrely complex interdependent JavaScript types and comes with a Turing-complete set of logical conditions. But this is a React conference, right? Let's implement a primitive React purely in the type system. For fun!

Most CSS developers today write visual styles in terms of what you literally see: exact color values, size numbers, and so on. But what if you could write styles as a function of how they fit into your design system? And what if you could get type safety in specifying and using those values, including in responsive props?

This talk will dive into some of the key features and flaws in many design system builders today such as Chakra UI and Tailwind. We'll establish what the best next steps for design systems should be with type-safe TypeScript APIs and performance both for prebuilt pages and at runtime.

Next.js and other wrapping React frameworks provide great power in building larger applications. But with great power comes great performance responsibility - and if you don’t pay attention, it’s easy to add multiple seconds of loading penalty on all of your pages. Eek! Let’s walk through a case study of how a few hours of performance debugging improved both load and parse times for the Centered app by several hundred percent each. We’ll learn not just why those performance problems happen, but how to diagnose and fix them. Hooray, performance! ⚡️

There are amazing tools out there providing you with excellent type safety. But when you get to the client-side fetching, things go wild. Even if you have perfectly typed backed, you lose the type information during the client-side communication. Yes, you can use GraphQL or protobuf and generate types, but... what if I told you there's an easier way? A way that lets you develop your apps smoother than with REST or GraphQL? How? RPC! Say hi to maximum productivity with fantastic developer experience.

Modern frontend applications want to efficiently query data on page load and navigate, format the data with TypeScript, and cache data between repeat requests. Setting that all up on your own is a chore... but with Apollo and Next.js, you can set up your client to auto-generate TypeScript types, cache query results intelligently, and generally be a breeze to work with.

TypeScript is great, but migrating an existing app to it can be a pain. Codecademy took multiple existing React apps and converted them to TypeScript. We'll cover how to make those kinds of conversions successful from both cultural and technical standpoints.