7 TypeScript Patterns I Use in Every Project
These aren't groundbreaking. They're the boring patterns that prevent bugs and save hours of debugging.
1. The Result Type (No More try/catch Hell)
// Instead of throwing exceptions everywhere:
function divide(a: number, b: number): number {
if (b === 0) throw new Error("Division by zero");
return a / b;
}
// Use a Result type:
type Result<T, E = Error> =
| { ok: true; value: T }
| { ok: false; error: E };
function divide(a: number, b: number): Result<number, string> {
if (b === 0) return { ok: false, error: "Division by zero" };
return { ok: true, value: a / b };
}
// Usage — the compiler FORCES you to handle errors:
const result = divide(10, 0);
if (result.ok) {
console.log(result.value); // TypeScript knows this is number
} else {
console.error(result.error); // TypeScript knows this is string
}
Why this matters: No more "undefined is not a function" because you forgot a try/catch. The type system enforces error handling.
2. Branded Types (Prevent Mixing Up IDs)
// The problem:
function getUser(id: string) { /* ... */ }
function getPost(id: string) { /* ... */ }
// Easy to mix up:
getUser(postId); // TypeScript allows this! But it's wrong!
// The fix — branded types:
type UserId = string & { readonly __brand: 'UserId' };
type PostId = string & { readonly __brand: 'PostId' };
function createUser(id: string): UserId {
return id as UserId;
}
function getUser(id: UserId) { /* ... */ }
function getPost(id: PostId) { /* ... */ }
const userId = createUser('abc');
getUser(userId); // ✅ Works
// getPost(userId); // ❌ TypeScript error! Type 'UserId' is not assignable to 'PostId'
When to use: Anytime you have multiple IDs that look the same (userId, orderId, sessionId) but mean different things.
3. The Builder Pattern for Complex Objects
interface Config {
host: string;
port: number;
database: string;
ssl: boolean;
poolSize: number;
timeout: number;
}
class ConfigBuilder {
private config: Partial<Config> = {};
static create() {
return new ConfigBuilder();
}
withHost(host: string) {
this.config.host = host;
return this; // Chain!
}
withPort(port: number) {
this.config.port = port;
return this;
}
withDatabase(database: string) {
this.config.database = database;
return this;
}
withSSL(ssl = true) {
this.config.ssl = ssl;
return this;
}
withPoolSize(size: number) {
this.config.poolSize = size;
return this;
}
build(): Config {
if (!this.config.host) throw new Error('host is required');
if (!this.config.database) throw new Error('database is required');
return {
host: this.config.host,
port: this.config.port ?? 5432,
database: this.config.database,
ssl: this.config.ssl ?? false,
poolSize: this.config.poolSize ?? 10,
timeout: this.config.timeout ?? 5000,
};
}
}
// Usage — readable, flexible, with defaults:
const config = ConfigBuilder.create()
.withHost('localhost')
.withDatabase('myapp')
.withSSL()
.withPoolSize(20)
.build();
4. Strict Event Emitter Types
// Instead of the loose EventEmitter from Node:
import { EventEmitter } from 'events';
const emitter = new EventEmitter();
emitter.on('data', (payload: unknown) => { /* type safety? nah */ });
emitter.emit('data', 123); // No type check
emitter.emit('typo', 'anything'); // No type check
// Strict typed version:
type EventMap = {
'user:login': { userId: string; timestamp: Date };
'user:logout': { userId: string };
'error': { message: string; code: number };
'data:update': { key: string; value: unknown };
};
class TypedEmitter<Events extends Record<string, unknown>> {
private emitter = new EventEmitter();
on<K extends keyof Events & string>(
event: K,
handler: (payload: Events[K]) => void
) {
this.emitter.on(event, handler as (...args: unknown[]) => void);
return () => this.emitter.off(event, handler as (...args: unknown[]) => void);
}
emit<K extends keyof Events & string>(
event: K,
payload: Events[K]
) {
this.emitter.emit(event, payload);
}
}
// Usage — fully typed:
const bus = new TypedEmitter<EventMap>();
bus.on('user:login', (payload) => {
console.log(payload.userId); // TypeScript knows this is string
console.log(payload.timestamp); // TypeScript knows this is Date
});
bus.on('error', (payload) => {
console.log(payload.code); // TypeScript knows this is number
});
// bus.emit('user:login', { userId: 123 }); // ❌ Error: string expected
// bus.emit('nonexistent', {}); // ❌ Error: not in EventMap
5. The Guard Pattern (Narrow Types in Functions)
interface User {
id: string;
name: string;
role: 'admin' | 'editor' | 'viewer';
email?: string; // Might not be set
}
// Instead of checking everywhere:
function sendEmail(user: User) {
if (!user.email) throw new Error('No email');
// TypeScript still thinks email might be undefined here in some cases
}
// Use type guards:
function hasEmail(user: User): user is User & { email: string } {
return typeof user.email === 'string' && user.email.length > 0;
}
function isAdmin(user: User): user is User & { role: 'admin' } {
return user.role === 'admin';
}
// Now TypeScript knows:
function sendEmail(user: User) {
if (!hasEmail(user)) return; // Guard clause
console.log(user.email.toLowerCase()); // ✅ TypeScript knows email is string
}
function deleteEverything(user: User) {
if (!isAdmin(user)) throw new Error('Unauthorized');
// ✅ TypeScript knows role is 'admin' here
}
6. Zod for Runtime Validation
import { z } from 'zod';
// Define schema once — use for both types AND runtime validation
const UserSchema = z.object({
id: z.string().uuid(),
name: z.string().min(1).max(100),
email: z.string().email(),
role: z.enum(['admin', 'editor', 'viewer']),
createdAt: z.string().datetime(),
});
// Infer TypeScript type from schema
type User = z.infer<typeof UserSchema>;
// Validate API responses at runtime:
async function fetchUser(id: string): Promise<User> {
const response = await fetch(`/api/users/${id}`);
const data = await response.json();
// This throws if data doesn't match schema
return UserSchema.parse(data);
}
// Safe parse (doesn't throw):
const result = UserSchema.safeParse(mysteryData);
if (result.success) {
const user: User = result.data;
} else {
console.error(result.error.flatten());
}
Why Zod over Joi/ Yup? Type inference. Your schema IS your type definition. No duplication.
7. The Async Pool Pattern
// When you need to run many async operations but limit concurrency:
async function asyncPool<T>(
concurrency: number,
items: T[],
fn: (item: T, index: number) => Promise<void>
): Promise<void> {
const executing = new Set<Promise<void>>();
for (const [index, item] of items.entries()) {
const promise = fn(item, index).then(() => {
executing.delete(promise);
});
executing.add(promise);
if (executing.size >= concurrency) {
await Promise.race(executing);
}
}
await Promise.all(executing);
}
// Usage — fetch 100 URLs but only 5 at a time:
const urls = Array.from({ length: 100 }, (_, i) => `https://api.example.com/page/${i}`);
await asyncPool(5, urls, async (url) => {
const response = await fetch(url);
if (!response.ok) console.error(`Failed: ${url}`);
});
// Compare with naive approach (all at once — might crash):
// await Promise.all(urls.map(url => fetch(url))); // 💥 Too many connections
Bonus: The Never-Returning Function
// For functions that always throw (assertions, unreachable code):
function assert(condition: unknown, message: string): asserts condition {
if (!condition) throw new Error(message);
}
function unreachable(x: never): never {
throw new Error(`Unreachable code reached: ${x}`);
}
// Usage:
type Status = 'loading' | 'success' | 'error';
function handleStatus(status: Status): string {
switch (status) {
case 'loading': return 'Loading...';
case 'success': return 'Done!';
case 'error': return 'Failed!';
}
// If you add a new status type, TypeScript will error here
// because the switch is no longer exhaustive
}
Which patterns do you use daily? Drop your favorites in the comments.
Follow @armorbreak for more TypeScript and Node.js content.