TypeScript with React ⚛️

1. Typing Component Props

Every React component receives a single props object. To type it, you describe its shape once with an interface, then annotate the parameter with that interface. From then on TypeScript enforces required props, rejects wrong types, and autocompletes prop names for you. A ? after a prop name makes it optional. Read this worked example carefully.

// Greeting.tsx — a component that takes typed props.

// 1) Describe the SHAPE of the props with an interface.
//    Each line is: propName: type;   add ? to make it optional.
interface GreetingProps {
  name: string;          // required text
  age: number;           // required number
  isVip?: boolean;       // optional — note the "?"
}

// 2) Annotate the props parameter with that interface.
//    Now TypeScript knows name is a string, age is a number, etc.
function Greeting({ name, age, isVip = false }: GreetingProps) {
  return (
    <p>
      Hi {name}, you are {age}.
      {isVip ? " ⭐ VIP" : ""}
    </p>
  );
}

// 3) Using it — TypeScript checks every prop you pass:
//    <Greeting name="Sam" age={20} />            ✅ valid
//    <Greeting name="Sam" age={20} isVip />      ✅ optional prop supplied
//    <Greeting name="Sam" />                     ❌ Error: 'age' is missing
//    <Greeting name="Sam" age="20" />            ❌ Error: string not assignable to number

You can describe props with either an interface or a type alias — for prop shapes they're nearly identical. A common convention: use interface for object shapes you might extend, and type for unions and one-offs. Notice the "primary" | "danger" union — that prop can only be one of those two strings.

// You can describe props with an INTERFACE or a TYPE alias.
// For component props they are almost interchangeable — pick one and be consistent.

interface ButtonProps {            //  <-- interface
  label: string;
  onClick: () => void;             //  a function that takes nothing, returns nothing
  variant?: "primary" | "danger";  //  union of allowed strings (only these two!)
}

type CardProps = {                 //  <-- type alias, same idea
  title: string;
  footer?: string;
};

// Rule of thumb:
//   interface  → object/prop shapes you might extend later (most components)
//   type       → unions, intersections, and one-off shapes
//
//   variant?: "primary" | "danger"  means the value can ONLY be one of those
//   two strings. Pass variant="blue" and TypeScript stops you before runtime.

// 🎯 YOUR TURN — finish this props interface, then read the checklist below.

interface ProfileCardProps {
  // 1) "username" must be text
  username: ___;          // 👉 the type for text
  // ✅ Expected: username: string;

  // 2) "score" must be a number
  score: ___;             // 👉 the type for whole/decimal numbers
  // ✅ Expected: score: number;

  // 3) "showBadge" is OPTIONAL and true/false
  ___ : boolean;          // 👉 add the property name with a "?" to mark it optional
  // ✅ Expected: showBadge?: boolean;
}

function ProfileCard({ username, score, showBadge = false }: ProfileCardProps) {
  return <div>{username} — {score}{showBadge ? " 🏅" : ""}</div>;
}

2. Typing useState & useRef

Both hooks are generic — they take a type inside angle brackets, like useState<number>(). Most of the time you don't need to write it: useState(0) is inferred as a number from its initial value. You add an explicit <T> when the initial value can't describe the real type — an empty array, or a value that's null now but will hold an object later.

// useState<T>() and useRef<T>() — telling React what type lives inside.

// A) useState INFERS the type from the initial value — no generic needed:
const [count, setCount] = useState(0);      // inferred as number
const [name, setName]   = useState("");     // inferred as string
setCount(5);        // ✅ ok
// setCount("five"); // ❌ Error: string not assignable to number

// B) Add an explicit <T> when the initial value can't describe the type.
//    Empty array? Tell it WHAT the array holds, or it becomes never[]:
const [tags, setTags] = useState<string[]>([]);   // an array of strings
setTags(["react", "ts"]);   // ✅

// C) Nullable state — value starts null but will become a User later.
//    The <User | null> generic is what makes the null-check below necessary.
interface User { id: number; name: string; }
const [user, setUser] = useState<User | null>(null);
// user.name        ❌ Error: 'user' is possibly null
if (user) {
  console.log(user.name);   // ✅ inside the guard, user is User (not null)
}

// D) useRef<T>() — a "box" that survives re-renders.
//    For a DOM element, type it with the element + start it at null:
const inputRef = useRef<HTMLInputElement>(null);
inputRef.current?.focus();   // ?. because current is null until React attaches it

//    For a plain mutable value, give the type and an initial value:
const renderCount = useRef<number>(0);
renderCount.current += 1;    // changing this does NOT trigger a re-render

