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 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 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} />;
}

Stop Using `any` — A Type-Safe State Management Pattern

Junior devs love any. It feels faster. It is not. I just spent three hours on-call debugging a production crash because someone used any on a user object that changed shape between API versions. The type system is your first line of defense, not your enemy.

Here is the real reason any is dangerous: it disables all type checking downstream. One any pollutes your entire component tree. The fix is a discriminated union for your API response. Model every possible state — loading, success, error, empty. Then narrow with type guards. If your API returns a new field you didn't expect, TypeScript screams at compile time, not in production at 2 AM.

This pattern forces you to handle every state explicitly. No more if (data) { ... } and hoping. The match function ensures you return something for every branch. Your future self will thank you when the PM asks for a loading spinner.

// io.thecodeforge
type ApiState<T> =
  | { status: 'loading' }
  | { status: 'success'; data: T }
  | { status: 'error'; error: Error }
  | { status: 'empty' };

function match<T, R>(
  state: ApiState<T>,
  handlers: {
    loading: () => R;
    success: (data: T) => R;
    error: (err: Error) => R;
    empty: () => R;
  }
): R {
  switch (state.status) {
    case 'loading': return handlers.loading();
    case 'success': return handlers.success(state.data);
    case 'error': return handlers.error(state.error);
    case 'empty': return handlers.empty();
  }
}

export { ApiState, match };

Why Your UseRef Is Breaking TypeScript — And How to Fix It

I've seen more production fires from useRef misuse than props. The pattern is always the same: a junior dev does const ref = useRef<HTMLInputElement>(null) and then tries to access ref.current.value without checking. TypeScript doesn't save them because current can be null. So they add a non-null assertion (!) and the bug disappears... until the component unmounts early.

Here is the fix: useRef with null as initial value means the ref is MutableRefObject<HTMLInputElement | null>. You must guard every access. But there is a smarter pattern — use a callback ref. It gives you the DOM node synchronously.

The callback ref pattern is safer because TypeScript narrows the type automatically inside the callback. No ?. operators everywhere. No runtime crashes from stale refs. This matters most in event handlers that fire after a component unmounts (like async data calls). Use this for form inputs, canvas elements, or any DOM node you manipulate directly.

// io.thecodeforge
import { useState, useCallback } from 'react';

interface SafeTextInputProps {
  onValue: (value: string) => void;
}

const SafeTextInput: React.FC<SafeTextInputProps> = ({ onValue }) => {
  const [text, setText] = useState('');
  
  const inputRef = useCallback((node: HTMLInputElement | null) => {
    if (node !== null) {
      // node is definitely HTMLInputElement here
      node.focus();
    }
  }, []);

  const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
    setText(e.target.value);
    onValue(e.target.value);
  };

  return <input ref={inputRef} value={text} onChange={handleChange} />;
};

export default SafeTextInput;

Polymorphic 'as' Prop Pattern with ComponentPropsWithoutRef

The polymorphic 'as' prop pattern allows a component to render as different HTML elements or custom components while maintaining type safety. This is essential for reusable UI primitives like buttons, headings, or containers. Using React's ComponentPropsWithoutRef ensures that the component accepts the correct props for the rendered element. Here's how to implement it:

1. Define a generic PolymorphicProps type that extracts props from the element type.
2. Use React.forwardRef to forward refs with correct typing.
3. Apply ComponentPropsWithoutRef to get props excluding ref.

Example: A Box component that can render as div, span, or section.

import React from 'react';
type BoxProps<T extends React.ElementType> = {
  as?: T;
  children?: React.ReactNode;
} & React.ComponentPropsWithoutRef<T>;
const Box = React.forwardRef(<T extends React.ElementType = 'div'>(
  props: BoxProps<T>,
  ref: React.ComponentPropsWithRef<T>['ref']
) => {
  const { as: Component = 'div', ...rest } = props;
  return <Component ref={ref} {...rest} />;
});
// Usage
<Box as="section" className="container">Content</Box>
<Box as="a" href="/link">Link</Box>

This pattern ensures that when you use as="a", the component expects href and other anchor-related props. Without ComponentPropsWithoutRef, TypeScript would not enforce these props. This is a production-grade pattern used in libraries like Chakra UI and Radix UI.

import React from 'react';

