Fixing "Cannot invoke an object which is possibly 'undefined'"

Cannot invoke an object which is possibly 'undefined' is the function-calling counterpart to TypeScript's general "possibly undefined" property access error — it fires specifically when you try to call something typed as Function | undefined, most commonly an optional callback prop or an optional method, without first confirming it's actually present.

This error means the value you're trying to call as a function has a type that includes undefined as a possibility — TypeScript won't let you invoke it without first proving (via a check, optional call syntax, or a default) that it's actually a function at that point, since calling undefined as a function would throw a runtime TypeError.

Why This Error Happens

Optional function props (onSave?: () => void) and optional methods on an interface are extremely common patterns — a callback the caller might or might not provide. TypeScript correctly types these as (() => void) | undefined, and calling them directly without narrowing produces this error, since a genuine undefined value flowing into a direct call would crash at runtime exactly where the type checker is warning you.

Reproducing the Error

An optional callback prop called directly:

interface ButtonProps {
  onClick?: () => void;
  label: string;
}

function Button({ onClick, label }: ButtonProps) {
  return (
    <button onClick={() => onClick()}>
      {/* Error: Cannot invoke an object which is possibly 'undefined'. */}
      {label}
    </button>
  );
}

Core Concepts Behind This Error

Optional call syntax (?.()) is the most direct, idiomatic fix, calling the function only if it's actually defined and otherwise evaluating to undefined harmlessly — this mirrors optional chaining's ?. for property access, extended specifically for function invocation.

Providing a default no-op function is an alternative pattern, useful when you want to guarantee the value is always callable throughout a component or module without repeated optional-call checks scattered through the code:

function Button({ onClick = () => {}, label }: ButtonProps) {
  return <button onClick={onClick}>{label}</button>; // always safely callable
}

An explicit guard is appropriate when the presence or absence of the callback should affect other behavior, not just whether it's called — for instance, conditionally rendering a button at all based on whether a handler was provided, rather than always rendering it and safely no-op-ing the click.

This error commonly appears in React component props specifically, since optional event handler props are an extremely common pattern — recognizing this as the dominant real-world context helps identify the fix quickly: it's almost always either ?.(), a default no-op, or a presence-based conditional render.

Fixing "Cannot Invoke an Object Which Is Possibly 'undefined'"

Fix 1: Use optional call syntax for the simplest, most common case:

function Button({ onClick, label }: ButtonProps) {
  return <button onClick={() => onClick?.()}>{label}</button>;
}

Fix 2: Provide a default no-op value when the function is always expected to be callable throughout the component:

function Button({ onClick = () => {}, label }: ButtonProps) {
  return <button onClick={onClick}>{label}</button>;
}

Fix 3: Use an explicit guard when the callback's absence should change behavior beyond just skipping the call:

function DeleteButton({ onDelete, label }: { onDelete?: () => void; label: string }) {
  if (!onDelete) {
    return null; // don't render a delete button at all if no handler was provided
  }
  return <button onClick={onDelete}>{label}</button>;
}

Should Optional Callbacks Always Get a Default No-Op, or Sometimes Stay Truly Optional?

Use a default no-op when the calling code genuinely doesn't need to distinguish "wasn't provided" from "was provided but chooses to do nothing" — this simplifies the component's internal logic since the value is always safely callable. Keep it truly optional (using ?.() or an explicit guard at each call site) when the distinction matters — some components need to behave differently (disable a button, hide an element, skip an entire feature) specifically because a handler wasn't provided, not just skip calling it.

Preventing This Error in Production

Default to optional call syntax (?.()) for optional callback invocations as the simplest, most consistent pattern across a codebase, reserving default no-op values or explicit guards for the specific cases where they genuinely simplify logic or where presence needs to affect other behavior. Keep optional prop types honest about genuine optionality — if a callback is effectively always provided in practice, consider whether it should actually be required in the type rather than optional, removing the need for this handling altogether.

If you hit this error, reach for ?.() first as the default, simplest fix, and only step up to a default value or explicit guard when the specific behavior you need genuinely requires distinguishing "not provided" from "provided but does nothing."