TypeScript's discriminated unions are a powerful feature that take pattern matching to the next level. They allow us to create complex, type-safe conditional logic that goes beyond simple switch statements. I've been using this technique extensively in my recent projects, and it's transformed how I approach control flow in TypeScript.
Let's start with the basics. A discriminated union is a type that uses a common property to distinguish between different variants. Here's a simple example:
type Shape =
| { kind: 'circle'; radius: number }
| { kind: 'rectangle'; width: number; height: number }
The 'kind' property here is our discriminant. It allows TypeScript to infer which specific shape we're dealing with based on its value.
Now, let's see how we can use this for pattern matching:
function getArea(shape: Shape): number {
switch (shape.kind) {
case 'circle':
return Math.PI * shape.radius ** 2
case 'rectangle':
return shape.width * shape.height
}
}
This is neat, but it's just the beginning. We can take this much further.
One of the most powerful aspects of discriminated unions is exhaustiveness checking. TypeScript can ensure we've handled all possible cases in our pattern matching. Let's add a new shape to our union:
type Shape =
| { kind: 'circle'; radius: number }
| { kind: 'rectangle'; width: number; height: number }
| { kind: 'triangle'; base: number; height: number }
function getArea(shape: Shape): number {
switch (shape.kind) {
case 'circle':
return Math.PI * shape.radius ** 2
case 'rectangle':
return shape.width * shape.height
// TypeScript will now warn us that we're not handling the 'triangle' case
}
}
To make this even more robust, we can add a default case that throws an error, ensuring we never accidentally forget to handle a new case:
function assertNever(x: never): never {
throw new Error("Unexpected object: " + x);
}
function getArea(shape: Shape): number {
switch (shape.kind) {
case 'circle':
return Math.PI * shape.radius ** 2
case 'rectangle':
return shape.width * shape.height
case 'triangle':
return 0.5 * shape.base * shape.height
default:
return assertNever(shape)
}
}
Now, if we ever add a new shape without updating our getArea function, TypeScript will give us a compile-time error.
But we can go even further with pattern matching. Let's look at a more complex example involving nested patterns.
Imagine we're building a simple state machine for a traffic light:
type TrafficLightState =
| { state: 'green' }
| { state: 'yellow' }
| { state: 'red' }
| { state: 'flashing', color: 'yellow' | 'red' }
function getNextState(current: TrafficLightState): TrafficLightState {
switch (current.state) {
case 'green':
return { state: 'yellow' }
case 'yellow':
return { state: 'red' }
case 'red':
return { state: 'green' }
case 'flashing':
return current.color === 'yellow'
? { state: 'red' }
: { state: 'flashing', color: 'yellow' }
}
}
Here, we're not just matching on the top-level state, but also on nested properties when we're in the 'flashing' state.
We can also use guards to add even more complex conditions to our pattern matching:
type WeatherEvent =
| { kind: 'temperature', celsius: number }
| { kind: 'wind', speed: number }
| { kind: 'precipitation', amount: number }
function describeWeather(event: WeatherEvent): string {
switch (event.kind) {
case 'temperature':
if (event.celsius > 30) return "It's hot!"
if (event.celsius < 0) return "It's freezing!"
return "The temperature is moderate."
case 'wind':
if (event.speed > 100) return "There's a hurricane!"
if (event.speed > 50) return "It's very windy."
return "There's a gentle breeze."
case 'precipitation':
if (event.amount > 100) return "It's pouring!"
if (event.amount > 0) return "It's raining."
return "It's dry."
}
}
This pattern matching approach isn't limited to switch statements. We can use it with if-else chains, or even with object literals for more complex scenarios:
type Action =
| { type: 'INCREMENT' }
| { type: 'DECREMENT' }
| { type: 'RESET' }
| { type: 'SET', payload: number }
const reducer = (state: number, action: Action): number => ({
INCREMENT: () => state + 1,
DECREMENT: () => state - 1,
RESET: () => 0,
SET: () => action.payload,
}[action.type]())
This approach can be particularly useful when implementing the visitor pattern. Here's an example of how we might use discriminated unions to implement a simple expression evaluator:
type Expr =
| { kind: 'number'; value: number }
| { kind: 'add'; left: Expr; right: Expr }
| { kind: 'multiply'; left: Expr; right: Expr }
const evaluate = (expr: Expr): number => {
switch (expr.kind) {
case 'number':
return expr.value
case 'add':
return evaluate(expr.left) + evaluate(expr.right)
case 'multiply':
return evaluate(expr.left) * evaluate(expr.right)
}
}
const expr: Expr = {
kind: 'add',
left: { kind: 'number', value: 5 },
right: {
kind: 'multiply',
left: { kind: 'number', value: 3 },
right: { kind: 'number', value: 7 }
}
}
console.log(evaluate(expr)) // Outputs: 26
This pattern allows us to easily extend our expression system with new types of expressions, and TypeScript will ensure we handle all cases in our evaluate function.
One of the most powerful aspects of this approach is how it allows us to refactor large, complex conditional blocks into more manageable and extendable structures. Let's look at a more complex example:
Imagine we're building a system to process different types of financial transactions:
type Transaction =
| { kind: 'purchase', amount: number, item: string }
| { kind: 'refund', amount: number, reason: string }
| { kind: 'transfer', amount: number, to: string }
| { kind: 'deposit', amount: number }
| { kind: 'withdrawal', amount: number }
type TransactionProcessor = {
[K in Transaction['kind']]: (transaction: Extract<Transaction, { kind: K }>) => void
}
const processTransaction: TransactionProcessor = {
purchase: ({ amount, item }) => {
console.log(`Processing purchase of ${item} for $${amount}`)
// Implement purchase logic
},
refund: ({ amount, reason }) => {
console.log(`Processing refund of $${amount} for reason: ${reason}`)
// Implement refund logic
},
transfer: ({ amount, to }) => {
console.log(`Processing transfer of $${amount} to ${to}`)
// Implement transfer logic
},
deposit: ({ amount }) => {
console.log(`Processing deposit of $${amount}`)
// Implement deposit logic
},
withdrawal: ({ amount }) => {
console.log(`Processing withdrawal of $${amount}`)
// Implement withdrawal logic
}
}
function handleTransaction(transaction: Transaction) {
processTransaction[transaction.kind](transaction as any)
}
In this example, we've used TypeScript's mapped types and conditional types to create a type-safe object where each key corresponds to a transaction kind, and each value is a function that processes that specific type of transaction. This approach allows us to easily add new types of transactions without changing the core logic of our handleTransaction function.
The beauty of this pattern is that it's both type-safe and extensible. If we add a new type of transaction, TypeScript will force us to add a corresponding processor function. If we try to process a transaction kind that doesn't exist, we'll get a compile-time error.
This pattern matching approach with discriminated unions can lead to more expressive, safer, and self-documenting TypeScript code, especially in complex applications. It allows us to handle complex logic in a way that's both readable and maintainable.
As our applications grow in complexity, these techniques become increasingly valuable. They allow us to write code that's not only correct, but also easy to understand and modify. By leveraging TypeScript's type system to its fullest, we can create robust, flexible systems that are a joy to work with.
Remember, the goal isn't just to write code that works, but to write code that clearly expresses its intent and is resistant to errors as requirements change. Pattern matching with discriminated unions is a powerful tool in achieving this goal.
In my experience, adopting these patterns has led to significant improvements in code quality and development speed. It takes some time to get used to thinking in terms of discriminated unions and exhaustive pattern matching, but once you do, you'll find it opens up new possibilities for structuring your code in clear, type-safe ways.
As you continue to explore TypeScript, I encourage you to look for opportunities to apply these patterns in your own code. Start small, perhaps by refactoring a complex if-else chain into a discriminated union. As you become more comfortable with the technique, you'll start to see more and more places where it can be applied to simplify and clarify your code.
Remember, the true power of TypeScript lies not just in its ability to catch errors, but in its ability to guide us towards better, more expressive code structures. By embracing patterns like discriminated unions and exhaustive pattern matching, we can create code that's not only correct, but also a pleasure to read and maintain.
Our Creations
Be sure to check out our creations:
Investor Central | Smart Living | Epochs & Echoes | Puzzling Mysteries | Hindutva | Elite Dev | JS Schools
We are on Medium
Tech Koala Insights | Epochs & Echoes World | Investor Central Medium | Puzzling Mysteries Medium | Science & Epochs Medium | Modern Hindutva
Top comments (0)