Why Unique Keys Are Essential in React

Why does the same React component behave differently on each render? You wrote it once.... Same code. Same props. But sometimes: → It shows different data → It lags → It resets Looks like a bug… But often, it’s just React doing its job. 𝗛𝗲𝗿𝗲’𝘀 𝘄𝗵𝗮𝘁’𝘀 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝗵𝗮𝗽𝗽𝗲𝗻𝗶𝗻𝗴: Every time a parent component re-renders — every child inside it re-renders too. React re-runs the component function to check what changed. Even if props look the same. 𝗛𝗼𝘄 𝘁𝗼 𝘁𝗲𝗹𝗹 𝗥𝗲𝗮𝗰𝘁 𝘁𝗼 𝘀𝗸𝗶𝗽 𝗿𝗲-𝗿𝗲𝗻𝗱𝗲𝗿: Wrap your component in React.memo() const Card = React.memo(({ name }) => {  return <div>{name}</div> } Now React skips re-rendering Card  unless its props actually change. Same component. Smarter behavior. 𝗥𝗲-𝗿𝗲𝗻𝗱𝗲𝗿 𝗵𝗮𝗽𝗽𝗲𝗻𝘀 𝘄𝗵𝗲𝗻: → State changes → Props change → Parent re-renders `React.memo` stops the third one (when props are stable). 𝗣𝗿𝗼 𝘁𝗶𝗽: If memo isn't skipping, check if you're passing new functions/objects/arrays every time — those break the shallow compare. Fix with 𝘶𝘴𝘦𝘊𝘢𝘭𝘭𝘣𝘢𝘤𝘬/𝘶𝘴𝘦𝘔𝘦𝘮𝘰. Understanding this is the difference between “it works” and “it scales.” Save this — next time re-renders confuse you, you’ll know exactly why. Have you ever had unexpected  re-renders break your app? Drop it below 👇 Follow for more React concepts  explained simply. #reactjs #webdevelopment #javascript #MERN

🚀 Controlled vs Uncontrolled Components in React — Real-World Perspective Most developers learn: 👉 Controlled = React state 👉 Uncontrolled = DOM refs But in real applications… 👉 The choice impacts performance, scalability, and maintainability. 💡 Quick Recap 🔹 Controlled Components: Managed by React state Re-render on every input change 🔹 Uncontrolled Components: Managed by the DOM Accessed via refs ⚙️ The Real Problem In large forms: ❌ Controlled inputs → Too many re-renders ❌ Uncontrolled inputs → Hard to validate & manage 👉 So which one should you use? 🧠 Real-world Decision Rule 👉 Use Controlled when: ✔ You need validation ✔ UI depends on input ✔ Dynamic form logic exists 👉 Use Uncontrolled when: ✔ Performance is critical ✔ Minimal validation needed ✔ Simple forms 🔥 Performance Insight Controlled input: <input value={name} onChange={(e) => setName(e.target.value)} /> 👉 Re-renders on every keystroke Uncontrolled input: <input ref={inputRef} /> 👉 No re-render → better performance ⚠️ Advanced Problem (Most devs miss this) 👉 Large forms with 20+ fields Controlled approach: ❌ Can slow down typing 👉 Solution: ✔ Hybrid approach ✔ Use libraries (React Hook Form) 🧩 Industry Pattern Modern apps often use: 👉 Controlled logic + Uncontrolled inputs internally Example: ✔ React Hook Form ✔ Formik (optimized patterns) 🔥 Best Practices ✅ Use controlled for logic-heavy forms ✅ Use uncontrolled for performance-critical inputs ✅ Consider form libraries for scalability ❌ Don’t blindly use controlled everywhere 💬 Pro Insight (Senior Thinking) 👉 This is not about “which is better” 👉 It’s about choosing the right tool for the problem 📌 Save this post & follow for more deep frontend insights! 📅 Day 17/100 #ReactJS #FrontendDevelopment #JavaScript #ReactHooks #PerformanceOptimization #SoftwareEngineering #100DaysOfCode 🚀

You think this React code will increment the counter to 2? Maga Look again.👇🐘🐘🐘 function App() { const [count, setCount] = useState(0); const handleClick = () => { setTimeout(() => { setCount(count + 1); }, 1000); setCount(count + 1); }; return ( <> <p>{count}</p> <button onClick={handleClick}>Click</button> </> ); } Most developers say: 👉 “First +1 immediately, then +1 after 1 second → final = 2” ❌ Wrong 🧠 What actually happens setCount(count + 1) → updates to 1 setTimeout callback runs later… But it uses stale count = 0 (closure!) 👉 So it sets 1 again 🎯 Final Result Count = 1, not 2 🚨 The real problem This is not a React bug This is a JavaScript closure + event loop problem Functions capture old state Async callbacks don’t magically get updated values React state is snapshot-based, not live ✅ Fix setCount(prev => prev + 1); ✔ Always use functional updates when state depends on previous value ✔ Works correctly with async (timeouts, promises, events) 💡 Takeaway If your mental model is: 👉 “state updates automatically everywhere” You’ll ship bugs. If your mental model is: 👉 “state is captured at execution time” You’ll write predictable systems. This is the difference between writing code that works… and code that scales in production. USE prev maga 😍 setCount(prev => prev + 1); 🐘🐘🐘 #ReactJS #JavaScript #Frontend #WebDevelopment #Debugging #EventLoop

Have you ever needed to touch the DOM directly while working in React? React is designed to be declarative. You describe the UI based on state, and the library handles the updates. But occasionally, you need what we call an 'escape hatch.' This is precisely where 'refs' come into play. They provide a way to access a DOM node or a React element directly, bypassing the standard re-render cycle. The most common reason to reach for a ref is to manage things like focus, text selection, or media playback. If you need a specific input field to focus the moment a page loads, you cannot easily do that with state alone. You need to reach into the DOM and call the native '.focus()' method. Beyond the DOM, refs are also perfect for storing any mutable value that needs to persist across renders without triggering a UI update. This includes things like timer IDs or tracking previous state values for comparison. However, with great power comes responsibility. Using refs is essentially stepping outside of the React ecosystem and taking manual control. If you can achieve your goal using props and state, you should. Overusing refs can make your components harder to debug and breaks the predictable flow of data that makes React so reliable. It is a tool for the edge cases, not the daily routine. Use it when you need to talk to the browser directly, but keep your core logic declarative. #ReactJS #SoftwareEngineering #WebDevelopment #Javascript #Frontend #CodingTips

💡 Understanding a subtle React concept: Hydration & “bailout” behavior One interesting nuance in React (especially with SSR frameworks like Next.js) is how hydration interacts with state updates. 👉 Hydration is the process where React makes server-rendered HTML interactive by attaching event listeners and syncing state on the client. When a page is server-rendered, the initial HTML is already in place. During hydration, React attaches event listeners and syncs the client state with that UI. Here’s the catch 👇 👉 If the client-side state matches what React expects, it may skip updating the DOM entirely. This is due to React’s internal optimization often referred to as a “bailout”. 🔍 Why this matters In cases like theme handling (dark/light mode): If the server renders a default UI (say light mode ☀️) And the client immediately initializes state to dark mode 🌙 React may still skip the DOM update if it doesn’t detect a meaningful state transition 👉 Result: UI can temporarily reflect the server version instead of the actual state. 🧠 Conceptual takeaway A more reliable pattern is: ✔️ Start with an SSR-safe default (consistent with server output) ✔️ Then update state after hydration (e.g., in a layout effect) This ensures React sees a real state change and updates the UI accordingly. 🙌 Why this is fascinating It highlights how deeply optimized React is — sometimes so optimized that understanding its internal behavior becomes essential for building predictable UI. Grateful to the developer community for continuously sharing such insights that go beyond surface-level coding. 🚀 Key idea In SSR apps, correctness isn’t just about what state you set — it’s also about when React observes the change. #ReactJS #NextJS #FrontendDevelopment #WebDevelopment #JavaScript #Learning

If you’re writing 5 files just to toggle a boolean... 🛑 You’re not scaling. You’re over-engineering. For a long time, I used Redux for almost everything in React. And honestly? It felt powerful... but also unnecessarily complex for 90% of my use cases. Recently, I switched to Zustand — and the difference is 🔥 Why Zustand just makes sense: ✅ Zero Boilerplate No Providers. No massive folder structures. Just create and use. ✅ Hook-Based If you know useState, you already understand Zustand. It feels like native React. ✅ Performance First It handles selective re-renders out of the box. Only the components that need the data will update. 💻 The "Store" is this simple: JavaScript import { create } from 'zustand' const useStore = create((set) => ({ count: 0, inc: () => set((state) => ({ count: state.count + 1 })), })) Use it anywhere: JavaScript function Counter() { const { count, inc } = useStore() return <button onClick={inc}>{count}</button> } ⚡ 𝗣𝗥𝗢 𝗠𝗢𝗩𝗘 (Most developers miss this): Use selectors to grab only what you need: const count = useStore((state) => state.count) This keeps your app lightning-fast even as your state grows massive. 📈 Since switching, my code is: → Simpler → Cleaner → Easier to maintain 🟣 Team Redux (The tried and true) 🐻 Team Zustand (The minimalist) #ReactJS #Zustand #JavaScript #WebDevelopment #Frontend #CodingTips #SoftwareEngineering

Why do we specifically pass 'props' into 'super(props)' in a React component constructor? It is one of those things many developers do out of habit without realizing the actual mechanism behind it. While calling 'super()' is a JavaScript requirement to initialize the 'this' keyword, passing 'props' is a very specific React requirement for the constructor phase. The reason is simple: visibility. When you call 'super(props)', you are telling the parent 'React.Component' class to initialize 'this.props' for you immediately. If you only call 'super()' without the argument, 'this.props' will be undefined inside the constructor. React eventually assigns props to the instance anyway, but that happens after the constructor has finished running. If your logic requires you to access a property or compute a state based on a prop right inside the constructor, forgetting the 'props' argument will crash your logic. You would be trying to read from a variable that hasn't been wired up to the instance yet. Even though modern React code bases have shifted to Functional Components where this ceremony is gone, the underlying logic of when data becomes available to an instance is a core part of the library’s history. It is a small detail that perfectly illustrates how React works under the hood. #ReactJS #Javascript #SoftwareEngineering #FrontendDevelopment #WebDev #CodingTips

A lot of people constantly ask me what React Hooks actually are, and the best way to think about Hooks and JavaScript concepts in general is to look at what problem they were trying to fix. For example, before React Hooks, people would create a Container Component and a Presentational Component. The Container Component would retrieve data, like making a fetch request, and then pass that data down to the Presentational Component, which was usually a pure function that returned some UI, like a div with styling, and accepted that data as props. This pattern helped create a standard for how data was retrieved in React and enforced separation of concerns, but it ended up being too boilerplate heavy for most people. So Hooks were introduced to let us hook into components directly, allowing us to load data as a side effect inside a function while still maintaining separation of concerns without needing extra components. #ReactJs #JavaScript #JavaScriptHooks

Most React devs know when to use useLayoutEffect. Almost none can explain why it behaves differently. The answer lives inside the commit phase. React's update cycle has two big stages: render (reconcile, diff, no DOM writes) and commit (apply changes, run effects). Commit itself splits into 3 sub-phases: → Before Mutation — read DOM snapshots before anything changes → Mutation — insert, update, remove DOM nodes → Layout — refs attached, useLayoutEffect fires here, synchronously useEffect never runs in the Layout pass. During reconciliation, React builds an Effect List — fiber nodes tagged with pending work. Fibers marked HookLayout flush during the Layout sub-phase. Fibers marked HookPassive get handed to the scheduler and run after the browser paints. React docs put it directly: "React guarantees that the code inside useLayoutEffect and any state updates scheduled inside it will be processed before the browser repaints the screen." Classic case where this matters: tooltip positioning. With useEffect, users catch a flicker — the tooltip renders in the wrong spot, then jumps. With useLayoutEffect, both renders complete before any pixel changes on screen. The tradeoff: useLayoutEffect blocks paint. Use it only when you need to measure or mutate the DOM before the user sees the frame. Data fetching, subscriptions, analytics — those belong in useEffect. One gotcha: useLayoutEffect is a no-op in SSR. React will warn you. Guard with typeof window !== 'undefined' or default to useEffect in universal code. #frontend #reactjs #javascript #typescript #frontenddevelopment #softwareengineering #webdevelopment

Why does your 'ref' return 'null' the moment you wrap your input in a custom component? It is one of those React quirks that trips up even experienced developers. By default, refs do not behave like props. They are treated as special instances that stop at the component boundary to protect encapsulation. This is exactly why we need 'forwardRef'. It acts as a bridge that allows a parent component to reach through a child and grab a direct handle on an internal DOM node. The most practical application is building a reusable UI library. If you create a custom 'Input' or 'Button' component, your parent component might need to call '.focus()' or '.scrollIntoView()'. Without 'forwardRef', your parent is just holding a reference to a React internal object, not the actual HTML element. Another real-world scenario involves Higher-Order Components (HOCs). If you wrap a component with a 'withAnalytics' or 'withTheme' wrapper, that wrapper will 'swallow' the ref by default. By using 'forwardRef' in your HOC implementation, you ensure the reference passes through the wrapper and lands on the component that actually needs it. It is about making your abstractions transparent and ensuring that the parent component maintains the control it expects over the physical DOM. Using this pattern sparingly is key. It is an escape hatch for those moments where declarative state isn't enough to manage physical browser behavior. It keeps your component interfaces clean while providing the necessary access for specialized UI interactions. #ReactJS #SoftwareEngineering #Frontend #WebDevelopment #Javascript #CodingTips #CodingBestPractices