TypeScript React — Missing Generic Crashed Checkout

React gives you freedom. TypeScript gives you guardrails. Together they give you something rare in frontend engineering: confidence that a refactor won't silently break a prop three components deep. In a codebase with a dozen engineers, untyped props are a game of telephone — by the time the wrong shape reaches the component that actually needs it, the original author has left the company. TypeScript closes that gap and makes intent explicit at the component boundary.

The problem TypeScript solves in React isn't just catching typos. It's expressing contracts. A generic data table shouldn't accept 'any data' — it should accept 'an array of T, and a set of column definitions that know how to read properties of T'. Without TypeScript that constraint lives only in a comment nobody reads. With TypeScript it's enforced by the compiler, autocompleted in the editor, and self-documenting in the type signature.

After reading this article you'll be able to type generic components that work across multiple data shapes, model complex UI state with discriminated unions so impossible states become compiler errors, forward refs with full type safety, and avoid the five performance and type-inference traps that catch even experienced React + TypeScript developers off guard. These are patterns straight from production codebases — not toy examples.

What is TypeScript with React?

TypeScript with React lets you bake type safety into component boundaries. Instead of runtime prop‑checking with PropTypes, you encode contracts at compile time. The real win: when a prop shape changes, every consumer lights up with errors — not silent breakage. In practice, that means a generic DataTable<T> can accept any data shape and enforce column definitions that know how to read fields of T. This isn't just about catching null dereferences; it's about making impossible states unrepresentable. For instance, a modal that shows either a loading spinner, an error message, or content should express that as a discriminated union — TypeScript then guarantees you can't accidentally render content while loading.

import { ReactNode } from 'react';

interface Column<T> {
  header: string;
  accessor: (row: T) => ReactNode;
}

interface DataTableProps<T> {
  data: T[];
  columns: Column<T>[];
}

export function DataTable<T>({ data, columns }: DataTableProps<T>) {
  return (
    <table>
      <thead>
        <tr>
          {columns.map(col => <th key={col.header}>{col.header}</th>)}
        </tr>
      </thead>
      <tbody>
        {data.map((row, i) => (
          <tr key={i}>
            {columns.map(col => <td key={col.header}>{col.accessor(row)}</td>)}
          </tr>
        ))}
      </tbody>
    </table>
  );
}

Discriminated Unions for Complex State Management

A state machine inside a React component is common: loading, success, error. The naive approach uses three separate booleans — but that lets you accidentally set both loading and error to true. A discriminated union collapses these into a single type that exactly one branch can hold. Use the status or state property as the discriminant and map over each variant. The payoff: every render path is explicit, and TypeScript will yell if you try to access data when status is 'error'.

type DataState<T> =
  | { status: 'loading' }
  | { status: 'error'; error: string }
  | { status: 'success'; data: T };

function reducer<T>(state: DataState<T>, action: Action<T>): DataState<T> {
  switch (action.type) {
    case 'FETCH_START':
      return { status: 'loading' };
    case 'FETCH_ERROR':
      return { status: 'error', error: action.payload };
    case 'FETCH_SUCCESS':
      return { status: 'success', data: action.payload };
  }
}

Forwarding Refs with Type Safety

React.forwardRef lets parent components grab a DOM node from a child. Without generics, the ref type is any and you lose all autocomplete. With a generic forwardRef, you keep the connection between the ref type and the underlying DOM element. The trick: the order of generics is RefType, Props — not Props, RefType. Mix them up and TypeScript will silently infer a wrong type. Common use case: wrapping a third‑party input library where the parent needs to call .focus() imperatively.

interface FormInputProps {
  label: string;
  value: string;
  onChange: (value: string) => void;
}

// RefType, then Props
export const FormInput = React.forwardRef<HTMLInputElement, FormInputProps>(
  ({ label, value, onChange }, ref) => {
    return (
      <label>
        {label}
        <input ref={ref} value={value} onChange={e => onChange(e.target.value)} />
      </label>
    );
  }
);

FormInput.displayName = 'FormInput';

Performance Gotchas: Type Inference Limits and Memoization

TypeScript's type inference is powerful but not free. Deeply nested generics — especially in large union types — can slow down editor autocompletion and increase compilation time. Worse, if a generic component is used inside a React.memo wrapper, the generic type can be lost because memo infers the props as a concrete type. The fix: explicitly annotate the memoised component with the generic signature. Another trap: using React.FC<Props> with a generic component forces you to lose the generic parameter — it's a concrete type wrapper. Instead, define the function directly with the generic.

// ❌ Bad: React.FC eats the generic
const DataTable: React.FC<DataTableProps<unknown>> = (props) => { ... };

// ✅ Good: keep the generic on the function
function DataTable<T>({ data, columns }: DataTableProps<T>) {
  return <BasicTable data={data} columns={columns} />;
}

export const MemoDataTable = React.memo(DataTable) as typeof DataTable;

Conditional Props and Type Narrowing with Generics

Sometimes a component's props change based on another prop value. For example, a Button component that optionally renders a tooltip when tooltip prop is provided, and then requires a tooltipPosition. Conditional types let you encode these rules: if tooltip is string, then tooltipPosition is required; otherwise it's forbidden. This eliminates runtime checks and makes the API self‑documenting. The key is to use a discriminated union on the component's props type itself, not just on state.

type ButtonProps = {
  label: string;
  onClick: () => void;
} & (
  | { tooltip?: never; tooltipPosition?: never }
  | { tooltip: string; tooltipPosition: 'top' | 'bottom' }
);

export function Button(props: ButtonProps) {
  if (props.tooltip) {
    // TypeScript narrows: tooltip and tooltipPosition are available
    return <TooltipButton {...props} />;
  }
  return <SimpleButton {...props} />;
}