React Compound Components Simplified

Ever wondered why changing one small thing in React doesn’t re-render the entire UI? 🤔 That’s reconciliation. In React, every update creates a new virtual DOM. But instead of updating everything, React compares the new tree with the previous one - and updates only what changed. Sounds simple, but small mistakes can break performance. 😬 • Missing or unstable keys ➡️ unnecessary re-renders • Recreating objects/functions ➡️ diffing becomes expensive • Large component trees ➡️ slower updates React is fast. But only if we help it. Reconciliation is not magic - it’s an optimization strategy based on assumptions. Understanding it changes how you structure components. 😉 Have you ever fixed a performance issue just by adding proper keys or memoization? #reactjs #frontend #webperformance #javascript #learninginpublic

𝗠𝗼𝘀𝘁 𝗥𝗲𝗮𝗰𝘁 𝗗𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝗢𝘃𝗲𝗿𝘂𝘀𝗲 𝘂𝘀𝗲𝗦𝘁𝗮𝘁𝗲 Not everything in React needs to be state. But many developers still store everything in useState. That leads to: • Unnecessary re-renders • Extra complexity • Harder-to-maintain components Here’s a simple way to think about it: 👉 If it affects the UI → use state 👉 If it doesn’t → use useRef useRef lets you store values across renders without triggering a re-render. This makes it perfect for things like: • Storing timers • Tracking previous values • Accessing DOM elements • Keeping mutable values Using state where a ref is enough is a common mistake. And over time, it impacts performance and code clarity. 👇 Simple comparison below Day 20/100 — sharing practical frontend engineering lessons. Do you usually default to state or think before choosing? #ReactJS #FrontendEngineering #JavaScript #WebDevelopment #SoftwareEngineering

How React Remembers State Between Renders? When a component re-renders, the function runs again from top to bottom. So how does useState not reset every time? 🤔 function Counter() { const [count, setCount] = React.useState(0); return <button onClick={() => setCount(count + 1)}>{count}</button>; } Every render: The function runs again and Variables are recreated. So why doesn’t count go back to 0? What Actually Happens Internally React stores state outside the component function. Behind the scenes: 1) Each component has a Fiber node 2) React keeps a linked list of Hooks 3) It tracks Hooks based on call order State is not stored in your function. It’s stored in React’s internal Fiber system. The function is just a way for React to describe UI. Understanding this makes Hooks feel much less magical. #ReactJS #ReactInternals #ReactHooks #FrontendDevelopment #SoftwareEngineering #JavaScript

Classic: Why is my ellipsis broken? It’s always funny watching a complex layout crumble because of a single line of CSS. You throw text-overflow: ellipsis at an element, but it just keeps pushing its neighbors around like it owns the place. The "Why": In Flexbox and Grid, items have min-width: auto by default. Your content is literally "too strong" for the container—it refuses to shrink smaller than the text itself. Until you give it permission to "slim down," that ellipsis isn't doing anything. The Irony: We build enterprise-grade apps with React and TypeScript, yet 50% of "broken" layouts are fixed by zeroing out a single property. If your 1fr column is acting up, you know what to do. #css #frontend #webdev #typescript #javascript #react #ui

useRef doesn't trigger re-renders. Here's why - useRef just returns this: { current: value } A plain object. Nothing reactive about it. Changing ref.current = newValue is like editing a JS object property. React has no idea it happened. useState is different — setState notifies React's scheduler. That notification is what causes a re-render. useRef skips that notification entirely. By design. Use it for: ✅ DOM refs (input.focus()) ✅ Timer IDs (clearInterval) ✅ Previous values ✅ Anything your logic needs but the UI doesn't Simple mental model: useState → remember + re-render useRef  → remember silently #React #JavaScript #Frontend #ReactHooks

🚀 10 React Design Patterns Every Developer Should Know As React applications grow, maintaining clean and scalable code becomes challenging. Using the right design patterns helps structure components better and improves reusability. Here are 10 React design patterns worth knowing 👇 1️⃣ Compound Components Pattern 2️⃣ Higher Order Components (HOC) 3️⃣ Render Props Pattern 4️⃣ Controlled Components 5️⃣ Custom Hooks Pattern 6️⃣ Provider Pattern (Context API) 7️⃣ Container / Presentational Pattern 8️⃣ State Reducer Pattern 9️⃣ Prop Getters Pattern 🔟 Compound Hook Pattern 💡 Understanding these patterns helps in building clean, scalable, and maintainable React applications. #React #Frontend #JavaScript #SoftwareEngineering #WebDevelopment

"Mastering React starts with its core building blocks: Components, Props, State, and Hooks (especially useState). Components are the reusable pieces of your UI, passing data down via props (read-only) while managing dynamic behavior through state. With the introduction of Hooks in React 16.8, useState revolutionized how we handle local state in functional components — no more class boilerplate! A quick reminder: Props → Data flow from parent to child (immutable from child's perspective) useState → [value, setValue] = useState(initialValue) — triggers re-renders on updates #ReactJS #JavaScript #FrontendDevelopment #WebDevelopment #ReactHooks"

Most React performance advice is wrong. Not because the patterns are bad but because developers apply them without understanding what React is actually doing. Here’s what I’ve learned: React.memo without useCallback is just theater. memo tells React: “Only re-render if prop references change.” But if you pass a new function reference on every render, memo does absolutely nothing. // ❌ Kills memo on every render <ProductCard onSelect={(id) => handleSelect(id)} /> // ✅ Actually works const handleSelect = useCallback((id) => { dispatch({ type: "SELECT", payload: id }); }, [dispatch]); useMemo has a cost use it surgically. React still performs dependency comparison on every render. For cheap computations, the memoization overhead can be higher than simply recalculating. Use useMemo only when: the computation is genuinely expensive the result is passed to a memoized child you’ve measured it, not assumed it Before reaching for memo or useMemo, ask: What is actually triggering the re-render? Can you eliminate the trigger instead of memoizing around it? Structural state changes beat memoization every time. What’s the nastiest React performance bug you’ve hit in production? #React #ReactJS #Frontend #TypeScript #WebDevelopment #MERN #JavaScript #SoftwareEngineering

Today, I stopped building "Prop-Heavy" components and started building Systems. I’ve officially implemented the Compound Component Pattern in my React frontend. The Architectural Shift: Prop-Drilling Extinguished: By using React Context within my component families, I no longer have to pass state through layers of unnecessary props. Developer Experience (DX): My components are now much more intuitive to use. They read like HTML, making the UI structure clear at a glance. Maximum Flexibility: I can now reorder titles, buttons, or status badges inside my Task Cards without touching the underlying component logic. Scalability: This is how the pros build UI libraries. It makes the codebase significantly easier to maintain as the project complexity increases. The Aha! Moment: A good component isn't just one that works; it is one that is a joy for other developers to use. Moving from "Rigid Props" to "Flexible Compounds" is like moving from a fixed menu to a buffet - you get exactly what you need, exactly where you want it. Clean code is a competitive advantage. #ReactJS #WebArchitecture #FrontendEngineering #100DaysOfCode #CleanCode #JavaScript #Day82 #Adityanandan #Theadityanandan