Options objects

One options param

Long argument lists are fragile because order carries meaning and every new flag shifts all calls. One options object fixes this by naming each input at the call site.

Callers pass only what matters and skip the rest. Readers see labels instead of positions, so intent survives long after the call was written.

interface CardOptions { title: string; wide?: boolean; theme?: string; } function makeCard(opts: CardOptions): string { return opts.title; } makeCard({ title: "Hello", wide: true });

Defaults inside

Optional fields need steady fallbacks in exactly one place. Destructure with defaults at the top of the function so later code works with complete values.

Central defaults keep calls short and behavior stable. Adding a new option later never breaks old callers because the fallback already exists.

function cardClass(opts: CardOptions): string { const wide = opts.wide ?? false; const theme = opts.theme ?? "light"; return theme + (wide ? " wide" : ""); }

Partial updates

Settings screens often change one field while keeping the rest. Partial makes every field optional for updates, then spread merges the patch over current state.

The full object stays the source of truth and patches stay tiny. Each update reads as intent: here is what changed, everything else is untouched.

function withPatch(base: CardOptions, patch: Partial<CardOptions>): CardOptions { return { ...base, ...patch }; } const next = withPatch({ title: "Hi" }, { wide: true });

Readonly options

Shared config should flow down, not mutate along the way. Readonly marks every field as view only so helpers can read options but never rewrite them.

Freezing input at the type level catches stray assignments during review, not in production. Functions return new objects instead of editing what they received.

type FrozenCard = Readonly<CardOptions>; function titleOf(opts: FrozenCard): string { return opts.title; }

Next: Builder

Article author: Arthur Isaev