The Everyday Problem with null | undefined

If you have spent any significant amount of time with JavaScript or TypeScript, you are intimately familiar with null and undefined. They are the dark matter of our codebases - invisible until they pull everything into a black hole of runtime errors.

We use them because they are convenient. They are the default state of “nothingness” in the language. When a function doesn’t return a value, it returns undefined. When we want to clear a variable explicitly, we might set it to null. It feels natural because it is built into the syntax.

However, this convenience comes at a subtle, accruing cost. A null and undefined are often treated as "values," but they behave like anti-values. They break the contract of our types. If a variable is typed as string | null, we cannot treat it as a string until we prove it isn't null.

The problem isn’t necessarily the existence of missing values; it’s how they quietly propagate. A null returned from a database helper function can trickle up through three service layers and a controller before finally crashing a frontend view component. By the time the error occurs, the context of why the value was missing is often lost. We are left chasing ghosts, trying to figure out which link in the chain failed to hold.

The Real Cost of Implicit Absence

The most obvious cost of null and undefined is the runtime error. "Cannot read properties of undefined" is the soundtrack to many debugging sessions. But in a mature TypeScript codebase, actual crashes are (hopefully) rare.

The real cost is the defensive posture we are forced to adopt.

To avoid crashes, our code becomes littered with guard clauses:

if (user) {  
  if (user.address) {  
    if (user.address.zipCode) {  
      // finally do something  
    }  
  }  
}

We write this logic over and over again. Worse, we carry a heavy cognitive load. Every time you touch a piece of code, you have to ask yourself: “Can this be null? Did the previous developer check for undefined? Is the type definition lying to me?”

There is also the ambiguity of intent. If a function returns null, what does that mean?

• Did the record not exist?
• Did the database connection fail?
• Is the value actually optional?
• Was it just not initialized yet?

null is a generic bucket for "something went wrong" or "nothing is here," and it forces the consumer to guess the intent. We end up writing code that looks safe because it satisfies the TypeScript compiler, but it isn't semantically robust.

Why TypeScript Helps - but Not Enough

TypeScript has made massive strides in mitigating these issues, primarily through strictNullChecks. This compiler flag forces us to acknowledge that string | null is not the same thing as string. It stops us from accidentally lowercasing a missing string.

We also have optional chaining (?.) and nullish coalescing (??). These are syntactic sugars that make handling missing data less verbose.

const zip = user?.address?.zipCode ?? '00000';

This is certainly better than nested if statements. However, optional chaining often acts as a bandage rather than a cure. It allows us to gloss over the problem. By using ?., we are essentially saying, "If this is broken, just keep going and return undefined."

This creates a new problem: implicit propagation. The undefined value keeps bubbling up the stack. We haven't handled the absence; we've just deferred it. We haven't modeled why the data is missing; we've just accepted that it might be.

Even with strict mode, TypeScript treats absence as a side effect of the type system, not a first-class citizen of your domain logic.

Making Absence Explicit with Option

There is an alternative pattern that has existed in other languages for decades and is slowly gaining traction in the TypeScript community: the Option type (sometimes called Maybe).

The core idea is simple. Instead of passing around a raw value that might be missing (e.g., User | null), you pass around a container. This container is always defined. It is an object that exists.

Inside the container, there are two possible states:

• Some: The container holds a value.
• None: The container is empty.

This sounds trivial, but the shift in reasoning is profound.

When you use an Option, you eliminate the concept of null from your business logic. You effectively tell the compiler and the future reader of your code: "This value might be missing, and I demand that you handle that possibility explicitly before you can touch the data."

You cannot accidentally use the value inside an Option. You must “unwrap” it. This forces a conscious decision at the point of usage. It transforms “absence” from a runtime hazard into a compile-time guarantee.

A Lightweight Option for TypeScript

To explore this, we will use a library called @rsnk/option. There are many libraries in this space, but this one provides the core benefits of the pattern without weighing you down with heavy academic theory or bloated API surfaces.

