Deck 12 - Advanced TypeScript for React (Senior TS Patterns)

Question 1

Deck 12 - Advanced TypeScript for React (Senior TS Patterns) (objective)

Answer 1

Goal: write and review React+TS like a senior: sound types, safe boundaries, expressive component APIs, and correct narrowing.
You learn: what/why, common traps, and what to recommend during code review.
Output style: PASS/PARTIAL/FAIL + 2-3 issues + fix approach.

Question 2

Mental model: TypeScript is structural, not nominal (what this means).

Answer 2

Types are compatible based on shape, not name. If two types have the same structure, they are assignable.
Why it matters: accidental compatibility can happen; use branded types when you need nominal-like safety.

Question 3

Mental model: TS checks at compile time, not runtime.

Answer 3

Types disappear at runtime. If data comes from outside (API, localStorage), you must validate at runtime.
Best practice: parse/validate at boundaries (Zod/io-ts) before using data in React state.

Question 4

Mental model: ‘unknown’ vs ‘any’ (how to choose).

Answer 4

unknown is safe: you must narrow before using. any disables type checking.
Senior rule: prefer unknown at boundaries; avoid any except in narrow interoperability seams.

Question 5

Mental model: variance and why callbacks bite.

Answer 5

Function parameter types are (effectively) contravariant/bivariant in some React typings.
Why: you can accidentally accept too-broad/too-narrow handlers. Prefer explicit handler types and generic props when needed.

Question 6

Mental model: widening vs literal types.

Answer 6

const x = ‘a’ preserves literal ‘a’; let x = ‘a’ widens to string.
Why: literal types enable discriminated unions and safer component APIs.

Question 7

Mental model: inference is your friend, but be explicit at boundaries.

Answer 7

Let TS infer locals; be explicit at component boundaries (props, return values of hooks, public APIs).
Why: keeps code readable and prevents accidental breaking changes.

Question 8

Mental model: type-level code has cost (cognitive + compile time).

Answer 8

Overly clever conditional types can slow TS and confuse reviewers.
Best practice: prefer simple types unless complexity buys real safety.

Question 9

Mental model: narrowing is driven by control flow.

Answer 9

TS narrows based on checks like typeof, in, instanceof, and discriminants.
Senior: structure code to make narrowing obvious and local.

Question 10

Mental model: ‘satisfies’ keeps literals while checking shape.

Answer 10

Use ‘satisfies’ to ensure an object meets a type without widening the object’s inferred literal types.
Great for configuration maps and component prop dictionaries.

Question 11

Mental model: generics are about relationships.

Answer 11

Generic types express ‘this depends on that’. Example: a function that returns the same element type it receives.
Senior: use generics to model relationships, not to ‘avoid writing types’.

Question 12

Mental model: discriminated unions model state machines.

Answer 12

Use a shared literal field (status/type) to represent distinct states.
Why: prevents impossible states and improves React UI branching.

Question 13

Mental model: never trust API response shapes.

Answer 13

Even if backend is ‘typed’, responses can change, be partial, or error.
Fix: validate + handle missing fields; model error paths explicitly.

Question 14

Mental model: avoid ‘boolean soup’ in props.

Answer 14

Multiple booleans create invalid combinations and unclear meaning.
Prefer enums/unions (variant: ‘primary’|’secondary’) or discriminated props.

Question 15

Mental model: prefer readonly for inputs.

Answer 15

Mark props and shared objects readonly to prevent mutation bugs.
Why: mutation breaks memoization and surprises consumers.

Question 16

Mental model: null vs undefined (be consistent).

Answer 16

Pick a consistent meaning: undefined often means ‘not provided’; null often means ‘known empty’.
Senior: be consistent in React state and API models.

Question 17

Mental model: Exhaustiveness is a correctness feature.

Answer 17

Use exhaustive checks in switch on unions to catch missing cases at compile time.
Why: prevents runtime bugs when new variants are added.

Question 18

Mental model: prefer domain types over primitives (when it helps).

Answer 18

Instead of string for everything, use types like UserId, Email.
Why: reduces accidental mixing of IDs/values.

Question 19

Mental model: React types can lie if you force them.

