TypeScript Tips That Actually Matter in Real Projects (including the satisfies operator)

A developer shares eight TypeScript patterns that improve code safety and maintainability in real projects, including the satisfies operator, as const, discriminated unions, and utility types like Partial, Pick, and Omit. The post emphasizes using TypeScript's type system to prevent impossible states and keep type definitions in sync.

Most TypeScript tutorials teach you the language. This article teaches you how to use it. There's a difference. The language has hundreds of features. A real project uses maybe twenty of them regularly, and about eight of them make up the difference between TypeScript that fights you and TypeScript that helps you. These are those eight. Each one comes from a pattern I've seen repeatedly in real codebases: first as an antipattern, then as a realization, then as a habit. The goal isn't to show off advanced type gymnastics. It's to show you the specific things that make your code safer, more readable, and less painful to maintain. any , manual casting, and loose types are the usual culprits. satisfies , as const , generics, solve the majority of real-world typing problems. satisfies to Validate Without Losing Inference as const for Literal Types That Don't Drift ReturnType and Parameters to Stay in Sync unknown Instead of any for External DataThis is the tip that changes how you model data in TypeScript. Once you see it, you'll spot the antipattern everywhere. // ❌ A type that tries to represent multiple states with optional fields interface ApiResponse { data?: User error?: string isLoading: boolean } The problem: this type allows impossible states. Nothing stops you from having both data and error set at the same time, or neither set, or isLoading: false with no data and no error . The type says "any combination of these fields is valid." Your domain says only three combinations are valid: loading, success, or error. The type isn't telling the truth. // ✅ Each state is explicit and mutually exclusive type ApiResponse<T = | { status: 'loading' } | { status: 'success'; data: T } | { status: 'error'; error: string } Now TypeScript knows exactly which fields exist in each state. When you narrow on status , you get precise autocomplete and type safety: function renderUser response: ApiResponse<User { switch response.status { case 'loading': return 'Loading...' case 'success': return response.data.name // TypeScript knows data exists here case 'error': return response.error // TypeScript knows error exists here } } If you add a new state to ApiResponse and forget to handle it in the switch, TypeScript tells you. That's the real payoff: exhaustiveness checking . The type system enforces that every case is handled. This pattern is especially powerful for modelling form states, async operations, and anything with multiple mutually exclusive conditions. TypeScript ships with a set of built-in utility types that most developers underuse. They exist specifically to prevent you from duplicating type definitions. // ❌ Manually maintaining two overlapping types interface User { id: string email: string firstName: string lastName: string role: 'admin' | 'user' createdAt: string } // Manually duplicated, will drift from User when User changes interface UpdateUserPayload { email?: string firstName?: string lastName?: string } // Manually duplicated again interface UserPreview { id: string firstName: string lastName: string } When User changes, you have to remember to update every manual derivative. You won't always remember. // ✅ Derived from the source of truth, always in sync interface User { id: string email: string firstName: string lastName: string role: 'admin' | 'user' createdAt: string } // Partial makes all fields optional type UpdateUserPayload = Partial<Pick<User, 'email' | 'firstName' | 'lastName' // Pick selects specific fields type UserPreview = Pick<User, 'id' | 'firstName' | 'lastName' // Omit removes specific fields type UserWithoutMeta = Omit<User, 'createdAt' | 'role' // Required makes all fields required opposite of Partial type StrictUser = Required<User // Readonly makes all fields immutable type ImmutableUser = Readonly<User The key insight: UpdateUserPayload is now derived from User . When you add a field to User , you decide whether to include it in the derived types, but the base type is the single source of truth. A practical combination that appears constantly in REST APIs: // Create payload: no id or metadata, those are server-generated type CreateUserPayload = Omit<User, 'id' | 'createdAt' // Update payload: everything optional except what can't change type UpdateUserPayload = Partial<Omit<User, 'id' | 'createdAt' | 'role' satisfies to Validate Without Losing Inference satisfies was introduced in TypeScript 4.9 and is still underused. It solves a specific problem that as and explicit type annotations both fail to handle cleanly. When you annotate a variable with a type, TypeScript widens the inferred type to match the annotation, and you lose specific information: js // ❌ Explicit annotation loses specific type information const config: Record<string, string = { host: 'localhost', port: '5432', } config.host // type: string, you've lost 'localhost' config.nonExistent // No error The index signature allows any key When you skip the annotation, you get precise inference but no validation against a shape: js // ❌ No annotation, no validation const config = { host: 'localhost', port: '5432', } config.host // type: 'localhost' ✅ config.nonExistent // Error ✅, but you have no shape validation satisfies // ✅ Validates against the shape AND preserves specific types type AppConfig = { host: string port: string database: string } const config = { host: 'localhost', port: '5432', database: 'myapp', unknownKey: 'oops', // ❌ Error: Object literal may only specify known properties } satisfies AppConfig config.host // type: 'localhost', specific type preserved ✅ satisfies tells TypeScript: "validate that this value matches this type, but infer the most specific type possible." You get the validation of an annotation and the precision of inference. Especially useful for configuration objects, theme definitions, and route maps: js type Routes = Record<string, { path: string; exact?: boolean } const routes = { home: { path: '/' }, about: { path: '/about' }, profile: { path: '/profile/:id', exact: true }, } satisfies Routes routes.home.path // type: '/', not just string routes.unknown // ❌ Error, unknown key caught at compile time as const for Literal Types That Don't Drift as const is one of the most practical tools in TypeScript for working with fixed sets of values. It tells the compiler: "don't widen this, keep every value as its literal type." js // ❌ TypeScript widens these to string , you lose the specific values const STATUSES = 'pending', 'active', 'cancelled', 'completed' type Status = typeof STATUSES number // type: string, not what you wanted js // ✅ as const preserves literal types const STATUSES = 'pending', 'active', 'cancelled', 'completed' as const type Status = typeof STATUSES number // type: 'pending' | 'active' | 'cancelled' | 'completed' ✅ // The array itself is also typed precisely const firstStatus = STATUSES 0 // type: 'pending' This pattern is particularly powerful for objects used as enums or configuration maps: js const HTTP CODES = { OK: 200, CREATED: 201, BAD REQUEST: 400, UNAUTHORIZED: 401, NOT FOUND: 404, INTERNAL ERROR: 500, } as const type HttpCode = typeof HTTP CODES keyof typeof HTTP CODES // type: 200 | 201 | 400 | 401 | 404 | 500 function handleResponse code: HttpCode { // TypeScript knows exactly which values are valid } handleResponse HTTP CODES.OK // ✅ handleResponse 999 // ❌ Error: 999 is not assignable to HttpCode as const also pairs naturally with discriminated unions: define your discriminant values as constants, derive the union type, and you have a single source of truth for both runtime values and compile-time types. Type casting with as is the TypeScript equivalent of // eslint-disable , it silences the compiler without solving the problem. Every as is a place where TypeScript's safety guarantee ends. // ❌ Casting tells TypeScript to trust you, and you might be wrong async function fetchUser id: string { const response = await fetch /api/users/${id} const data = await response.json return data as User // TypeScript believes you. The runtime doesn't care. } If the API returns a different shape than User , TypeScript won't tell you. The bug surfaces at runtime, in production, when someone accesses user.firstName and gets undefined . // ✅ Validate the shape at runtime, TypeScript trusts what you verify function isUser value: unknown : value is User { return typeof value === 'object' && value == null && 'id' in value && 'email' in value && 'firstName' in value && typeof value as any .id === 'string' && typeof value as any .email === 'string' } async function fetchUser id: string : Promise<User { const response = await fetch /api/users/${id} const data: unknown = await response.json if isUser data { throw new Error Invalid user response for id: ${id} } return data // TypeScript now knows this is User, and it's been verified } The value is User return type is a type predicate : it tells TypeScript that if the function returns true , the value can be treated as User in the narrowed scope. For production codebases with complex external data, consider Zod for runtime validation, it generates TypeScript types from schemas and validates data at the boundary in one step. We covered the full pattern in API Calls Done Right https://dev.to/gavincettolo/api-calls-done-right . Generics are the feature most developers avoid the longest, and regret avoiding. They're the tool that lets you write a function once and have it work correctly across multiple types, without sacrificing type safety. // ❌ Three functions doing the same thing for different types function getFirstUser items: User : User | undefined { return items 0 } function getFirstProduct items: Product : Product | undefined { return items 0 } function getFirstOrder items: Order : Order | undefined { return items 0 } Or worse, using any to avoid repetition: // ❌ any kills type safety entirely function getFirst items: any : any { return items 0 } // ✅ One function, full type safety across all types function getFirst<T items: T : T | undefined { return items 0 } const firstUser = getFirst users // type: User | undefined const firstProduct = getFirst products // type: Product | undefined const firstNumber = getFirst 1, 2, 3 // type: number | undefined Generics become especially powerful with constraints, limiting which types are accepted: // Only works with objects that have an id field function findById<T extends { id: string } items: T , id: string : T | undefined { return items.find item = item.id === id } findById users, 'user-1' // ✅ User has id findById products, 'prod-1' // ✅ Product has id findById 1, 2, 3 , 'x' // ❌ Error: number doesn't have id A real-world example, a typed API fetcher: js async function apiFetch<T url: string : Promise<T { const response = await fetch url if response.ok throw new Error HTTP error: ${response.status} return response.json as Promise<T } // The return type is inferred from the type parameter const user = await apiFetch<User '/api/users/1' // type: User const products = await apiFetch<Product '/api/products' // type: Product The rule of thumb: when you find yourself writing the same function structure for multiple types, that's a generic waiting to be extracted. ReturnType and Parameters to Stay in Sync When you call a function from an external library, or from another part of your codebase, you often need types that match its return value or arguments. The naive approach is to manually write those types. The problem is that manual types drift. // ❌ Manually written type that will drift from the actual function interface UserServiceResult { id: string name: string // ...but what if userService.getUser changes? } function processUser user: UserServiceResult { // ... } When userService.getUser adds a new field, UserServiceResult doesn't update automatically. You have a type that lies about the actual data. ReturnType and Parameters // ✅ Types derived directly from the functions, always in sync function getUser id: string { return { id, firstName: 'Gavin', lastName: 'Cettolo', role: 'admin' as const, createdAt: new Date .toISOString , } } // Automatically matches whatever getUser returns type User = ReturnType<typeof getUser // Automatically matches whatever getUser accepts type GetUserParams = Parameters<typeof getUser // type: id: string function processUser user: User { // user has exactly the shape of getUser's return value // If getUser changes, processUser is immediately aware console.log user.firstName } This is particularly useful when working with third-party libraries where you don't control the type definitions: js import { createStore } from 'some-library' // Extract the return type without importing a separate type type Store = ReturnType<typeof createStore // Extract what the function expects type StoreConfig = Parameters<typeof createStore 0 Other intrinsic utility types worth knowing alongside these: Awaited<T , unwraps a Promise type: Awaited<Promise<User → User InstanceType<T , extracts the instance type from a constructor unknown Instead of any for External Data any is TypeScript's escape hatch. It tells the compiler: "I know what I'm doing, stop checking." The problem is that you often don't know, especially with external data. unknown is the safe alternative. It represents a value you haven't inspected yet. TypeScript forces you to narrow it before you can use it. // ❌ any propagates silently, errors hide until runtime function parseConfig raw: any { return { port: raw.port, // No error even if raw.port doesn't exist host: raw.host.trim , // Runtime crash if host is undefined debug: raw.debug, } } With any , TypeScript assumes every property access and method call is valid. Errors surface at runtime, not at compile time. unknown with narrowing // ✅ unknown forces you to verify before you use function parseConfig raw: unknown : AppConfig { if typeof raw == 'object' || raw === null || 'port' in raw || 'host' in raw { throw new Error 'Invalid config shape' } const { port, host } = raw as { port: unknown; host: unknown } if typeof port == 'number' || typeof host == 'string' { throw new Error 'Invalid config field types' } return { port, host } } The places where unknown matters most: js // API responses const data: unknown = await response.json // Error handling, errors thrown in try/catch are unknown try { await riskyOperation } catch error: unknown { if error instanceof Error { console.error error.message // Safe: TypeScript knows it's an Error } } // JSON.parse, the return type is any by default, worth narrowing immediately const parsed: unknown = JSON.parse rawString The rule: use any only when you're in a migration path from untyped code and you need to move fast. For all external data boundaries, APIs, JSON parsing, error handling, use unknown and narrow explicitly. Three more patterns that didn't make the full treatment but are worth knowing. // Generate precise string types programmatically type EventName = 'click' | 'focus' | 'blur' type HandlerName = on${Capitalize<EventName } // type: 'onClick' | 'onFocus' | 'onBlur' type ApiEndpoint = /api/v1/${'users' | 'products' | 'orders'} // type: '/api/v1/users' | '/api/v1/products' | '/api/v1/orders' Especially useful for event handler naming, API route typing, and CSS class generation. never for Exhaustiveness Checking // TypeScript will error if you forget to handle a case function assertNever value: never : never { throw new Error Unhandled case: ${JSON.stringify value } } type Shape = 'circle' | 'square' | 'triangle' function getArea shape: Shape, size: number : number { switch shape { case 'circle': return Math.PI size 2 case 'square': return size 2 case 'triangle': return Math.sqrt 3 / 4 size 2 default: return assertNever shape // Error if a case is missing } } If you add 'hexagon' to Shape and forget to add a case in the switch, TypeScript will error at the assertNever call. Zero runtime surprises. // ❌ Loose index signature, any string key is valid interface Config { key: string : string } // ✅ Prefer Record with a union of known keys type Config = Record<'host' | 'port' | 'database', string // Or use satisfies + as const for maximum precision const config = { host: 'localhost', port: '5432', database: 'myapp', } satisfies Record<string, string Index signatures are sometimes necessary, but when you know the possible keys upfront, Record with a union type gives you better autocomplete and stricter validation. TypeScript's value isn't in the number of features you use. It's in using the right features precisely. The eight tips in this article share a common thread: they're all about making the type system reflect the real constraints of your domain. Discriminated unions that model actual states. Utility types that derive from a single source of truth. unknown that forces you to verify before you use. TypeScript that fights you is usually TypeScript that's been used loosely, any where there should be unknown , optional fields where there should be discriminated unions, manual types where there should be inference. TypeScript that helps you is TypeScript that's been used precisely. The difference isn't complexity. It's intention. Which of these tips was new to you, and which one are you already using? Drop it in the comments. And if there's a TypeScript pattern that's saved you hours in a real project, share it, the best tips in these threads always come from the comments. If this was useful, a ❤️ or a 🦄 means a lot. And follow along for the next article in the series.