// 🎯 YOUR TURN — give each piece of state the right type.

// 1) A list of numbers that starts empty.
//    An empty [] alone would be inferred as never[] — so add the generic!
const [scores, setScores] = useState<___>([]);   // 👉 array of numbers
// ✅ Expected: useState<number[]>([])

// 2) A value that is a Product OR null until it loads.
interface Product { id: number; title: string; }
const [product, setProduct] = useState<___>(null);  // 👉 Product OR null
// ✅ Expected: useState<Product | null>(null)

// 3) A ref to a <div> element on the page.
const boxRef = useRef<___>(null);   // 👉 the DOM type for a div element
// ✅ Expected: useRef<HTMLDivElement>(null)

3. Typing Events & Children

React gives each event a specific type, and you tell it which HTML element fired it using a generic. Type a change handler as React.ChangeEvent<HTMLInputElement> and e.target.value is correctly known to be a string. A click handler is React.MouseEvent<HTMLButtonElement>. To accept nested content (anything between your component's tags), type the children prop as React.ReactNode — the catch-all for "anything renderable."

// Typing event handlers — the event object carries the right element type.

// Change event on an <input>. Because we typed it HTMLInputElement,
// e.target.value is known to be a string and autocompletes.
const handleChange = (e: React.ChangeEvent<HTMLInputElement>) => {
  setName(e.target.value);     // ✅ value is a string
};

// Click event on a <button>:
const handleClick = (e: React.MouseEvent<HTMLButtonElement>) => {
  e.preventDefault();
  console.log("clicked at", e.clientX, e.clientY);
};

// Wiring them up in JSX:
// <input onChange={handleChange} />
// <button onClick={handleClick}>Save</button>

// Children — accept ANY renderable content (text, JSX, numbers, arrays)
// with React.ReactNode. This is the type to reach for whenever a component
// wraps other content.
interface CardProps {
  title: string;
  children: React.ReactNode;   // <-- anything you can render
}

function Card({ title, children }: CardProps) {
  return (
    <section>
      <h2>{title}</h2>
      <div>{children}</div>     {/* whatever was nested inside <Card> */}
    </section>
  );
}

// <Card title="Hi"><p>Some content</p></Card>   ✅ <p> is a valid ReactNode

4. Run It: the immutable state-update pattern

The TSX above can't run in this editor, but the update pattern you'll use with a typed setState<Todo[]> is plain JavaScript. The golden rule: never mutate the existing state — build and return a brand-new value. This runnable demo simulates setTodos with a function so you can press Run and watch it work.

// This runs in the editor (plain JS) to show the IMMUTABLE update pattern
// you'll use with React's typed setState. In real React + TS you'd write:
//   const [todos, setTodos] = useState<Todo[]>([]);
// Here we simulate setTodos with a plain function so you can run it.

let todos = [];   // pretend this is state: an array of { id, text, done }

// setState replaces the value — never mutate the old array, build a NEW one.
function addTodo(list, text) {
  return [...list, { id: list.length + 1,
...

// You will see React.FC ("Function Component") in older tutorials:
const Hello: React.FC<{ name: string }> = ({ name }) => <p>Hi {name}</p>;

// It works, but most teams now AVOID it. The plain version is preferred:
function Hello({ name }: { name: string }) {
  return <p>Hi {name}</p>;
}

// Why many avoid React.FC:
//  • It used to add an implicit "children" prop even when a component
//    takes no children — easy to pass children by accident.
//  • It makes generic components awkward to write.
//  • The plain "function Component(props: Props)" form is simpler and
//    is what the React docs themselves use today.
// Bottom line: type the props directly; reach for React.FC only if a
// codebase already standardises on it.

// 🎯 MINI-CHALLENGE: a typed "Counter" component
//
// Build a <Counter /> component (write the types yourself — no blanks given):
// 1. Props interface "CounterProps":
//      - "start" : a number (the initial count)
//      - "label" : a string
//      - "onChange?" : OPTIONAL — a function (newValue: number) => void
// 2. Inside, hold the count with useState, typed/inferred from "start".
// 3. Add a handleClick typed as React.MouseEvent<HTMLButtonElement>
//    that increases the count and calls onChange (if provided).
// 4. Render: <button>{label}: {count}</button>
//
// ✅ Self-check: <Counter start={0} label="Clicks" /> compiles, and
//    <Counter start="0" label="Clicks" /> is a TYPE ERROR (string not number).

// your code here