Patterns

Right, so you want to build a class that does one thing well, but you also want it to be able to do a dozen other, often unrelated, things. You could write a monolithic GodClass that does everything from sorting arrays to brewing coffee, but then you’d be stuck maintaining that monstrosity forever. Or, you could engage in the deeply tedious ritual of classical inheritance, chaining together extends statements until your class declaration looks like a family tree drawn by a bored medieval scribe.

Right, so you need events. You’ve outgrown passing callbacks around like hot potatoes and you’re ready for something that can handle the chaos of a real application. But you’re also in TypeScript, which means you’re not about to trade type safety for convenience. You want to know, at compile time, if you’re trying to emit 'userLoggedIn' with a string payload when your listener expects a User object. We’re not savages.

Right, so you’ve decided to build something that doesn’t turn into a tangled mess of new keywords and import spaghetti the moment it scales past “Hello, World.” Good. You’re in the right place. Dependency Injection (DI) is the practice of handing your classes their dependencies rather than letting them go out and construct those dependencies themselves. It’s the difference between a teenager rummaging through your fridge and you handing them a prepared plate of food. The outcome is the same (the food is eaten), but one method is chaotic and the other is controlled. A DI Container is just the fancy automated kitchen that prepares all the plates.

Right, so you’ve fallen in love with a library. It’s brilliant, it does 95% of what you need, but that last 5% is nagging at you. You need to add a .withSparkles() method to its main class. Your first instinct might be to fork the repo on GitHub and start hacking away. Don’t. That’s the path to maintenance hell, where you’re stuck managing your own private version forever, never able to upgrade.

Right, so you need a place to store things by a key and then get them back later. Your first thought is, “I know! Map<string, Something>.” And for a lot of cases, that’s fine. But what if Something isn’t an instance, but a class? And what if you don’t just want to retrieve it, but you want to instantiate it later, in a type-safe way, without resorting to as AnyClass hacks that’ll bite you later? Welcome to the Registry Pattern. It’s essentially a type-safe, fancy-pants factory that uses a map under the hood.

Right, so you want to build something that other people can extend. Maybe it’s a framework, a CLI tool, or a state management library. You’re smart enough to know you won’t think of every use case, so you decide to make it pluggable. This is where most developers reach for a void* in C or an any in TypeScript and call it a day. We are not most developers. We’re going to build an extension system that doesn’t make your users feel like they’re juggling chainsaws in the dark.

Right, let’s talk about fluent builders. You’ve seen them everywhere—jQuery’s $('#element').css('color', 'red').fadeOut(), your favorite query builder, that config object you can’t seem to stop chaining methods onto. They’re glorious. They turn a series of imperative, clunky statements into a single, readable, almost declarative sentence. But building one yourself in TypeScript? It’s a fantastic exercise in bending the type system to your will to create something that’s not just clever but genuinely pleasant and safe to use. The goal isn’t just method chaining; it’s intelligent method chaining where the types guide you and prevent you from making a complete mess.

Right, so you’ve met the optional chaining operator (?.), that brilliant little piece of syntactic sugar that lets you navigate potential null or undefined without blowing up your entire application. And you’ve probably also been introduced to the idea of Result (or Either) types, a more structured and type-safe way of representing failure than just throwing errors into the void and hoping someone catches them. You might be wondering: “Can I use these two beautiful things together?” The answer is a resounding “Yes, but… oh dear god, be careful.” It’s like using a chainsaw to make a fine wood carving. Powerful, but one wrong move and you’ve accidentally validated a null value as a successful operation. Let’s talk about how to do it right.

Right, let’s talk about error handling that doesn’t suck. You’ve probably been told a thousand times to “throw errors” and “catch” them. In the small, that’s fine. But at the application level, treating errors as a shocking, exceptional surprise is like being surprised by rain in London. It’s going to happen. The question is, are you prepared with an umbrella, or are you just going to get wet and complain?

Right, error boundaries. You’ve probably been told they’re React’s magic catch-all for errors in your component tree. And you’d be right, but also, like most magic, it’s mostly clever trickery with a few important limitations. I’m here to demystify it. The core idea is simple: a component that acts like a giant try/catch block for its entire subtree. When something in that tree blows up, this component catches the error, logs it, and displays a friendly “something went wrong” UI instead of letting the entire app vanish into the void. It’s your application’s immune system.

Right, let’s talk about error handling without throwing your toys out of the pram. You’ve probably been told a thousand times, “Don’t use exceptions for control flow!” It’s good advice. Exceptions are like shouting “FIRE!” in a crowded theatre—effective, but disruptive, and you can’t be sure who’s going to handle the panic. In TypeScript, they also completely bypass your type system. A function that throws lies about its return type; it says it returns a string but might instead yeet a WrenchError into your runtime.

Let’s be honest: you’ve probably handled errors by throwing them. It’s the JavaScript way, and TypeScript inherits it. You call a function, it blows up, you try/catch it. Simple, right? But it’s also incredibly rude. A function that throws is like a guest who, instead of saying “I’m allergic to shellfish,” just vomits on your table. You had no warning, and now you’re left cleaning up the mess. There’s a more polite, more predictable, and frankly, more type-safe way: the Result type. This isn’t a language feature; it’s a pattern. A design pattern where we encode success and failure into our type system, forcing us (and anyone using our code) to handle both outcomes. The compiler becomes our copilot, making it a compile-time error to forget that things can, and will, go wrong.