Answer 19

Casting (as) can silence errors but create runtime bugs.
Senior: only cast after validating, and keep casts narrow and well-justified.

Question 20

Mental model: build type safety from the edges inward.

Answer 20

Start with typed API client + runtime validation, then typed hooks, then typed components.
Why: prevents ‘any leaks’ from contaminating your app.

Question 21

Best practice: type props with an explicit Props type.

Answer 21

Define Props separately and give components a single named prop type.
Why: improves readability, reusability, and keeps component signatures stable.

Question 22

Best practice: do NOT use React.FC by default (why).

Answer 22

React.FC adds implicit children and can complicate generics/defaultProps.
Prefer: function Component(props: Props) or const Component = (props: Props) => …

Question 23

Best practice: type state as a union that matches reality.

Answer 23

Example: User | null, or {status:’loading’} | {status:’success’, data:User}.
Why: prevents impossible states and makes render branching safe.

Question 24

Best practice: use discriminated union for async state.

Answer 24

Represent async state with status: ‘idle’|’loading’|’error’|’success’.
Why: TS can narrow state so UI code is correct by construction.

Question 25

Best practice: prefer unknown for fetch results, then parse.

Answer 25

Treat JSON as unknown. Validate with a schema before setting state. Why: avoids runtime crashes from shape mismatch.

Question 26

Best practice: use const assertions for config maps.

Answer 26

Use as const or satisfies to build typed lookup tables. Why: keeps literal keys/values and enables safe indexing.

Question 27

Best practice: event handler typing.

Answer 27

Use React types: React.MouseEvent, React.ChangeEvent. Why: correct target/value types and fewer unsafe casts.

Question 28

Best practice: refs - type them explicitly.

Answer 28

Use useRef(null) or useRef(null). Why: prevents accidental undefined/null misuse and unsafe property access.

Question 29

Best practice: avoid non-null assertions (!) in UI code.

Answer 29

Non-null assertion can crash at runtime. Prefer: guard, optional chaining, or restructure so TS can narrow.

Question 30

Best practice: encode optionality in props clearly.

Answer 30

If prop is optional, code must handle it. If required, make it required. Why: optional props become a reliability footgun when callers omit them.

Question 31

Best practice: use overloads sparingly for hooks/utilities.

Answer 31

Overloads can make APIs nicer but can also confuse inference. Prefer a single generic signature unless you truly need different call shapes.

Question 32

Best practice: prefer type-safe enums via unions, not TS enum.

Answer 32

Use 'type Variant = "a" | "b"' instead of enum. Why: unions are simpler and tree-shake well.

Question 33

Best practice: never use 'string' for CSS class names map keys if you can avoid it.

Answer 33

Type class maps with literal keys: const styles = { root: '...', ... } as const. Why: prevents typos and provides autocomplete.

Question 34

Best practice: constrain generics to what you need.

Answer 34

Use instead of if you require id. Why: expresses constraints; prevents misuse.

Question 35

Best practice: component 'variant' prop with discriminated props.

Answer 35

Use unions to vary allowed props by variant. Why: prevents invalid prop combos (e.g., href only allowed for links).

Question 36

Best practice: never widen union accidentally with '| any'.

Answer 36

Adding any to a union collapses safety. Senior: avoid any; keep unions precise.

Question 37

Best practice: model API errors explicitly.

Answer 37

Use { ok:true, data } | { ok:false, error }. Why: forces caller to handle error path; avoids try/catch-only flows.

Question 38

Best practice: prefer readonly arrays for inputs.

Answer 38

Use readonly T[] for function inputs and props. Why: prevents accidental mutation and helps reasoning.

Question 39

Best practice: use 'satisfies' for typed objects you want to keep narrow.

Answer 39

Example: const routes = { home:'/', ... } satisfies Record. Why: checks shape without widening.

Question 40

Best practice: do not over-export types from components.

Answer 40

Export only what consumers need. Why: avoids tight coupling and reduces refactor cost.

Question 41

Pattern: branded types for IDs (what/why).

Answer 41

Use a brand to prevent mixing different IDs (UserId vs OrderId). Why: TS is structural, so plain strings are interchangeable unless branded.

