Thanuja S’ Post

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

React.memo doesn't prevent re-renders. It just changes why they happen. ⚠️ You think it's optimized. The Profiler says otherwise. 𝗧𝗵𝗲 𝗺𝗼𝘀𝘁 𝗰𝗼𝗺𝗺𝗼𝗻 𝗺𝗶𝘀𝘁𝗮𝗸𝗲: function Parent() { const config = { theme: 'dark' }; // new object → new reference const handleClick = () => console.log('clicked'); // new function → new reference return <Child config={config} onClick={handleClick} />; } const Child = React.memo(({ config, onClick }) => { return <button onClick={onClick}>{config.theme}</button>; }); React.memo does a shallow comparison. config and handleClick are new references on every render — so Child re-renders every time. The memo did nothing. 𝗧𝗵𝗲 𝗳𝗶𝘅 — 𝘀𝘁𝗮𝗯𝗶𝗹𝗶𝘀𝗲 𝘁𝗵𝗲 𝗿𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲𝘀: function Parent() { const config = useMemo(() => ({ theme: 'dark' }), []); const handleClick = useCallback(() => console.log('clicked'), []); return <Child config={config} onClick={handleClick} />; } Stable UI requires stable references. 𝗪𝗵𝗲𝗻 𝗥𝗲𝗮𝗰𝘁.𝗺𝗲𝗺𝗼 𝗶𝘀 𝗮𝗰𝘁𝘂𝗮𝗹𝗹𝘆 𝘄𝗼𝗿𝘁𝗵 𝗶𝘁: 1️⃣ 𝗣𝗿𝗼𝗽𝘀 𝗮𝗿𝗲 𝗽𝗿𝗶𝗺𝗶𝘁𝗶𝘃𝗲𝘀 𝗼𝗿 𝘀𝘁𝗮𝗯𝗶𝗹𝗶𝘀𝗲𝗱 𝗿𝗲𝗳𝗲𝗿𝗲𝗻𝗰𝗲𝘀 Objects and functions without memoization = wasted effort. Strings, numbers, booleans compare correctly by default. 2️⃣ 𝗧𝗵𝗲 𝗰𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁 𝗶𝘀 𝗴𝗲𝗻𝘂𝗶𝗻𝗲𝗹𝘆 𝗲𝘅𝗽𝗲𝗻𝘀𝗶𝘃𝗲 𝘁𝗼 𝗿𝗲𝗻𝗱𝗲𝗿 If the render is cheap, the comparison is the bottleneck. 3️⃣ 𝗬𝗼𝘂 𝗺𝗲𝗮𝘀𝘂𝗿𝗲𝗱 𝗶𝘁 𝗳𝗶𝗿𝘀𝘁 If you didn't measure it, you didn't optimize it. Open the Profiler. Find the actual bottleneck before reaching for the API. ⚠️ React.memo without stable references is optimisation theatre. It looks like performance work. It isn't. 🎯 𝗧𝗵𝗲 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆 Memoisation is a tool, not a default. Reach for the Profiler before you reach for the API. 💬 Where did React.memo fool you into thinking something was optimized? Drop it below. 👇 #ReactJS #SoftwareEngineering #WebDev #FrontendEngineering #JavaScript

Everything inside your component is recreated on every render. Most developers know this. But very few actually feel the impact of it. I didn’t… until it started affecting performance in a real feature. When React re-renders a component, it doesn’t “update” it. It runs the entire function again. That means: • Variables are re-created   • Functions get new references   • Objects & arrays become new instances  Even if the UI looks exactly the same. At first, this feels harmless. Until you see something like this 👇 A small state change in parent →   Triggers multiple child re-renders →   No visible bug → but UI becomes slower  The problem wasn’t React. It was this: const data = { value: count }; const handleClick = () => doSomething(); Looks fine. But on every render: - data is a new object   - handleClick is a new function  And React sees: “New reference = something changed” The real issue is not re-rendering. It’s uncontrolled identity changes. That’s when these stopped being “optimizations” for me: • React.memo   • useCallback   • useMemo  And became tools to control behavior. The shift that matters: Don’t ask: Why did it re-render? Ask: What changed by reference? Once you understand this, you stop writing React casually. And start writing it intentionally. Curious — what’s one time React rendering surprised you? #ReactJS #Frontend #JavaScript #WebDevelopment #SoftwareEngineering #DevLife

𝐇𝐨𝐰 𝐈 𝐑𝐞𝐝𝐮𝐜𝐞𝐝 𝐑𝐞𝐚𝐜𝐭 𝐑𝐞𝐧𝐝𝐞𝐫 𝐓𝐢𝐦𝐞 𝐛𝐲 𝟔𝟎% 🚀 Recently, I worked on a React dashboard application where the UI felt slow and unresponsive 😓 Pages were taking too long to update especially with large data sets So I decided to debug the issue 👇 🔍 Step 1 — Measured performance Used React DevTools Profiler Found multiple unnecessary re-renders ⚠️ Problem Every state change was re-rendering large components unnecessarily Fixes I applied 👇 ⚡ Used React.memo Prevented child components from re-rendering when props didn’t change 🧠 Applied useMemo Memoized expensive calculations to avoid recalculating on every render 🔁 Used useCallback Stopped functions from being recreated on every render 📦 Improved component structure Split large components into smaller ones Moved state closer to where it was needed 🔑 Fixed key usage in lists Replaced index keys with unique IDs 🚀 Result ✔ ~60% reduction in render time ✔ Smooth UI interactions ✔ Better user experience Key learning 💡 Performance issues are often not obvious They hide in unnecessary re-renders Tip for developers ⚠️ Don’t optimize blindly Measure → Identify → Fix Good developers make things work. Great developers make them fast. #ReactJS #FrontendDeveloper #WebDevelopment #JavaScript #Performance #ReactOptimization #SoftwareDeveloper #CodingInterview

🚀 Day 7 / 21 — Frontend Challenge Today I built: 👉 Premium To-Do App (with Local Storage & Task Management) 🧠 Flow I designed before coding: • Step 1: Identified core UI elements (input field, add button, task list, checkbox, edit & delete actions) and planned a modern UI layout • Step 2: Created a tasks array to store all task objects with properties (text, completed) • Step 3: Integrated localStorage to persist tasks even after page reload • Step 4: Designed saveTasks() function to store updated tasks in localStorage • Step 5: Built renderTasks() function to dynamically display all tasks from array • Step 6: Implemented add task logic with validation and pushed new task into array • Step 7: Added checkbox functionality to toggle task completion status • Step 8: Implemented edit feature using prompt to update task text • Step 9: Added delete functionality to remove tasks from array • Step 10: Re-rendered UI after every action (add, edit, delete, toggle) to keep UI in sync with data • Step 11: Enabled Enter key support for faster task addition • Step 12: Loaded saved tasks automatically on page load using renderTasks() 🛠 Tech Used: HTML | CSS | JavaScript | LocalStorage ✨ Features: • ➕ Add new tasks • ✅ Mark tasks as completed (checkbox) • ✏️ Edit existing tasks • 🗑️ Delete tasks • 💾 Data stored in localStorage (persistent) • ⚡ Real-time UI updates • ⌨️ Add tasks using Enter key • 🎯 Clean & modern UI 🚧 Challenges Faced: Managing synchronization between UI and data (tasks array) was a key challenge. Ensuring localStorage updates correctly after every action required careful handling. Implementing edit functionality while maintaining clean data flow also needed attention. 💡 Key Learning: Learned how to manage application state using arrays and keep UI in sync using re-rendering. Understanding localStorage is essential for building real-world applications that retain user data. 🙏 Guidance by: Keyur Gohil 🏫 Learning at: Red & White Skill Education Official 📂 GitHub Repo: https://lnkd.in/ddgreMdS #21DaysJSWithKeyur #JavaScript #FrontendDevelopment #BuildInPublic #WebDevelopment #UIComponents

𝗧𝗼𝗽 𝗥𝗲𝗮𝗰𝘁𝗝𝗦 𝗖𝗼𝗿𝗲 𝗖𝗼𝗻𝗰𝗲𝗽𝘁𝘀 𝗘𝘃𝗲𝗿𝘆 𝗙𝗿𝗼𝗻𝘁𝗲𝗻𝗱 𝗘𝗻𝗴𝗶𝗻𝗲𝗲𝗿 𝗦𝗵𝗼𝘂𝗹𝗱 𝗞𝗻𝗼𝘄 React is one of the most powerful libraries for building modern user interfaces. Understanding its core concepts is essential to building scalable, maintainable, and high-performance applications. Here are the most important React fundamentals every developer should master. 𝗖𝗼𝗺𝗽𝗼𝗻𝗲𝗻𝘁𝘀 Components are the building blocks of a React application. Each component is reusable, independent, and responsible for a part of the UI. 𝗝𝗦𝗫 JSX allows you to write HTML-like syntax inside JavaScript. It makes UI code more readable and easier to maintain. 𝗣𝗿𝗼𝗽𝘀 Props are used to pass data from parent to child components. They are immutable and help maintain a predictable data flow. 𝗦𝘁𝗮𝘁𝗲 State is used to manage dynamic data within a component. When state updates, React automatically re-renders the UI. 𝗛𝗼𝗼𝗸𝘀 Hooks allow functional components to use state and lifecycle features. Common hooks include useState, useEffect, and useContext. 𝗩𝗶𝗿𝘁𝘂𝗮𝗹 𝗗𝗢𝗠 Virtual DOM is a lightweight copy of the real DOM. React updates only the changed elements, improving performance. 𝗖𝗼𝗻𝗱𝗶𝘁𝗶𝗼𝗻𝗮𝗹 𝗥𝗲𝗻𝗱𝗲𝗿𝗶𝗻𝗴 React allows rendering UI based on conditions, making applications dynamic and interactive. 𝗘𝘃𝗲𝗻𝘁 𝗛𝗮𝗻𝗱𝗹𝗶𝗻𝗴 React handles user interactions like clicks and inputs using synthetic events, ensuring cross-browser compatibility. 𝗨𝗻𝗶𝗱𝗶𝗿𝗲𝗰𝘁𝗶𝗼𝗻𝗮𝗹 𝗗𝗮𝘁𝗮 𝗙𝗹𝗼𝘄 Data flows in one direction (parent to child), making applications easier to debug and maintain. 𝗦𝗶𝗺𝗽𝗹𝗲 𝗧𝗮𝗸𝗲𝗮𝘄𝗮𝘆 Strong React applications are built by combining reusable components, efficient state management, and optimized rendering techniques. Mastering these fundamentals is the key to building scalable frontend systems. #ReactJS #FrontendDevelopment #JavaScript #WebDevelopment #SoftwareEngineering #UIEngineering #ReactHooks #VirtualDOM #Coding #LearningEveryday

𝐇𝐨𝐰 𝐈 𝐑𝐞𝐝𝐮𝐜𝐞𝐝 𝐑𝐞𝐚𝐜𝐭 𝐑𝐞𝐧𝐝𝐞𝐫 𝐓𝐢𝐦𝐞 𝐛𝐲 𝟔𝟎% 🚀 Recently, I worked on a React application where the UI felt slow and unresponsive 😓 Pages were taking too long to update especially with large data sets So I decided to debug the issue 👇 🔍 Step 1 — Measured performance Used React DevTools Profiler Found multiple unnecessary re-renders ⚠️ Problem Every state change was re-rendering large components unnecessarily Fixes I applied 👇 ⚡ Used React.memo Prevented child components from re-rendering when props didn’t change 🧠 Applied useMemo Memoized expensive calculations to avoid recalculating on every render 🔁 Used useCallback Stopped functions from being recreated on every render 📦 Improved component structure Split large components into smaller ones Moved state closer to where it was needed 🔑 Fixed key usage in lists Replaced index keys with unique IDs 🚀 Result ✔ ~60% reduction in render time ✔ Smooth UI interactions ✔ Better user experience Key learning 💡 Performance issues are often not obvious They hide in unnecessary re-renders Tip for developers ⚠️ Don’t optimize blindly Measure → Identify → Fix Good developers make things work. Great developers make them fast. #ReactJS #FrontendDeveloper #WebDevelopment #JavaScript #Performance #ReactOptimization #SoftwareDeveloper #CodingInterview

🚀 JavaScript Project 3: Counter System Built a stste-driven counter with increment, decrement and reset actions —but this time, I focused on how engineers think, not just making it work. 🔑 Key ideas: • State is the single source of truth • UI updates are centralized ( updateUI ) • Event delegation for scalable interaction • Data-driven actions using data-* attributes • Clear UI feedback (disabled states, interaction response) 💡Biggest insight: Don't manipulate the UI directly — update state, then let the UI reflect it. 🔗 Live: https://lnkd.in/dTNy6A2M 💻 Code: https://lnkd.in/dp638D6h This is part of my journey building JavaScript systems step-by-step. More coming. #JavaScript #Frontend #WebDevelopment #LearningInPublic

🚀 Frontend Performance — Learning in Public Over the last couple of days, I explored Lighthouse-based performance analysis on a real application. Key learnings 👇 🧠 Main Thread Matters 👉 Browser runs on a single thread 👉 Heavy JS → slower interaction 🚦 Render-Blocking Resources 👉 CSS/JS can delay UI rendering ⛓️ Critical Request Chain 👉 Too many dependencies → slower loading 📊 Lighthouse Insight 👉 It’s not about score 👉 It’s about identifying root causes 🎯 Big takeaway: Performance = reduce work + remove blockers 📌 Next: Building a real-world performance audit report #Frontend #WebPerformance #JavaScript #ReactJS #SoftwareEngineering #LearnInPublic

🔥 React DevTools: Common Issues & How to Use It Effectively React DevTools is one of the most powerful tools for diagnosing performance issues… but many developers don’t use it correctly. Here’s what I’ve learned 👇 ------------------------------------- 🔍 Common Issues Developers Face: 1️⃣ Not Profiling – Many just inspect components without measuring re-renders or performance. 2️⃣ Ignoring Component Trees – Deep trees hide unnecessary renders. 3️⃣ Overlooking State & Props – Changes in parent state can trigger unexpected child re-renders. 4️⃣ Misreading Flame Charts – Not understanding which operations are expensive. 💡 How to Use React DevTools Effectively: ------------------------------------------------- ✅ Profiler Tab – Measure every render and find bottlenecks. ✅ Highlight Updates – See exactly which components re-render. ✅ Inspect Component Props & State – Check if changes are causing unnecessary renders. ✅ Compare Commits – Analyze how updates affect your tree. ✅ Filter and Focus – Only measure the components that matter. 🚀 Pro Tip: “React DevTools doesn’t just show problems… it tells you exactly where to optimize.” 💬 Your Turn: Which feature of React DevTools helped you most in improving performance? #reactjs #reactdeveloper #webdevelopment #frontend #javascript #reactperformance #profiling #devtools #softwareengineering #frontendengineering #performanceoptimization #cleancode #techlead