State and Lifecycle ⚛️

1. useState — A Component's Memory

useState is a React Hook (a special function whose name starts with use) that gives a component a value it can remember between renders. You call it like const [count, setCount] = useState(0): the argument 0 is the initial value, and you get back a pair — the current value (count) and a setter function (setCount). The one rule that makes React work: only the setter changes state, and calling the setter is what tells React to re-render. Read this worked example, run it, and watch the setter trigger a "render".

// React state lives inside the component. Our editor can't render UI,
// so we model what useState DOES with plain JS variables + console.log.
// In a real component the line would be:  const [count, setCount] = useState(0);

// useState returns a PAIR: [currentValue, updaterFunction].
// We fake that pair so we can watch it behave like the real hook.
let count = 0;                          // the current value React holds for you
function setCount(next) {               // the setter — in React
...

In a real component this all lives inside the function. Here's the JSX it produces (read-only — the type annotation useState<number> pins the value to a number):

import { useState } from "react";

function Counter() {
  const [count, setCount] = useState<number>(0);

  return (
    <button onClick={() => setCount(count + 1)}>
      Clicked {count} times
    </button>
  );
}

Every click calls setCount, React stores the new number, then re-runs Counter so the button text updates. That loop — event → setter → re-render — is the heartbeat of every interactive React app.

2. State vs Props

Beginners constantly confuse these two, so burn in the difference now. Props are passed into a component by its parent and are read-only — the component must never reassign them. State is owned by the component and is the only thing it's allowed to change (through its setter). A handy test: "Could this value ever change while the component is on screen, because of something the component itself does?" If yes, it's state; if it just arrives from outside, it's a prop.

// PROPS are passed IN by a parent. The component cannot change them.
// STATE is owned BY the component. The component changes it with its setter.

// Think of one <Greeting name="Ada" /> below.
// 'name' is a PROP: it comes from outside and is read-only here.
// 'likes' is STATE: it belongs to this component and changes on click.

let likes = 0;                          // STATE owned by Greeting
const name = "Ada";                     // PROP handed down from the parent

function like() {    
...

3. Updating Objects Immutably

When state holds an object, you must never edit it in place (obj.age = 29). React decides whether to re-render by checking if the state is a new object — same object reference, no re-render. So you build a fresh copy with the spread operator ..., then override just the field you're changing: setUser({ ...user, age: 29 }). The spread copies every existing field; the field you list after it wins. Your turn — fill the blank.

// 🎯 YOUR TURN — update ONE field of an object WITHOUT mutating it.
// Rule: never edit the old object. Build a NEW object with the spread (...).

const user = { name: "Sam", age: 28, city: "London" };

// 1) Make a NEW object that copies every field of 'user'
//    but changes age to 29. Spread the old one first, then override age.
const updated = ___;        // 👉 { ...user, age: 29 }

console.log("old:", JSON.stringify(user));     // old must be UNCHANGED
console.log("new:", JSON.stringify(u
...

4. Updating Arrays Immutably

Arrays follow the same rule: produce a new array, never mutate the old one. That means avoiding push, pop, splice and sort (they change the array in place) and reaching instead for operations that return a new array: spread to add ([...todos, item]), filter to remove, and map to change one item. Fill in the two blanks below.

// 🎯 YOUR TURN — update an ARRAY immutably (no push/splice/pop).
// Each step returns a BRAND NEW array; the original stays untouched.

const todos = ["Learn props", "Learn state"];

// 1) ADD an item. Spread the old array, then add the new string.
const added = ___;          // 👉 [...todos, "Build a project"]

// 2) REMOVE "Learn props" using filter (keep everything that ISN'T it).
const removed = ___;        // 👉 added.filter(t => t !== "Learn props")

console.log("original:", JSON.stringif
...

5. Functional Updates — setX(prev => ...)

When the new state is built from the old state, pass the setter a function instead of a value: setCount(prev => prev + 1). React calls your function with the very latest value, so you can never accidentally work from a stale (outdated) snapshot — which is exactly what goes wrong if you fire several updates in a row using a plain variable. Run this to see the trap and the fix side by side.

// Functional update: setCount(prev => prev + 1).
// Use it whenever the NEW state depends on the OLD state.

let count = 0;
function setCount(updater) {
  // React passes the LATEST value into your function and stores the result.
  count = typeof updater === "function" ? updater(count) : updater;
}

console.log("=== The stale-value trap ===");
count = 0;
// Imagine reading 'count' once (0) and reusing that snapshot three times:
const snapshot = count;                 // snapshot = 0
setCount(sn
...

// A reducer-like function: (state, action) -> NEW state.
// This is how big apps keep updates predictable. Notice: it never mutates.

const initial = { count: 0, history: [] };

function reducer(state, action) {
  switch (action.type) {
    case "increment":
      return { ...state, count: state.count + 1,           // new object
               history: [...state.history, "inc"] };       // new array
    case "decrement":
      return { ...state, count: state.count - 1,
               history: 
...

6. Lifting State Up

What if two components need the same piece of data — say one shows a count and another changes it? If each keeps its own copy, they drift out of sync. The fix is lifting state up: move the state to the nearest common parent, then pass the value down as a prop to one child and the setter down to the other. Now there is a single source of truth, and every child reads the same value.

// LIFTING STATE UP: when two components need the SAME data,
// move the state to their nearest common PARENT and pass it down as props.
//
// Before: each child had its own count -> they disagreed.
// After:  the parent owns 'count' and passes it (+ the setter) to both.

// Parent owns the single source of truth:
let count = 0;
function setCount(next) { count = next; }

// Child A "displays" the shared value (it receives count as a PROP):
function Display(value) { console.log("Display shows:", 
...

// 🎯 MINI-CHALLENGE: a "like" toggle reducer (no UI needed)
// Build a single function that flips a button between liked / not liked
// and keeps an accurate like COUNT — using only immutable updates.
//
// 1. Start with:  let state = { liked: false, count: 0 };
// 2. Write toggle(state) that returns a NEW state object:
//      - flips state.liked  (true <-> false)
//      - if it just became liked, count goes UP by 1
//      - if it just became unliked, count goes DOWN by 1
//    (use { ...sta
...