Question 42

Pattern: indexed access types (use case).

Answer 42

Use T['field'] to reference the type of a property. Why: keeps types in sync when object shapes change.

Question 43

Pattern: mapped types (use case).

Answer 43

Transform keys: { [K in keyof T]: ... }. Why: build derived types like partials, readonly, and field validators.

Question 44

Pattern: conditional types (use case).

Answer 44

Type depends on condition: T extends U ? X : Y. Why: express relationships like 'if input is array, output is element type'. Keep it simple.

Question 45

Pattern: infer in conditional types (use case).

Answer 45

Extract a type: T extends Promise ? U : never. Why: decode wrapper types in utilities.

Question 46

Pattern: satisfies vs as const (difference).

Answer 46

as const freezes literals and makes everything readonly. satisfies checks shape but keeps inference for literals without forcing readonly everywhere.

Question 47

Pattern: exact object shapes (common pitfall).

Answer 47

Excess property checks happen on object literals but not on variables. Senior: avoid relying on excess property checks for security; validate at runtime.

Question 48

Pattern: exhaustive switch with never.

Answer 48

In a switch on a union, assign the default to a never variable. Why: TS errors when a new union member is unhandled.

Question 49

Pattern: safe narrowing with 'in'.

Answer 49

Use 'if ("error" in res)' to narrow union shapes. Why: good for API result unions and polymorphic objects.

Question 50

Pattern: user-defined type guards (when).

Answer 50

Write function isUser(x: unknown): x is User. Why: reusable runtime checks that inform TS narrowing.

Question 51

Pattern: generics in components (best practice).

Answer 51

Prefer inference-friendly patterns: (props: Props) => ... Why: React JSX can misparse ; use comma trick and keep generic APIs simple.

Question 52

Pattern: building typed dictionaries safely.

Answer 52

Use Record where K is a union of allowed keys. Why: prevents missing keys and avoids string indexing errors.

Question 53

Pattern: avoiding 'as' with helper functions.

Answer 53

Prefer createX(...) helpers that return correctly typed values. Why: avoids unsafe casts and centralizes invariants.

Question 54

Pattern: type-safe error handling with Result.

Answer 54

Use Result = { ok:true, value:T } | { ok:false, error:E }. Why: explicit control flow; better than throwing for expected errors.

Question 55

Pattern: noImplicitAny + strictNullChecks (why).

Answer 55

These flags enforce sounder code by preventing implicit any and forcing null handling. Senior: treat type errors as correctness bugs, not nuisance.

Question 56

Under the hood: why JSON is unknown at runtime.

Answer 56

fetch().json() returns untyped data. TS cannot guarantee shape. You must validate because runtime can differ from compile-time assumptions.

Question 57

Under the hood: why union narrowing improves correctness.

Answer 57

Control-flow narrowing means once you check status/ok, TS knows which fields exist. This prevents calling methods on possibly undefined fields in React renders.

Question 58

Under the hood: why 'any' spreads like a virus.

Answer 58

Once a value is any, operations on it become any, removing checks downstream. Senior: contain any to the smallest boundary, or use unknown + parsing.

Question 59

Under the hood: why non-null assertion is dangerous in React.

Answer 59

React renders can happen before data loads; assumptions like user!.name can crash. Prefer guards/conditional rendering or state machines.

Question 60

Under the hood: why structural typing can cause accidental bugs.

Answer 60

Two distinct domain values may share shape (string), so TS allows mixing. Branding or wrapper objects prevent accidental assignment.

Question 61

Under the hood: why 'satisfies' is powerful for config objects.

Answer 61

It checks that your object meets a contract but keeps literal inference. This gives you safe indexing + autocomplete without widening everything to string.

Question 62

Under the hood: why TS enums can be annoying.

Answer 62

They emit runtime code and can be harder to tree-shake. String unions often provide the same benefit without runtime output.

Question 63

Under the hood: JSX generic parsing gotcha.

Answer 63

In TSX, can be parsed as a JSX tag. Workaround: or move generics to helper functions/hooks.

Question 64

Under the hood: why exhaustive checks prevent regressions.