type BoxProps<T extends React.ElementType> = {
  as?: T;
  children?: React.ReactNode;
} & React.ComponentPropsWithoutRef<T>;

const Box = React.forwardRef(<T extends React.ElementType = 'div'>(
  props: BoxProps<T>,
  ref: React.ComponentPropsWithRef<T>['ref']
) => {
  const { as: Component = 'div', ...rest } = props;
  return <Component ref={ref} {...rest} />;
});

export default Box;

Compound Components with TypeScript: Typed Context + Namespaced Sub-Components

Compound components allow you to create a set of components that work together implicitly, like with . In TypeScript, you can achieve type safety by using a typed context and namespacing sub-components as static properties of the parent.

1. Define a context with a generic type for shared state.
2. Create the parent component that provides the context.
3. Define sub-components that consume the context.
4. Attach sub-components to the parent as static properties.

Example: A Tabs component with Tab and Panel sub-components.

```tsx import React, { createContext, useContext, useState } from 'react';

interface TabsContextType { activeIndex: number; setActiveIndex: (index: number) => void; }

const TabsContext = createContext(undefined);

function useTabsContext() { const context = useContext(TabsContext); if (!context) throw new Error('Tabs sub-components must be used within '); return context; }

interface TabsProps { children: React.ReactNode; }

function Tabs({ children }: TabsProps) { const [activeIndex, setActiveIndex] = useState(0); return ( {children} ); }

interface TabProps { index: number; children: React.ReactNode; }

function Tab({ index, children }: TabProps) { const { activeIndex, setActiveIndex } = useTabsContext(); return ( setActiveIndex(index)} style={{ fontWeight: activeIndex === index ? 'bold' : 'normal' }} > {children} ); }

interface PanelProps { index: number; children: React.ReactNode; }

function Panel({ index, children }: PanelProps) { const { activeIndex } = useTabsContext(); return activeIndex === index ?

{children}

: null; }

Tabs.Tab = Tab; Tabs.Panel = Panel;

export default Tabs; ```

Usage: Tab 1Content 1

This pattern ensures that sub-components can only be used inside the parent, and TypeScript provides autocomplete for the static properties.

Tabs.tsxTSX

Copy

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

37

38

39

40

41

42

43

44

45

46

47

48

49

50

51

52

53

54

55

56

57

58

59

import React, { createContext, useContext, useState } from 'react';

interface TabsContextType {
  activeIndex: number;
  setActiveIndex: (index: number) => void;
}

const TabsContext = createContext<TabsContextType | undefined>(undefined);

function useTabsContext() {
  const context = useContext(TabsContext);
  if (!context) throw new Error('Tabs sub-components must be used within <Tabs>');
  return context;
}

interface TabsProps {
  children: React.ReactNode;
}

function Tabs({ children }: TabsProps) {
  const [activeIndex, setActiveIndex] = useState(0);
  return (
    <TabsContext.Provider value={{ activeIndex, setActiveIndex }}>
      {children}
    </TabsContext.Provider>
  );
}

interface TabProps {
  index: number;
  children: React.ReactNode;
}

function Tab({ index, children }: TabProps) {
  const { activeIndex, setActiveIndex } = useTabsContext();
  return (
    <button
      onClick={() => setActiveIndex(index)}
      style={{ fontWeight: activeIndex === index ? 'bold' : 'normal' }}
    >
      {children}
    </button>
  );
}

interface PanelProps {
  index: number;
  children: React.ReactNode;
}

function Panel({ index, children }: PanelProps) {
  const { activeIndex } = useTabsContext();
  return activeIndex === index ? <div>{children}</div> : null;
}

Tabs.Tab = Tab;
Tabs.Panel = Panel;

export default Tabs;

Try it live

🔥Always validate context usage

📊 Production Insight

This pattern is used in libraries like Reach UI and Headless UI. For performance, memoize context values to prevent unnecessary re-renders of all sub-components when state changes.

🎯 Key Takeaway

Compound components with typed context and namespaced sub-components provide an elegant, type-safe API for tightly coupled UI elements.

thecodeforge.io 🔗 Copy link

Typed Custom Hooks with Generics: useAsync Pattern

Custom hooks often need to handle asynchronous operations with different data types and arguments. Using generics, you can create a type-safe useAsync hook that infers the return type and argument types.