It provides a generic class Option<T>. You wrap your risky data in it, and then you use its methods to safely transform or retrieve that data.

Let’s look at how this changes the code we write every day.

Simple, Familiar Scenarios

Example 1: Frontend URL Parameter Parsing

Handling query parameters is a classic frontend task. Imagine reading a “page” number from a URL query string. The parameter might be missing, it might be a non-numeric string (like “abc”), or it might be a negative number.

Without Option: We often end up with imperative code that mutates variables or uses multiple exit points to handle validation.

function getPageNumber(param: string | null): number {  
 // Handle missing value  
 if (!param) {  
  return 1;  
 }  
// Try parsing  
const parsed = parseInt(param, 10);
// Validate the parsed result  
if (Number.isNaN(parsed) || parsed < 1) {

return 1;

}
return parsed;

}

With Option: We can treat the parameter as a pipeline. We don’t care about the specific failure state (missing vs. invalid); we just care about getting a valid number or a default.

import O from "@rsnk/option";  
function getPageNumber(param: string | null): number {

return (

O.fromNullable(param)

// Try to parse the string to a number  
.map((p) => parseInt(p, 10))

// Keep it only if it is a valid, positive number  
.filter((p) => !Number.isNaN(p) && p > 0)

// If it was missing, invalid, or negative, default to 1  
.unwrapOr(1)

);

}

This highlights the strength of the pattern: composability. We combined parsing logic and validation logic into a single flow without declaring temporary variables or writing manual if checks.

Example 2: Backend Environment Configuration

Reading environment variables is a classic source of backend bugs.

Without Option:

const rawPort = process.env.PORT;  
let port = 3000;  
if (rawPort) {

const parsed = parseInt(rawPort, 10);

if (!Number.isNaN(parsed)) {

port = parsed;

}

}

With Option:

import O from "@rsnk/option";  
const port = O.fromNullable(process.env.PORT)

.map((p) => parseInt(p, 10))

.filter((p) => !Number.isNaN(p))

.unwrapOr(3000);

Here, the intent is crystal clear. We take the value, try to parse it, and ensure it’s a valid number (using filter), and if any of that fails or if the value was missing, we default to 3000. We don't need temporary variables or nested if blocks.

More Realistic, Layered Scenarios

The Option pattern truly shines when logic gets more complex and spans multiple layers of an application.

Example 3: Frontend Data Transformation

Consider a dashboard that fetches a transaction list. We need to find the latest transaction, format its date, and display it. The array might be empty, the date string might be malformed, or the transaction might be missing entirely.

import O from "@rsnk/option";  
interface Transaction {

id: string;

timestamp?: string; // API might return partial data  
amount: number;

}
// Helper to safely get an array element  
const lookup = <T>(arr: T[], index: number): O.Option<T> =>

O.fromNullable(arr[index]);
// Helper to safely parse a date string  
const dateFromISOString = (iso: string): O.Option<Date> => {

const d = new Date(iso);

return isNaN(d.getTime()) ? O.none : O.from(d);

};
function getLastTransactionDate(transactions: Transaction[]): string {

return (

O.some(transactions)

// Get the last item.  
// Standard array access returns T | undefined, so we use peak helper  
.andThen((transactions) => lookup(transactions, transactions.length - 1))

// timestamp could be undefined, so we use mapNullable  
.mapNullable((transaction) => transaction.timestamp)

// Try to parse the date  
.andThen((timestamp) => dateFromISOString(timestamp))

// Format the date object  
.map((date) => date.toLocaleDateString())

// If anything was missing or invalid along the way:  
.unwrapOr(“No recent activity”)

);

}

In a traditional approach, this function would likely require 4 or 5 conditionals. Here, it is a linear flow. The andThen allows us to chain operations that might themselves return an Option (like safeDate). If the timestamp is bad, the chain short-circuits gracefully.