Answer 64

When you add a new union variant, TS forces you to handle it. This catches missing UI branches during refactors.

Question 65

Under the hood: why 'readonly' helps performance reasoning.

Answer 65

Readonly encourages immutability, which pairs with referential equality checks. Immutable data makes memoization and rerender analysis simpler.

Question 66

Gotcha: using any for API response. ``` const [user, setUser] = useState(null); useEffect(() => { fetch('/api/user').then(r => r.json()).then(setUser); }, []); return

{user.name.toUpperCase()}

; ```

Answer 66

FAIL - any hides unsafe API shape and allows runtime crashes (user/name may be missing). Use unknown + validation and type state as User | null (or status union).

Question 67

Gotcha: missing null in state union. ``` type User = { id: string; name: string }; const [user, setUser] = useState({ id: '', name: '' }); ```

Answer 67

PARTIAL - Sentinel empty user can mask loading vs real data. Prefer User | null or discriminated async state.

Question 68

Gotcha: optional prop but treated as required. ``` type Props = { userId?: string }; function Profile({ userId }: Props) { return

{userId.toUpperCase()}

; } ```

Answer 68

FAIL - userId may be undefined. Make prop required or add guard + fallback UI.

Question 69

Gotcha: unsafe non-null assertion. ``` return

{user!.name}

; ```

Answer 69

FAIL - Can crash before data is loaded. Add conditional rendering or model state so TS narrows safely.

Question 70

Gotcha: union without narrowing. ``` type Api = { ok: true; user: { name: string } } | { ok: false; error: string }; function f(res: Api) { return res.user.name; } ```

Answer 70

FAIL - res.user does not exist on error case. Narrow with if (res.ok) or 'in' operator.

Question 71

Gotcha: Result type but forgetting exhaustiveness. ``` type State = { status: 'loading' } | { status: 'success'; data: User } | { status: 'error'; message: string }; function View(s: State) { if (s.status === 'success') return s.data.name; return '...'; } ```

Answer 71

PARTIAL - Missing explicit handling of loading/error. Prefer switch with exhaustive check for clarity.

Question 72

Gotcha: stringly-typed variant booleans. ``` type Props = { primary?: boolean; secondary?: boolean }; ```

Answer 72

PARTIAL - Invalid combinations possible. Use variant union: { variant: 'primary' | 'secondary' }.

Question 73

Gotcha: TSX generic parsing issue. ``` const Comp = (props: { value: T }) =>

; ```

Answer 73

FAIL - In TSX, can be parsed as JSX. Use or move generic to helper function.

Question 74

Gotcha: unsafe cast to satisfy compiler. ``` const user = data as User; setUser(user); ```

Answer 74

PARTIAL - Cast can hide invalid shapes. Prefer runtime validation or a type guard before assignment.

Question 75

Gotcha: using Record loses key safety. ``` const labels: Record = { open: 'Open' }; labels.opne; ```

Answer 75

PARTIAL - Typos not caught. Prefer literal key union + satisfies to keep keys narrow.

Question 76

Gotcha: mixing null and undefined in state inconsistently.

Answer 76

PARTIAL - Inconsistent optionality makes checks messy. Pick a convention: null for 'empty', undefined for 'not provided' and stick to it.

Question 77

Gotcha: mutating typed arrays passed via props. ``` function List({ items }: { items: string[] }) { items.push('x'); return null; } ```

Answer 77

FAIL - Mutates props; can break memoization and surprises callers. Treat as readonly input and create a new array.

Question 78

Gotcha: missing readonly in helper signature. ``` function sortUsers(users: User[]) { return users.sort(...); } ```

Answer 78

PARTIAL - Mutates input. Use readonly User[] and return a new sorted copy.

Question 79

Gotcha: event target typing mistake. ``` function onChange(e: Event) { // e.target.value } ```

Answer 79

FAIL - Wrong event type in React. Use React.ChangeEvent for correct target typing.

Question 80

Gotcha: async function returns Promise but typed as value. ``` function load(): User { return fetch('/api').then(r => r.json()); } ```

Answer 80

FAIL - Return type mismatch. Use Promise and validate response shape.