{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreifkqly43hubyswiy72q5nnzehs25y22rhbms3477nnnxnsyycvcyy",
"uri": "at://did:plc:25rdn5elo5izoxrmtis34zuk/app.bsky.feed.post/3mpv4e52ac7w2"
},
"coverImage": {
"$type": "blob",
"ref": {
"$link": "bafkreieuh5lpoq4im6qddtttzoffdityfw7uxvtndjszsodne2hkeyjc6a"
},
"mimeType": "image/webp",
"size": 151918
},
"path": "/surajrkhonde/the-mall-of-react-an-uncle-nephew-guide-4def",
"publishedAt": "2026-07-05T07:27:24.000Z",
"site": "https://dev.to",
"tags": [
"react",
"frontend",
"webdev",
"programming"
],
"textContent": "_One mall. Many shops. From the day everything had to be rearranged by hand, to the smart, modern mall you shop in today._\n\n## Setting the Scene\n\nš¦ **Nephew:** Uncle, I use React every day, but if someone asks me how it actually works inside, I go blank.\n\nšØāš¦³ **Uncle:** Then let's fix that with one picture in your head: a big shopping mall. Every React idea maps to something in this mall. Keep this table nearby.\n\nIn the Mall | In React\n---|---\nThe mall building | The web page, the browser\nMall Management | React itself\nThe floor plan / store layout instructions | Your code\nIndividual shops | Components\nMerchandise Management supplies to a shop | Props\nA shop's own private cash register & sales log | State\nThe actual shop windows customers see | The real DOM\nThe design studio's mockup display | The Virtual DOM\nThe renovation team comparing mockup to real window | Reconciliation / Diffing\nMall Security, prioritizing what needs attention now | The Scheduler / Fiber\nShoppers walking through the mall | The user\nShops that are built but not yet \"open,\" waiting to be switched on | Hydration\nThe mall directory board + walking directions | The Router\n\nš¦ **Nephew:** Alright, let's walk the mall.\n\n## Part 1: The Old, Exhausting Mall\n\nš¦ **Nephew:** Before React, how did people even manage websites?\n\nšØāš¦³ **Uncle:** No design studio existed. Every tiny change ā a shop rearranges one shelf, updates one price tag ā meant someone walked out onto the **actual, live shop floor** , in front of real customers, and moved it by hand.\n\n\n\n Change needed\n ā\n v\n Walk onto the LIVE shop floor\n Adjust it directly, customers watching\n\n\nš¦ **Nephew:** Sounds slow for a big mall.\n\nšØāš¦³ **Uncle:** It was ā touching the real shop floor (the DOM) is expensive; every touch risks the whole storefront needing to redraw. So the mall hired a faster handyman crew: **jQuery**.\n\nš¦ **Nephew:** Problem solved?\n\nšØāš¦³ **Uncle:** Faster hands, same job. Every single change still had to be manually planned and carried out, one at a time, live. Bigger mall, same tiring work.\n\n## Part 2: The Scale Problem That Forced a Fix\n\nš¦ **Nephew:** What actually broke this old way of working?\n\nšØāš¦³ **Uncle:** Scale. Imagine a mall the size of Facebook's ā not a hundred shoppers, but hundreds of millions, all inside at once. A \"like\" counter changes. A friend's online-status light turns green. A notification badge updates. Comments pour in live.\n\nEach one of those is a live, walk-onto-the-floor change. Thousands per second, across millions of screens. The floor gets messy, staff bump into each other, updates lag.\n\nSo the engineers asked one question:\n\n> _\"What if, instead of touching the real shop floor every time, we first build the change in a private design studio, compare it to what's currently displayed, and only carry out the smallest necessary fix?\"_\n\nThat private studio is the **Virtual DOM**.\n\n## Part 3: The Design Studio ā What the Virtual DOM Actually Does\n\n\n BEFORE REACT WITH REACT (Virtual DOM)\n āāāāāāāāāāāāā āāāāāāāāāāāāāāāāāāāāāāāāā\n Change needed Change needed\n ā ā\n v v\n Walk onto the LIVE floor Build it in the DESIGN STUDIO\n Fix it directly (customers don't see this)\n (customers see every fumble) ā\n v\n Compare studio mockup to\n what's on the real floor NOW\n ā\n v\n Carry out ONLY the real\n differences, on the real floor\n\n\nš¦ **Nephew:** Walk me through the steps.\n\nšØāš¦³ **Uncle:** Six of them:\n\n 1. **You write the floor plan** ā your component code.\n 2. **A studio mockup is built first** ā the Virtual DOM, invisible to shoppers.\n 3. **Something happens** ā a click, a purchase, a price update.\n 4. **A new mockup is built** ā reflecting what the shop _should_ look like now.\n 5. **The renovation team compares old vs new mockup** ā **reconciliation** ; finding the differences is **diffing**.\n 6. **Only the real differences get carried out** on the actual shop floor.\n\n\n\nš¦ **Nephew:** So the trick is: mock it up quietly first, then make the smallest real change.\n\nšØāš¦³ **Uncle:** That's React's entire speed secret.\n\n## Part 4: Mall Security and the Smarter Priority System ā Fiber\n\nš¦ **Nephew:** What's \"React Fiber\" and \"Concurrent Rendering\"?\n\nšØāš¦³ **Uncle:** Meet **Mall Security** , whose job is deciding what needs attention right now.\n\nIn the _old_ mall, once security starts handling one task ā say, slowly walking a maintenance route ā they can't stop halfway, even if something urgent happens elsewhere (a customer needs help immediately at checkout). The urgent thing waits until the whole maintenance route finishes.\n\nš¦ **Nephew:** Like typing in a search bar while product images are still loading, and your typing freezes?\n\nšØāš¦³ **Uncle:** Exactly that. Old React handled updates one at a time, unable to interrupt itself for anything urgent.\n\n\n\n OLD SECURITY NEW SECURITY (FIBER)\n āāāāāāāāāāāāāā āāāāāāāāāāāāāāāāāāāāāā\n Follows one task start to finish Watches everything continuously\n Cannot break away mid-task Notices urgent situations instantly\n Urgent request must WAIT Switches attention immediately,\n resumes the paused task later\n\n\nš¦ **Nephew:** So Fiber is a new priority rulebook.\n\nšØāš¦³ **Uncle:** Exactly ā pause low-priority work (background image loading), jump to urgent work (your typing), resume the paused work later. Fully automatic.\n\n## Part 5: The Instruction Translator ā What JSX Really Is\n\nš¦ **Nephew:** Why do we write HTML-looking tags inside JavaScript?\n\nšØāš¦³ **Uncle:** Because the mall's actual construction crew (the browser) doesn't understand your friendly floor-plan format directly. Something translates it first ā that's **Babel**.\n\n\n\n ReactDOM.render(\n React.createElement('h1', null, 'Welcome!'),\n document.getElementById('mall-entrance')\n );\n\n\nSince React 17, the translation got leaner ā you don't need to import React into every file just to use JSX.\n\nThree small translation rules: every tag must properly close, `class` becomes `className`, multi-word instructions get joined, like `onClick`.\n\n## Part 6: The Shops ā Components\n\nš¦ **Nephew:** What exactly is a \"component\"?\n\nšØāš¦³ **Uncle:** One shop. A reusable unit that displays part of the mall's overall layout. The whole mall is built by arranging many small shops into sections.\n\n\n\n Mall\n / \\\n FoodCourt Electronics\n / \\ / \\\n Counter1 Counter2 Phones Laptops\n\n\nš¦ **Nephew:** Can the same shop type appear more than once?\n\nšØāš¦³ **Uncle:** Yes ā two \"Phones\" branches in different wings run completely independently. One branch's register doesn't affect the other's.\n\nTwo styles of building a shop:\n\n * **Function components** ā the modern style, a plain function returning what to display.\n * **Class components** ā the older, more formal style, with more setup ceremony.\n\n\n\nAn even older style, `React.createClass`, is long deprecated. The mall keeps modernizing its own construction rules.\n\n## Part 7: Supplied Stock vs. the Shop's Own Register ā Props and State\n\nš¦ **Nephew:** I always mix these up.\n\nšØāš¦³ **Uncle:** **Props are the stock Mall Management supplies to a shop.** The shop displays and sells it, but can't change what was supplied ā only Management restocks with something different.\n\n**State is the shop's own private register** ā today's sales count, whether the \"sale\" banner is currently on. The shop updates this itself, freely.\n\n\n\n Management\n ā (props flow down ā supplied stock)\n v\n Shop\n ā (messages flow up ā via a request form Management gave them)\n v\n Management\n\n\nš¦ **Nephew:** Why can't information flow both ways freely?\n\nšØāš¦³ **Uncle:** Then nobody could tell whether a display changed because a customer interacted with it, or because the stock itself changed. One-way flow keeps the whole mall predictable. And the strictest rule: a shop can never alter its own supplied stock. Try it, and Management just re-supplies the original at the next restock.\n\n## Part 8: Paperwork for the Older-Style Shops ā Class Components\n\nš¦ **Nephew:** Class components have this ritual with `this`, `bind`, `constructor`.\n\nšØāš¦³ **Uncle:** Formal opening-day paperwork, filed before the shop opens.\n\n**The constructor** ā the shop's registration form:\n\n\n\n constructor(props) {\n super(props);\n this.state = { salesCount: 0 };\n this.recordSale = this.recordSale.bind(this);\n }\n\n\n`super(props)` is how the shop formally acknowledges the supplied stock before using it on the form.\n\n**Binding** ā if a shop's \"record a sale\" instruction gets handed to a self-checkout kiosk to trigger, the shop's sense of \"who am I\" can get lost unless labeled beforehand. That labeling is `bind`.\n\n**Why`setState` isn't instant** ā React schedules updates and often batches several together, like the register updating its total _after_ the current transaction finishes, not interrupting mid-sale for every scribble.\n\n## Part 9: A Shop's Full Life ā Opening, Operating, Closing\n\n\n OPENING DAY DAILY OPERATION CLOSING\n (Mounting) (Updating) (Unmounting)\n āāāāāāāāāāāā āāāāāāāāāāāāāā āāāāāāāāāāāā\n constructor shouldComponentUpdate componentWillUnmount\n render render (cleanup: stop\n componentDidMount componentDidUpdate deliveries, remove\n sensors, lock up)\n\n\n`componentDidMount` fires the moment the shop opens ā safe to fetch initial stock data here. `shouldComponentUpdate` lets a shop say \"that change doesn't affect my floor ā skip re-arranging.\" `componentWillUnmount` fires right before closing ā cancel pending deliveries, remove motion sensors, stop background music.\n\nš¦ **Nephew:** What if a shop forgets that cleanup?\n\nšØāš¦³ **Uncle:** A **ghost shop problem** ā a memory leak. The shop closed, but a background delivery subscription it started keeps running anyway, costing resources for a shop that no longer exists.\n\n## Part 10: Hooks ā Giving Every Shop Standard Equipment\n\nš¦ **Nephew:** Why do hooks even exist?\n\nšØāš¦³ **Uncle:** Function-style shops used to have **no memory at all** between visits ā like a shop that forgets its own sales count the instant a customer leaves. Hooks gave them standard equipment, just like class-style shops always had.\n\n**`useState`** ā the register itself:\n\n\n\n const [salesCount, setSalesCount] = useState(0);\n\n\nYou're not editing the old ledger page directly ā `setSalesCount` requests a fresh page with the new total already written on it.\n\n**`useEffect`** ā a shop's standing instructions:\n\n\n\n useEffect(() => { /* runs once, on opening */ }, []);\n useEffect(() => { /* runs whenever salesCount changes */ }, [salesCount]);\n useEffect(() => {\n return () => { /* cleanup ā runs on closing */ };\n }, []);\n\n\n**`useRef`** ā a back-office drawer that doesn't trigger a storefront redraw when something's placed in it.\n\n**`useMemo` / `useCallback`** ā reusing yesterday's inventory count instead of recounting from scratch, when nothing's actually changed.\n\n**`React.memo`** ā telling a whole shop: \"if your supplied stock hasn't changed, skip redecorating the window.\" The class-shop equivalent is `React.PureComponent`.\n\n## Part 11: A Shop's Own Routine ā Custom Hooks\n\nš¦ **Nephew:** What if several shops need the exact same routine ā like \"track whether the mall's Wi-Fi is currently online\"?\n\nšØāš¦³ **Uncle:** One shop writes that routine once, and any other shop borrows a copy. That's a **custom hook**.\n\n\n\n function useWifiStatus() {\n const [online, setOnline] = useState(navigator.onLine);\n\n useEffect(() => {\n const update = () => setOnline(navigator.onLine);\n window.addEventListener('online', update);\n window.addEventListener('offline', update);\n return () => {\n window.removeEventListener('online', update);\n window.removeEventListener('offline', update);\n };\n }, []);\n\n return online;\n }\n\n function PaymentCounter() {\n const online = useWifiStatus();\n return <p>{online ? 'Card payments available' : 'Cash only right now'}</p>;\n }\n\n\nš¦ **Nephew:** So it's just organizing existing hooks under one name?\n\nšØāš¦³ **Uncle:** Exactly ā no new magic, just a reusable routine any shop can adopt.\n\n## Part 12: A Formal Ledger for Complicated Sales ā `useReducer`\n\nš¦ **Nephew:** What if a shop's register has many related fields, and updates depend on each other in complex ways?\n\nšØāš¦³ **Uncle:** Switch to a formal ledger system ā `useReducer`. Instead of writing directly, the shop submits a formal request (\"action\") to a strict accountant (the \"reducer\"), who decides exactly how the ledger updates.\n\n\n\n function reducer(state, action) {\n switch (action.type) {\n case 'sale': return { total: state.total + action.amount };\n case 'refund': return { total: state.total - action.amount };\n default: return state;\n }\n }\n\n const [ledger, dispatch] = useReducer(reducer, { total: 0 });\n dispatch({ type: 'sale', amount: 500 });\n\n\nš¦ **Nephew:** Sounds like Redux, but for one shop.\n\nšØāš¦³ **Uncle:** Exactly right ā `useReducer` is Redux's core idea, scaled to a single shop's own ledger.\n\n## Part 13: When a Shop Has a Crisis ā Error Boundaries\n\nš¦ **Nephew:** What if a shop has a total system failure ā say, its checkout software crashes?\n\nšØāš¦³ **Uncle:** Without protection, the _entire mall_ shuts down ā one shop's failure takes down everything. Real malls don't work that way.\n\nAn **Error Boundary** is a fire door around a section ā if a shop inside collapses, the boundary catches it, displays \"this section is temporarily unavailable,\" and the rest of the mall keeps operating normally.\n\n\n\n class ErrorBoundary extends React.Component {\n state = { hasError: false };\n static getDerivedStateFromError() { return { hasError: true }; }\n render() {\n if (this.state.hasError) return <p>This section is temporarily closed.</p>;\n return this.props.children;\n }\n }\n\n <ErrorBoundary>\n <RiskyShop />\n </ErrorBoundary>\n\n\n## Part 14: \"Back in 5 Minutes\" ā Suspense and Lazy Loading\n\nš¦ **Nephew:** What if a shop isn't ready yet ā still being fitted out?\n\nšØāš¦³ **Uncle:** Show a **\"back in 5 minutes\"** sign instead of an empty gap. That's **Suspense**.\n\n\n\n const LuxuryStore = React.lazy(() => import('./LuxuryStore'));\n\n <Suspense fallback={<p>This store is opening shortly...</p>}>\n <LuxuryStore />\n </Suspense>\n\n\n`React.lazy` means: don't build and fit out a shop's entire interior until a shopper actually walks toward that section. If your mall has fifty stores, why make every visitor wait for all fifty to be fully constructed before the doors even open?\n\n\n\n WITHOUT lazy loading WITH lazy loading\n āāāāāāāāāāāāāāāāāāāāā āāāāāāāāāāāāāāāāāā\n Build ALL 50 shops Build only the shops needed\n before opening the doors for the entrance area\n ā ā\n Slow grand opening Fast opening ā other shops\n built only as shoppers approach\n\n\n## Part 15: Invisible Groupings and Shops That Appear Elsewhere ā Fragments and Portals\n\nš¦ **Nephew:** Sometimes I need to return two shops from one section, but React wants a single wrapper.\n\nšØāš¦³ **Uncle:** Use a **Fragment** ā an invisible grouping with no extra physical structure added.\n\n\n\n return (\n <>\n <ShopOne />\n <ShopTwo />\n </>\n );\n\n\nš¦ **Nephew:** And something like a popup announcement that appears floating over the whole mall?\n\nšØāš¦³ **Uncle:** That's a **Portal** ā logically still part of your section (still gets its supplied stock and register access normally), but physically displayed somewhere else entirely, like a mall-wide announcement screen built specifically for overlays.\n\n\n\n ReactDOM.createPortal(<AnnouncementModal />, document.getElementById('modal-root'));\n\n\n## Part 16: The Opening-Day Inspector ā StrictMode\n\nš¦ **Nephew:** What does `<React.StrictMode>` do?\n\nšØāš¦³ **Uncle:** An inspector who deliberately makes shops **run their opening routine twice** , during development only ā specifically to catch shops that accidentally rely on leftover setup from the first run instead of starting cleanly each time. It never runs these extra checks in the live, real mall ā only during rehearsal.\n\n## Part 17: The Sticky Note in the Drawer ā Stale Closures\n\nš¦ **Nephew:** My `useEffect` keeps using an old value, even after it clearly changed. What's happening?\n\nšØāš¦³ **Uncle:** A **stale closure**. A shop writes a sticky note at the start of a routine and keeps referring back to that same note all day ā even if the real number has changed since.\n\n\n\n useEffect(() => {\n const interval = setInterval(() => {\n console.log(salesCount); // frozen at whatever it was when this ran\n }, 1000);\n return () => clearInterval(interval);\n }, []); // empty array = write the note once, never refresh it\n\n\nFix: tell the routine to write a fresh note whenever the real value changes.\n\n\n\n useEffect(() => {\n const interval = setInterval(() => {\n console.log(salesCount); // always fresh now\n }, 1000);\n return () => clearInterval(interval);\n }, [salesCount]);\n\n\n## Part 18: The Checkout Counter ā Controlled and Uncontrolled Forms\n\nš¦ **Nephew:** Forms confuse me most.\n\nšØāš¦³ **Uncle:** Picture a checkout counter.\n\n**Controlled** ā Management watches and records every single item scanned, live, the instant it happens:\n\n\n\n <input value={value} onChange={(e) => setValue(e.target.value)} />\n\n\n**Uncontrolled** ā the cashier keeps their own running total, and Management only checks the final receipt at the end:\n\n\n\n const inputRef = useRef();\n <input ref={inputRef} defaultValue=\"\" />\n // Management checks inputRef.current.value only at submit\n\n\nControlled is more common ā Management usually wants instant feedback, like flagging an invalid coupon code as it's typed.\n\n## Part 19: Deciding What's Displayed ā Conditionals and Lists\n\n\n {isMember ? <VIPLounge /> : <PublicWaitingArea />}\n\n\n\"If true, display this; otherwise, display that.\"\n\nFor a whole row of similar shops (a food court, say), use `.map()`, but every item needs a `key` ā a shop number pinned to each unit, so the renovation team knows exactly which one moved, was added, or removed.\n\n\n\n {stalls.map(stall => <FoodStall key={stall.id} data={stall} />)}\n\n\n## Part 20: Before the Doors Open ā How the Page Actually Loads\n\n\n 1. Blueprint arrives ā raw HTML reaches the browser\n 2. Interior design applied ā CSS applied, layout and colors appear\n 3. Staff/equipment arrives ā JavaScript (React) downloads\n 4. Mockup built ā React builds its Virtual DOM\n 5. Doors open ā React places everything on the real floor\n 6. (if applicable)\n Frozen displays wake up ā Hydration\n\n\nIf shops arrive **already fully built and stocked** before doors open ā **Server-Side Rendering** ā shoppers see a complete mall immediately. But those shops are frozen displays until React \"wakes them up,\" attaching working registers and staff. That's **Hydration**.\n\nIf instead the mall opens as an **empty shell** , waiting for construction crews to arrive before building anything ā **Client-Side Rendering** ā shoppers initially see nothing.\n\nEither way, shoppers only ever experience plain floors, plain lighting, plain signage. In web terms: the browser only ever receives plain HTML, CSS, JavaScript. JSX, hooks, components are just a better-organized way for _you_ to produce that final result.\n\n## Part 21: The City Guide Listing ā Why Next.js Matters for Being Found\n\nš¦ **Nephew:** Why do people add Next.js on top of React?\n\nšØāš¦³ **Uncle:** Imagine a city guide inspector visits your mall _before construction finishes_. The shell is empty. They walk away and list your mall as \"nothing here.\"\n\nThat's what a search engine's crawler does to pure Client-Side Rendering ā visits, sees an empty shell, reports \"empty page.\" Next.js fixes this by ensuring the mall is **already built** before anyone peeks in:\n\n * **Server-Side Rendering** ā build it fresh, for every visitor, on request, or\n * **Static Site Generation** ā build it once, ahead of time, and hand out a ready photograph instantly.\n\n\n\nEither way, the inspector always sees a fully built, meaningful mall.\n\n## Part 22: Mall-Wide Communication ā Context, Redux, React Query\n\nš¦ **Nephew:** What about Redux, Context, React Query?\n\nšØāš¦³ **Uncle:** Picture the mall grown huge ā many floors, fifty shops, information that needs to travel between shops that aren't near each other. Passing a message shop-to-shop through everyone in between gets messy fast. That's \"prop drilling.\"\n\n * **Context** ā a mall-wide PA announcement system. Any shop tunes in directly. Good for things that rarely change, like \"which membership tier is currently browsing.\"\n * **Redux** ā a proper Central Management Office. All important information lives in one official ledger. Shops don't edit it directly ā they submit a formal request (\"action\"), and a strict rulebook (\"reducer\") decides how it updates.\n * **React Query** ā a dedicated logistics team whose only job is talking to **outside suppliers** (an external API). Fetches, remembers recent orders so it doesn't ask twice unnecessarily, quietly refreshes stock in the background.\n\n\n\nš¦ **Nephew:** If one small thing changes, does the whole mall rebuild?\n\nšØāš¦³ **Uncle:** No ā only the shop whose register or supplied stock actually changed, plus anything directly depending on it. Keep registers as local as possible, use `React.memo` generously, split PA channels by topic instead of one giant announcement for everything.\n\n## Part 23: Getting Around the Mall ā Routing\n\nš¦ **Nephew:** How do multiple pages actually work in a React app?\n\nšØāš¦³ **Uncle:** This is where the mall shines as a picture. A single-page app is really a mall with **one shared floor structure** ā entrance, corridors, PA system ā and different **sections** slide into view depending on where the directory board points you.\n\n\n\n Mall Directory Board (Router)\n / | \\\n /electronics /food-court /membership\n ā ā ā\n Electronics FoodCourt MembershipDesk\n Section Section (protected)\n\n\n**Routes** are sections of the mall:\n\n\n\n <Routes>\n <Route path=\"/electronics\" element={<Electronics />} />\n <Route path=\"/food-court\" element={<FoodCourt />} />\n <Route path=\"/membership\" element={<MembershipDesk />} />\n </Routes>\n\n\nš¦ **Nephew:** What about a department store that has its own smaller sections inside it ā like Electronics has a Phones sub-section and a Laptops sub-section?\n\nšØāš¦³ **Uncle:** **Nested routes** ā the outer shop (Electronics) keeps its own shared shelving and signage (a layout), while only the inner sub-section changes as you walk around inside it.\n\n\n\n <Route path=\"/electronics\" element={<ElectronicsLayout />}>\n <Route path=\"phones\" element={<Phones />} />\n <Route path=\"laptops\" element={<Laptops />} />\n </Route>\n\n\nš¦ **Nephew:** And the Membership Desk ā that needs a card to even enter?\n\nšØāš¦³ **Uncle:** A **protected route** ā a checkpoint before the section, checking for a valid membership card (an auth token) before letting the visitor walk in. No card, redirect them to the sign-up counter instead.\n\n\n\n function ProtectedRoute({ children }) {\n const isMember = useAuth();\n if (!isMember) return <Navigate to=\"/join\" />;\n return children;\n }\n\n <Route path=\"/membership\" element={\n <ProtectedRoute><MembershipDesk /></ProtectedRoute>\n } />\n\n\nš¦ **Nephew:** So the directory board (router) decides which section to render, nested routes are stores-within-stores, and protected routes are checkpoints?\n\nšØāš¦³ **Uncle:** Exactly the whole picture ā and notice it's the _same_ mall the whole time. No page reload, no new building. The router just swaps which section is currently visible, reusing the shared corridors and PA system underneath.\n\n## Part 24: Putting the Whole Mall Together\n\n\n 1. Blueprint translated (Babel), bundled ā some sections maybe pre-built (Next.js)\n 2. Visitor arrives ā sees an already-built mall (SSR/SSG) or an empty shell (CSR)\n 3. Doors visually open ā HTML/CSS paint immediately\n 4. Displays wake up ā Hydration attaches interactivity\n 5. Shopper walks around ā Security (Fiber) prioritizes what needs attention\n 6. The directory board routes them to a section (Router)\n 7. A change happens ā mockup built, diffed, only real changes reach the floor\n 8. A shop eventually closes ā cleanup runs, nothing left running needlessly\n\n\nš¦ **Nephew:** So React isn't magic ā it's an extremely well-organized construction, priority, and navigation system.\n\nšØāš¦³ **Uncle:** Exactly. The day you can explain _why_ each piece exists ā not just name it ā is the day you've actually understood React.\n\n## Quick Reference ā Uncle's Cheat Sheet\n\nIdea | In one line\n---|---\nVirtual DOM | A private design-studio mockup, checked before touching the real floor\nReconciliation / Diffing | Comparing old and new mockups to find what changed\nReact Fiber | Smarter Mall Security ā can pause and reprioritize\nConcurrent Rendering | Letting urgent shopper needs jump ahead of background work\nJSX | Friendly floor-plan format, translated by Babel\nProps | Stock Management supplies to a shop (read-only)\nState | A shop's own private, changeable register\n`useState` | Gives a function-shop a register\n`useEffect` | Opening, updating, and closing instructions\n`useRef` | A back-office drawer that doesn't trigger a redraw\n`useMemo` / `useCallback` | Reusing yesterday's count instead of recounting\n`React.memo` | \"Skip redecorating if supplied stock hasn't changed\"\nCustom Hook | A reusable routine any shop can borrow\n`useReducer` | A formal accountant deciding ledger updates\nError Boundary | A fire door ā contains a crisis to one section\nSuspense / `React.lazy` | \"Back in 5 minutes\" sign; build shops only when needed\nFragment | An invisible grouping, no extra structure\nPortal | A shop rendering physically elsewhere, logically still in the tree\nStrictMode | An inspector forcing double-runs to catch bugs early\nStale closure | An old sticky note, never refreshed\nControlled input | Management watches and records live\nUncontrolled input | Cashier keeps their own running total, checked at the end\nHydration | Waking up already-built, frozen displays\nSSR | Building fresh, for every visitor\nSSG | Building once, reusing the photograph\nRedux | A central management office, one official ledger\nContext | A mall-wide PA announcement system\nReact Query | The logistics team talking to outside suppliers\nRouter | The directory board deciding which section shows\nNested Routes | Stores-within-stores, sharing an outer layout\nProtected Routes | A checkpoint requiring a membership card\n\n_\"Less noise, more action.\"_ For each idea, be able to say out loud what real problem it solves ā that's worth more than memorizing hook names.",
"title": "The Mall of React: An Uncle-Nephew Guide"
}