Right, let’s talk about one of the few things that can make error handling in TypeScript feel almost civilized: the instanceof pattern. You see, JavaScript’s native Error type is tragically anemic. It’s a blank slate with a message property and, if you’re lucky, a usable stack trace. Throwing around generic Error objects is like trying to fix a precision watch with a sledgehammer—it gets the job done, but good luck figuring out what went wrong afterwards.

Right, so you’ve decided to use try/catch in TypeScript. Good for you. It’s the responsible choice. You write your beautiful, type-safe code, you wrap the risky operation, and then you go to handle the error in the catch block. You type e and… wait a minute. What is this unknown nonsense? I can see your face. You were expecting an Error object, or maybe a string if some barbaric library threw one. Instead, TypeScript gives you this cosmic shrug. You feel like you’ve been robbed. “I know this function throws an Error!” you yell at your IDE. The IDE does not care.

Let’s be honest: you’ve been tempted. You see a function that takes a string and returns an int, and a little voice in your head whispers, “What if we need to handle other types later? We should make this generic now.” That voice is your inner architect, and while its intentions are noble, it’s often your enemy. In Go, the most powerful design tool is often the concrete type, and the most common design mistake is abandoning it too soon in favor of needless abstraction.

Right, let’s talk about table-driven design. You’ve probably already used this pattern without knowing its fancy name. It’s the moment you realize you’re about to write your fifth if or case statement for what is essentially the same operation, just on different data, and you scream “there has to be a better way!” There is. It’s called table-driven design, and it’s embarrassingly simple. Instead of a sprawling chain of conditional logic, you define your behavior in a data structure—a table—and then you write one, single, elegant loop to process it. The logic is decoupled from the data, which means your code becomes more readable, more testable, and infinitely easier to change and extend. It’s the difference between hand-carving each piece of a model and using a 3D printer. One is artisanally painful; the other is brilliantly efficient.

Right, let’s talk about errgroup. You’ve been there: you have a handful of goroutines doing work, and you need to wait for them all to finish, but if any of them fails, you want to cancel the whole operation immediately. You could roll this yourself with a sync.WaitGroup, some channels, and a context.Context for cancellation, but you’d be writing the same boilerplate for the tenth time this week. Stop that. The fine folks at the Go team felt your pain and gave us golang.org/x/sync/errgroup. It’s essentially a WaitGroup that understands errors and context.

Right, let’s talk about semaphores. You’ve probably heard the term in operating systems or concurrent programming—it’s a fancy word for a counter that controls access to a finite number of resources. In Go, we don’t have a semaphore package in the standard library. Why? Because we can build a perfectly good one, a weighted one at that, in about three lines of code using a buffered channel. It’s one of those elegant “less is more” designs that makes you appreciate Go’s simplicity, even if you occasionally want to throw your keyboard at it.

Right, the Worker Pool pattern. You’ve hit that beautiful moment in your Go journey where you realize that just slapping a go keyword in front of every function call is a fantastic way to trigger a cascading failure, get rate-limited into the next decade, or simply melt your machine’s CPU. Congratulations! Welcome to the big leagues, where we think about bounding our concurrency instead of just unleashing it like a herd of cats.

Right, let’s talk about the pipeline pattern. You’ve probably got some data that needs a series of operations performed on it: fetch it, process it, filter it, transform it, store it. You could write one big, gnarly function that does all of that. But then you’d have a monster that’s impossible to test, reason about, or modify without breaking three other things. We’re better than that. The pipeline pattern is our escape hatch. We break that big process into discrete stages, each a separate goroutine, connected by channels. Data flows in one end, gets worked on, and flows out the other. It’s like an assembly line for your data, and it’s one of the most elegant ways to structure concurrent programs in Go. It makes your code modular, testable, and frankly, a joy to work with.

Right, let’s settle this. You’re about to configure a thing in Go—a server, a client, a database connection, some complex monstrosity you built. You quickly realize your constructor function is getting out of hand. It’s starting to look like NewThing(host string, port int, timeout time.Duration, enableLogging bool, maxRetries int, name string, fluxCapacitorCapacity float64) and it’s an unreadable, unmaintainable mess. You need a pattern. You’ve likely seen two: the Options Struct and Functional Options. Let’s break down why both exist and when to use which.

Let’s be honest: you’ve seen this before. You’re trying to create a Thing, and its constructor is a nightmare. You either have a function with fourteen arguments where the last nine are almost always the same, or you’ve got a dozen different NewThingWithXAndYButNotZ constructors. It’s a mess. It’s un-Go-like. It’s exactly the kind of ceremony we’re trying to avoid. Enter the Functional Options pattern. This is one of those patterns that looks like magic the first time you see it, but once you understand it, you’ll wonder how you ever lived without it. The core idea is simple: we pass a variadic slice of functions to our constructor, and each function operates on the struct we’re building. It’s configuration with a functional flair.