1. Define a generic function type for the async operation.
2. Use useState and useEffect to manage loading, error, and data states.
3. Return typed state and a run function.

Example: useAsync that takes an async function and returns its result.

```tsx import { useState, useCallback } from 'react';

interface AsyncState { data: T | null; loading: boolean; error: Error | null; }

type AsyncFn = (...args: Args) => Promise;

function useAsync( asyncFn: AsyncFn, immediate: boolean = false ) { const [state, setState] = useState>({ data: null, loading: immediate, error: null, });

const run = useCallback(async (...args: Args) => { setState({ data: null, loading: true, error: null }); try { const data = await asyncFn(...args); setState({ data, loading: false, error: null }); return data; } catch (error) { setState({ data: null, loading: false, error: error as Error }); throw error; } }, [asyncFn]);

return { ...state, run }; }

export default useAsync; ```

Usage: ``tsx const fetchUser = async (id: number): Promise<{ name: string }> => { const res = await fetch(/api/user/${id}`); return res.json(); };

const { data, loading, error, run } = useAsync(fetchUser); // data is inferred as { name: string } | null // run expects (id: number) => Promise<{ name: string }> ```

This pattern eliminates the need for manual type assertions and ensures that the hook's return types are always in sync with the async function.

useAsync.tsTSX

Copy

1

2

3

4

5

6

7

8

9

10

11

12

13

14

15

16

17

18

19

20

21

22

23

24

25

26

27

28

29

30

31

32

33

34

35

36

import { useState, useCallback } from 'react';

interface AsyncState<T> {
  data: T | null;
  loading: boolean;
  error: Error | null;
}

type AsyncFn<T, Args extends any[]> = (...args: Args) => Promise<T>;

function useAsync<T, Args extends any[]>(
  asyncFn: AsyncFn<T, Args>,
  immediate: boolean = false
) {
  const [state, setState] = useState<AsyncState<T>>({
    data: null,
    loading: immediate,
    error: null,
  });

  const run = useCallback(async (...args: Args) => {
    setState({ data: null, loading: true, error: null });
    try {
      const data = await asyncFn(...args);
      setState({ data, loading: false, error: null });
      return data;
    } catch (error) {
      setState({ data: null, loading: false, error: error as Error });
      throw error;
    }
  }, [asyncFn]);

  return { ...state, run };
}

export default useAsync;

Try it live

⚠ Avoid stale closures in async hooks

📊 Production Insight

In production, extend this pattern to handle cancellation (e.g., with AbortController) and avoid state updates on unmounted components. Libraries like React Query offer more robust solutions, but this pattern is great for simple cases.

🎯 Key Takeaway

Generic custom hooks like useAsync<T, Args> provide end-to-end type safety for asynchronous operations, reducing runtime errors and improving developer experience.

● Production incidentPOST-MORTEMseverity: high

The Missing Generic Annotation That Took Down a Checkout Page

Symptom

Users completed payment details, clicked 'Place Order', and saw a blank white screen. No console errors. No API call logged.

Assumption

The payment form component inferred the correct prop types from the provided data. "It worked in Storybook," said the developer.

Root cause

The generic component PaymentForm<T> received an array of mixed payment methods. TypeScript inferred T as the union of all possible values, not the specific method selected, causing the submit handler to receive an incorrectly typed object — and the render branch that handled the correct shape was never reached.

Fix

Explicitly annotate the generic call site: <PaymentForm<CreditCard>> — or redesign the prop to use a discriminated union that forces TypeScript to narrow correctly.

Key lesson

• Always specify the generic parameter explicitly when the inferred type might be wider than intended.
• Test generic components with every concrete type they'll receive in production — not just the happy path.
• Add a compile-time assertion (e.g., expect-type) to verify the generic resolves to the expected shape.

Production debug guideSymptom → Action guide for the three most common type failures in production React apps4 entries

Symptom · 01

Component doesn't accept the props you're passing (TS error in editor) but compiles locally

→

Fix

Check the tsconfig.json strict flag and ensure skipLibCheck is not masking errors. Run tsc --noEmit to verify build-time types match runtime.

Symptom · 02

Generic component infers an any type for a prop

→

Fix

Inspect the generic constraint: is it too loose? Add an explicit type annotation at the call site or use a default generic like <T extends Record<string, unknown>>.

Symptom · 03

Ref forwarding produces a TS error on the forwarded component

→

Fix

Verify that the forwardRef generic is correctly ordered: React.forwardRef<HTMLDivElement, Props> and that the component function accepts ref as the second parameter.

Symptom · 04

Discriminated union state leads to unreachable code in one branch

→

Fix

Check that the discriminant property (e.g., status) is a literal type, not a generic string. Use a mapped type to exhaustively cover all variants.

★ TypeScript + React Quick Debug Cheat SheetUse these commands and fixes when type inference goes wrong in production

Generic component infers `unknown` instead of expected type−

Immediate action

Annotate the generic: `<MyComponent<ConcreteType>`

Commands

tsc --noEmit --strict

copy

console.log type of prop using `typeof` in a test

copy

Fix now

Add a default generic parameter: function MyComponent<T = SomeConcreteType>(props: T)

React.forwardRef type mismatch+

Immediate action

Check the order of generics: forwardRef<RefType, Props>(props, ref)

Commands

tsc --noEmit --strict

copy

Inspect the ref type with `React.RefObject<HTMLDivElement>`

copy

Fix now

Use useImperativeHandle with a typed interface to avoid prop drilling

Discriminated union doesn't narrow in switch/case+

Immediate action

Add a default case with `never` to trigger compile-time error

Commands

tsc --noEmit --strict

copy

Check if discriminant property is optional or nullable

copy

Fix now

Add an exhaustiveCheck(param: never): never helper function

Advanced Patterns Comparison

Pattern	Best Use Case	Runtime Safety	Compile-Time Overhead
Generic Data Component	Tables, lists, forms with dynamic schemas	High – type errors caught in editor	Low – simple constraint inference
Discriminated Union State	State machines with 2–5 mutually exclusive states	Very High – impossible states prevented	Low – union resolution is fast
ForwardRef + Generics	Imperative DOM access (focus, scroll)	Medium – ref type must be correct	Low – only impacts that component
Conditional Props (Union)	Components with conditional optional pairs (tooltip + position)	Very High – wrong combos become type errors	Medium – complex unions may slow inference
React.FC + Generics (avoid)	Don't use this combination	Low – generic lost, runtime errors possible	High – slows down type checking for all consumers

⚙ Quick Reference

10 commands from this guide

File	Command / Code	Purpose
iothecodeforgecomponentsDataTable.tsx	interface Column {	What is TypeScript with React?
iothecodeforgehooksuseDataFetch.ts	type DataState =	Discriminated Unions for Complex State Management
iothecodeforgecomponentsFormInput.tsx	interface FormInputProps {	Forwarding Refs with Type Safety
iothecodeforgecomponentsMemoizedDataTable.tsx	const DataTable: React.FC> = (props) => { ... };	Performance Gotchas
iothecodeforgecomponentsButton.tsx	type ButtonProps = {	Conditional Props and Type Narrowing with Generics
useApiState.ts	type ApiState =	Stop Using `any`
SafeTextInput.tsx	interface SafeTextInputProps {	Why Your UseRef Is Breaking TypeScript
PolymorphicBox.tsx	type BoxProps = {	Polymorphic 'as' Prop Pattern with ComponentPropsWithoutRef
Tabs.tsx	interface TabsContextType {	Compound Components with TypeScript
useAsync.ts	interface AsyncState {	Typed Custom Hooks with Generics

Key takeaways

1

Generic components enforce compile‑time contracts across data shapes

always constrain with extends.

2

Discriminated unions eliminate impossible states from your UI state machine.

3

React.forwardRef generics require ref type first, props second

wrong order gives unknown ref.

4

Avoid React.FC for generic components; use plain generic functions instead.

5

Conditional props encode relationships in the type system

let the compiler enforce them.

INTERVIEW PREP · PRACTICE MODE

Interview Questions on This Topic

Practice List View

Q01SENIOR

How would you type a generic table component that accepts a dynamic arra...

Q02SENIOR

Explain how discriminated unions improve state management in React compo...

Q03JUNIOR

What is the correct order of generics in React.forwardRef, and what happ...

Q01 of 03SENIOR

How would you type a generic table component that accepts a dynamic array of columns, where each column can render a function of the row data?

ANSWER

Define the component as function DataTable<T>({ data, columns }: { data: T[]; columns: { header: string; render: (row: T) => ReactNode }[] }). The generic T is inferred from the data prop. Each column's render function receives a typed row. This pattern ensures type safety across all column renderers.

Q02 of 03SENIOR

Explain how discriminated unions improve state management in React components compared to multiple booleans.

ANSWER

A discriminated union defines a finite set of states where exactly one is active at a time, e.g., { status: 'loading' } | { status: 'error'; error: string } | { status: 'success'; data: T }. Multiple booleans allow impossible states (loading + success simultaneously). The union forces every render branch to handle each state explicitly. Common use: data fetching where you always want to show either a spinner, error message, or content — never a combination.

Q03 of 03JUNIOR

What is the correct order of generics in React.forwardRef, and what happens if you get it wrong?

ANSWER

The correct order is React.forwardRef<RefType, Props>(). If you swap them, the ref will be typed as unknown (or any in older versions). That means calling .focus() or .scrollIntoView() on the ref will produce a runtime error because the type doesn't include those methods. Always double‑check: ref type first, props second.

01

How would you type a generic table component that accepts a dynamic array of columns, where each column can render a function of the row data?

SENIOR

02

Explain how discriminated unions improve state management in React components compared to multiple booleans.

SENIOR

03

What is the correct order of generics in React.forwardRef, and what happens if you get it wrong?

JUNIOR

FAQ · 4 QUESTIONS

Frequently Asked Questions

01

What is the biggest mistake beginners make with TypeScript and React generics?

The biggest mistake is using React.FC<Props> with a generic type — the generic is effectively lost. Always define generic components as plain functions with the <T> before the parentheses.

Was this helpful? 👍 Yes👎 No

02

How do I debug a generic component that won't accept the props I pass?

First, check your generic constraint — is it too tight? Then inspect the inferred type by hovering over the component usage in your editor. If it shows unknown, you need an explicit annotation at the call site or a default generic parameter. Run tsc --noEmit --strict to catch type errors that your editor might hide.

Was this helpful? 👍 Yes👎 No

03

When should I use a discriminated union instead of boolean flags for component state?

Any time you have two or more mutually exclusive states (loading, error, success, empty). Booleans let you accidentally set multiple flags true; a discriminated union enforces exclusivity at compile time. Use them for data‑fetching hooks, modal visibility, and form submission flow.

Was this helpful? 👍 Yes👎 No

04

Can I use React.forwardRef with a generic component?

Yes. The pattern is: const MyComponent = React.forwardRef<RefType, Props>(). If you need the component to also be generic (e.g., forwardRef with a generic data type), you can wrap it in a generic function: function MyComponent<T>(props: Props<T>, ref: Ref) { ... } and then assign displayName`. The generic goes on the outer function.

Was this helpful? 👍 Yes👎 No

📖 What to Read Next

→TypeScript Strict Mode — Missing Null Check Broke PaymentsOrders completed with zero amounts — a missing null check on user.phoneNumber caused payment failures. Find the exact fi→TypeScript Interview — Unknown vs Any Production GotchaTypeScript's 'unknown' type forces type guards, avoiding runtime crashes. But 'any' bypasses all checks — a common inter→TypeScript Conditional Types — Why Unions Collapse to NeverDistributive conditionals silently widen unions when T extends never is bare. The [T] extends [U] tuple fix prevents typ→JavaScript vs TypeScript — NaN Crash That Cost $40kPromo code 'SAVE20' caused NaN and $40k lost orders — JavaScript's type coercion struck silently. TypeScript catches it.→TypeScript Generics — The Silent `any` in Merge FunctionsA merge(defaults, overrides) silently returns any past production code review. Prevent with explicit type args and asser

From Other Categories

Design a Distributed Locking ServiceAdvanced

N

Naren Founder & Principal Engineer

20+ years shipping production JavaScript and front-end systems at scale. Everything here is grounded in real deployments.

Follow

✓ Verified

production tested

July 19, 2026

last updated

2,466

articles · all by Naren

🔥

That's TypeScript. Mark it forged?

6 min read · try the examples if you haven't

✓ Mark as read · go to React Server Components → Save for later

←

Previous

E2E Testing React Apps with Playwright

5 / 15 · TypeScript

Next

React Server Components

→