The time is {currentHour}:00
{/* Conditional rendering */} {isLoggedIn ?Welcome back!
:Please log in.
} {/* Rendering a list */}{user.role}
Current count: {count}
; } ``` Here, `count` is a piece of state. `useState(0)` initializes it to `0`, and `setCount` is the function used to update it. Without state, components could only render static output based on props, they'd have no way to "remember" anything or react to user interaction (clicks, typing, toggles, etc.). State exists to answer the question: **"What does this component need to remember between renders?"** Examples of things that typically need state: * Whether a modal is open or closed * The current value of an input field * Items in a shopping cart * Whether data is still loading * The active tab in a tab bar Without state, none of these interactive behaviors would be possible — the UI would just be a fixed snapshot. You never modify state directly. Instead, you call the **setter function** returned by `useState`, and React handles re-rendering the component with the new value. ```javascript function Counter() { const [count, setCount] = useState(0); const increment = () => setCount(count + 1); // ✅ correct // count = count + 1; // ❌ never do this directly return ; } ``` **Important nuance — state updates can be asynchronous/batched.** If a new state value depends on the previous one, use the **functional update** form to avoid stale values: ```javascript function Counter() { const [count, setCount] = useState(0); const incrementTwice = () => { setCount((prev) => prev + 1); setCount((prev) => prev + 1); }; return ; } ``` Using `(prev) => prev + 1` guarantees each update builds on the latest value, rather than relying on a `count` variable that might be stale within the same render. Also, calling a setter **triggers a re-render** — React re-runs the component function with the updated state so the UI reflects the change. ### Understanding Re-Rendering A **re-render** happens when React calls a component function again to figure out what the UI should look like now. There are three main triggers: 1. **State changes** — calling a `useState` setter function 2. **Props changes** — a parent re-renders and passes new prop values down 3. **Parent re-renders** — when a parent component re-renders, its children usually re-render too (even if their own props didn't change) ```javascript function App() { const [count, setCount] = useState(0); return (Count: {count}
; } ``` Every time the button is clicked, `setCount` runs → `App` re-renders → `Display` receives a new `count` prop → `Display` re-renders too. When you call a state setter, React schedules a re-render of that component (and its children). The component function runs again from top to bottom, producing new JSX based on the current state values. ```javascript function Toggle() { const [isOn, setIsOn] = useState(false); console.log("Toggle rendered, isOn =", isOn); return ( ); } ``` Each click flips `isOn`, which triggers a re-render, which prints a new log line and updates the button label. React compares the new JSX output to the previous one (using a process involving the **virtual DOM**) and only updates the real DOM where something actually changed — it doesn't repaint the whole page. **Note:** calling a setter with the *same* value it already holds (e.g., `setCount(5)` when `count` is already `5`) will generally **not** trigger a re-render — React bails out early since there's nothing new to reflect. ### Component Lifecycle from a High Level Every component roughly goes through three phases: 1. **Mounting** — the component is created and inserted into the DOM for the first time 2. **Updating** — the component re-renders due to state or prop changes (this is the re-rendering we've been discussing) 3. **Unmounting** — the component is removed from the DOM (e.g., a conditional stops rendering it) ```javascript function Timer() { const [seconds, setSeconds] = useState(0); useEffect(() => { console.log("Mounted!"); const interval = setInterval(() => { setSeconds((s) => s + 1); }, 1000); return () => { console.log("Unmounted, cleaning up interval"); clearInterval(interval); }; }, []); returnSeconds: {seconds}
; } ``` * The `useEffect` with an empty `[]` dependency array runs once on **mount**. * Its return function (the cleanup) runs on **unmount**. * Every time `seconds` changes, that's an **update** (re-render) — but since `[]` is empty, the effect itself doesn't re-run on every update, only the cleanup/setup pair runs once. This mount → update (many times) → unmount cycle is the high-level lifecycle every component goes through. ### Why React Updates the UI Automatically This goes back to React's core philosophy: **the UI is a function of state and props.** You never manually tell React "change this text" or "hide this button." Instead: 1. You describe what the UI *should* look like for any given state/props (via JSX) 2. When state or props change, React re-runs that description 3. React compares the new description to the old one (virtual DOM diffing) 4. React updates only the parts of the real DOM that actually changed (this process is often called **reconciliation**) ```javascript // You just describe the "what": return isLoggedIn ?{user.role}
{user.name} {user.isAdmin && "(Admin)"}
; } ``` Here, `currentUser` starts in `App` and flows down through three layers (`Dashboard` → `Sidebar` → `UserBadge`) before it's finally used. This pattern — passing a prop through components that don't use it themselves, just to get it to a deeply nested child — is sometimes called **"prop drilling."** Prop drilling works fine for shallow trees, but in deeply nested apps it can get unwieldy. That's usually solved later with tools like **Context** or state management libraries — but the underlying data flow rule (parent → child) never changes. If a deeply nested child needs to send data back *up*, it does so the same way covered in the props lesson: the parent passes a **callback function** down as a prop, and the child calls it. **4\. Application Structure** As real apps grow, component trees are typically organized around a few common patterns: 1. Layout components — structural pieces that stay consistent across pages (Header, Footer, Sidebar, Layout) 2. Page/container components — represent a full "screen" or route, often responsible for fetching data and coordinating state 3. Presentational/UI components — small, reusable, often stateless pieces focused purely on rendering (Button, Card, Avatar, Badge) ```javascript function HomePage() { const [posts, setPosts] = useState([]); useEffect(() => { fetchPosts().then(setPosts); }, []); return (Time's up!
; } ``` ```javascript function Timer() { // ✅ Side effect moved to useEffect, runs after render/commit useEffect(() => { document.title = "Timer running"; }); returnTime's up!
; } ``` **Phase 3: Commit** Once React finishes calculating the new UI description, it moves to the **commit phase** — this is where React actually applies changes to the real DOM. * On **initial mount**, React uses `appendChild()` (or similar) to insert all the DOM nodes it created * On a **re-render**, React compares the new element tree to the previous one (a process called **reconciliation** / "diffing") and applies only the **minimal set of changes** needed ```javascript function Clock({ time }) { return ({time}
` changed, and updates *just that text node* in the real DOM. After the commit phase, the browser paints the updated screen, and any `useEffect` callbacks (that had a dependency change) run. ### Putting It Together: A Full Cycle ```javascript function Counter() { const [count, setCount] = useState(0); useEffect(() => { console.log("Committed! count is now:", count); }, [count]); console.log("Rendering with count =", count); return ; } ``` Clicking the button produces this sequence: 1. **Trigger** — `setCount(count + 1)` is called 2. **Render** — `Counter` function runs again, logs `"Rendering with count = 1"`, produces new JSX 3. **Commit** — React updates the button's text in the real DOM 4. **Paint** — browser shows the updated button 5. **Effect** — `useEffect` runs (since `count` changed), logs `"Committed! count is now: 1"` ### Mount vs. Update vs. Unmount (Lifecycle Stages) Zooming out, this Trigger → Render → Commit cycle repeats across a component's lifetime, which breaks into three stages: | Stage | What happens | Hook equivalent | | --- | --- | --- | | **Mount** | Component is created and inserted into the DOM for the first time | `useEffect(() => {...}, [])` | | **Update** | Component re-renders due to state/props/context changes | `useEffect(() => {...}, [dep])` | | **Unmount** | Component is removed from the DOM | Cleanup function returned from `useEffect` | ```javascript function ChatRoom({ roomId }) { useEffect(() => { console.log(`Mounted / roomId changed to ${roomId}`); const connection = connectToRoom(roomId); return () => { console.log(`Cleaning up before unmount / before next roomId`); connection.disconnect(); }; }, [roomId]); return
Connected to {roomId}
; } ``` If `roomId` changes, React runs the **cleanup** from the previous render before running the **new effect** — this is sometimes called "unmount + remount" behavior for effects, even though the component itself doesn't actually unmount from the DOM.