Lesson 9 of 80

TypeScript with React

Q: You write const [user, setUser] = useState(null), then later try setUser(someUserObject) — and TypeScript rejects it. Why, and what's the fix?

A strong answer covers: useState(null) infers the state's type as literally null, since there's no other value in the initializer to widen from; Assigning anything other than null to setUser is then a real type error; Fix: explicitly supply the generic, useState (null), telling TypeScript the full range of values this state can hold.

Typing a component is just typing a function — props are parameters, JSX is the return value. Everything from the last 8 lessons applies directly.

14 min read

Check your understanding

Every option explains itself — why the right one is right, and why each wrong one is wrong. Miss one and it comes back later on a spaced-repetition schedule.

Question 1 of 3

const [user, setUser] = useState(null); later, setUser({ id: "1", name: "Ada" }) is rejected by TypeScript. Why?

useState(null) infers the state's type as literally null, since there's nothing else to widen fromuseState always infers any unless a generic is providedsetUser can only ever be called once per component

Stuck? Ask the AI tutor

Hints without spoilers, and a plain explanation of why a wrong answer was wrong — answered only from this lesson. Free account, no card.

Interview questions on TypeScript with React

What interviewers actually ask about this, and what a strong answer has to cover.

You write const [user, setUser] = useState(null), then later try setUser(someUserObject) — and TypeScript rejects it. Why, and what's the fix?

A strong answer covers

useState(null) infers the state's type as literally null, since there's no other value in the initializer to widen from
Assigning anything other than null to setUser is then a real type error
Fix: explicitly supply the generic, useState<User | null>(null), telling TypeScript the full range of values this state can hold

Likely follow-ups

Is this the same widening/inference behavior from the type-inference lesson, or something specific to useState?
How would you type a generic, reusable List component so it correctly types items and renderItem based on whatever data it's given?

Practice these with the AI interviewer →

The plain-language idea

From the React track: a component is just a function. From this track: typing a function means typing its parameters and its return value. Put together, there's nothing React-specific about typing a component — it's ordinary function typing, applied to props and JSX.

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

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

ButtonProps is just an interface, the same as any other. The component is a function whose parameter happens to be props and whose return type happens to be JSX.

See it in a real thing: the `useState(null)` gotcha

const [user, setUser] = useState(null);
// inferred type: null — not User | null

setUser({ id: "1", name: "Ada" }); // ❌ Argument of type 'User' is not assignable to 'null'

const [user2, setUser2] = useState<User | null>(null);
// explicit generic: user2 is User | null

setUser2({ id: "1", name: "Ada" }); // ✅

From the type-inference lesson: TypeScript infers from the value given. useState(null)'s only value is null itself — there's no other value to widen from — so the state's type is inferred as literally null, forever. The fix is the same generics mechanism from earlier in this track: supply useState's type parameter explicitly to tell it the full range of values this state can hold, not just its initial one.

TypeScript + React: the same tools, aimed at componentsStep 1 of 3

function Button({ label, onClick }: { label: string; onClick: () => void }) — props typed directly on the destructured argument.

What people usually miss

Watch out

useState(null)'s inference gotcha is the exact widening behavior from the type-inference lesson, not something React-specific — there's simply no second value in useState(null)'s call for TypeScript to generalize from.
A component can be generic, using the exact mechanism from the generics lesson: function List<T>({ items, renderItem }: { items: T[]; renderItem: (item: T) => ReactNode }) types itself differently depending on what data it's actually given.
Typing event handlers needs the specific event type, not a generic Event — onClick: (e: React.MouseEvent<HTMLButtonElement>) => void gives you the actual properties (like e.currentTarget) typed correctly, where a looser type wouldn't.
Props being typed doesn't create any runtime enforcement. Like every TypeScript type, prop types are erased at compile time — nothing stops a plain JavaScript caller (or a // @ts-ignore) from passing the wrong shape at runtime.

Why this matters in interviews

Being asked to type a piece of React code is really a test of whether you've absorbed the last 8 lessons and can apply them somewhere concrete — generics, narrowing, inference, and structural typing all show up directly, not as separate "React TypeScript" rules to memorize on top.