It is important to note that adopting Option doesn’t mean you have to abandon TypeScript’s native tools like optional chaining (?.) or nullish coalescing (??). In fact, they can work quite well together.

// The "Pragmatic" Approach  
// Using optional chaining to simplify the "drilling" and Option to handle the "logic."  
function getLastTransactionDate(transactions: Transaction[]): string {  
// We use native ?. to grab the potential timestamp in one go,  
// then wrap the result to handle the actual domain logic.  
return O.fromNullable(transactions[transactions.length - 1]?.timestamp)

.andThen((timestamp) => dateFromISOString(timestamp))

.map((date) => date.toLocaleDateString())

.unwrapOr(“No recent activity”);

}

Example 4: Backend Domain Logic

Let’s look at a service method in a Node.js backend. We want to find a user by ID, check if they have an active subscription, and return their subscription level. If anything is missing, we treat them as a “Free” tier user.

import O from "@rsnk/option";  
interface Subscription {

level: “pro” | “enterprise” | “basic”;

isActive: boolean;

}
interface User {

id: string;

subscription?: Subscription;

}
class UserService {

private db: Map<string, User>;
constructor(db: Map<string, User>) {

this.db = db;

}
// A method that explicitly returns an Option, signaling  
// to the caller that the user might not exist.  
findUser(id: string): O.Option<User> {

return O.fromNullable(this.db.get(id));

}
getUserTier(userId: string): string {

return (

this.findUser(userId)

// Focus on the subscription  
.mapNullable((user) => user.subscription)

// Logic: Only care if subscription is active  
.filter((sub) => sub.isActive)

// Extract the level  
.map((sub) => sub.level)

// Default to free for any failure case  
.unwrapOr(“free”)

);

}

}

This example demonstrates safe navigation. We don’t have to check if (user) or if (user.subscription). We define the happy path, and the Option type handles the sad path automatically.

What Changes in Daily Development

Adopting this pattern is less about syntax and more about a shift in mindset.

Code reads like a story. Instead of reading code that stutters with checks (if this, else if that), you read a continuous narrative of data transformation. "Take the user, find their subscription, check if active, get the level."

Refactoring becomes safer. When you change a function to return Option<T> instead of T | null, TypeScript forces you to update every call site. You cannot ignore the change. The compiler becomes a stricter, more helpful pair programmer.

“Missing” is no longer an afterthought. In the null | undefined world, handling the missing case is often something we tack on at the end. With Option, you are aware of the "box" from the very first line. You design your API with the possibility of absence in mind, leading to more robust interfaces.

When Option Might Be Too Much

Is Option the silver bullet for everything? No.

As with any pattern, context matters. If you are writing a small, throwaway script, introducing an Option library might be overkill. Standard optional chaining (?.) is perfectly adequate for simple, local variables where the scope is small and the logic is linear.

There is also an interoperability cost. If you are working heavily with React forms or third-party libraries that expect null, you will find yourself wrapping and unwrapping values frequently. While @rsnk/option is lightweight, it is still an abstraction.

However, for domain logic, complex data processing, and shared libraries, the benefits Option usually outweigh the small setup cost.

A Thoughtful Closing

Moving away from null doesn't happen overnight. It isn't a requirement to be a "good" developer. It is simply a tool-a different way of modeling the world that prioritizes safety and explicitness.

If this concept sparks your curiosity, you don’t need to rewrite your entire codebase. Try it in one place. Perhaps apply it to that one tricky configuration parser, or a utility function that deals with deeply nested API responses.

Use a library like @rsnk/option to give you the primitives you need without the bloat. See if the code feels cleaner. See if you feel more confident when you deploy it.

The goal isn’t to eliminate null for the sake of purity. The goal is to write code that lets you sleep a little better at night, knowing that your "missing values" are exactly where you left them - safely inside a box, waiting to be handled.

Ready to experiment? Check out @rsnk/option on npm.