Stop Using Optional Chaining and Properties in JavaScript/TypeScript: Why Erroring Early Saves You

Are you tired of chasing down undefined errors in your JavaScript or TypeScript code? The allure of optional chaining and optional properties can be strong, but they often lead to more problems than they solve. Especially when working with APIs and external data.

The Danger of Optionals: A Functional Programmer's Perspective

Functional Programming teaches us early on to avoid Maybe/Optional types whenever possible. While convenient, they introduce complexity. Every function and class must account for the "data isn't there" scenario. This leads to more code and increased debugging. Embracing "Parse, Don't Validate" reduces code complexity, streamlining error handling to the data entry point.

Why JavaScript/TypeScript Developers Should Rethink Optionals

Many JavaScript/TypeScript developers overuse optional chaining (thing | undefined) and optional properties (property?: thing | undefined). This flexibility comes at a cost:

• Code bloat: Handling undefined in multiple places increases code size.
• Hidden errors: Many undefined scenarios can't be handled gracefully, leading to errors anyway.
• Immutability challenges: Dealing with potentially missing data makes immutable data handling difficult.
• Object creation temptation: Developers might create objects to sidestep undefined issues. This can introduce weird bugs that appear only in specific code paths.

The Go Approach: Error Early, Error Often

Adopt the Go programming language philosophy: if data is missing, throw an error immediately. This approach shields the rest of your codebase from ambiguity. Avoid types that include data | undefined and properties that might not exist, like name?: string.

Parse and Validate: Creating Robust Data Structures

What if you receive JSON data with optional fields from an external source you can't control? The solution is parsing and validation. Use tools like Zod or manual validation to ensure the data you need exists. Implement defaults if possible, and create a new type that includes all required data. If validation fails, throw an error.

This approach provides several benefits:

• Clear error handling: Problems are identified immediately at the source.
• Simplified code: Inner functions can rely on data being present.
• Improved data integrity: Ensures data aligns with your application's requirements.

Actionable Steps: From Chaos to Clarity

Here’s how to implement this approach in your projects:

• Avoid optional chaining and properties: Design types that explicitly define required data.
• Parse external data: Validate and transform incoming data into your application's internal types.
• Error aggressively: If data is missing, don't hesitate to throw an error.
• Define default values: For non-critical missing data, define sensible defaults during parsing.

Real-World Example: Validating API Responses

Imagine an API that returns user data:

interface ApiResponse {
  id: number;
  name?: string;
  email: string;
}

Instead of directly using ApiResponse, validate and transform the data:

import { z } from "zod";

const UserSchema = z.object({
  id: z.number(),
  name: z.string().optional(),
  email: z.string().email(),
});

type User = z.infer<typeof UserSchema>;

function parseUser(data: any): User {
  const result = UserSchema.safeParse(data);
  if (!result.success) {
    throw new Error("Invalid user data from API");
  }
  return result.data;
}

Now, your code can confidently work with the User type, knowing that the id and email are always present, and the name has been explicitly handled.

Your Future Self Will Thank You

Adopting a "error early" strategy might seem strict initially, but it leads to more robust, maintainable, and bug-free code. By avoiding optional chaining and properties, and embracing parsing and validation, you'll save yourself countless hours of debugging and create a more reliable application. So, before you reach for that ? operator, consider the long-term costs and opt for a more explicit and error-aware approach.