Fixing React Performance Issues with Referential Equality

Why Lifting State Up is Important in React? In React, one of the most powerful concepts you’ll come across is "Lifting State Up". It might sound complex at first, but once you get it, your component design improves instantly. 1️⃣What is Lifting State Up? Lifting state up means moving state from a child component to its closest common parent so that multiple components can share and stay in sync with the same data. 2️⃣ Why is it Important? 1️⃣ Single Source of Truth When state is managed in one place, your data stays consistent across components. No more bugs caused by mismatched states. 2️⃣ Better Data Flow React follows a unidirectional data flow (parent ➝ child). Lifting state up helps you stay aligned with React’s core philosophy. 3️⃣ Easier State Management Instead of managing multiple states in different components, you centralize it, making your app easier to debug and maintain. 4️⃣ Component Communication Made Easy Sibling components can’t talk directly. But if you lift the state to a parent, they can communicate via props. 3️⃣Simple Example Imagine two components: -SearchBar -ResultsList Both need access to the same search query. 🔍Instead of keeping state inside SearchBar, lift it up to the parent: -Parent holds query -Pass query & setQuery to SearchBar -Pass query to ResultsList -Now both components stay perfectly in sync. 4️⃣When NOT to Lift State When the state is only used in one component When lifting makes your component tree unnecessarily complex Rule of thumb: Lift state only as much as needed, not more. Final Thoughts Mastering this concept will make you a better React developer. It’s not just about writing code, it’s about designing clean, scalable systems. What do you think? Have you faced issues that were solved by lifting state up? Let’s discuss #React #Frontend #WebDevelopment #JavaScript #ReactJS #Coding

Using index as a key is dangerous Every React developer has written this at least once. items.map((item, index) => (  <li key={index}>{item}</li> )) Looks fine. Works fine. But it isn't This is Post 5 of the series: 𝗥𝗲𝗮𝗰𝘁 𝗨𝗻𝗱𝗲𝗿 𝘁𝗵𝗲 𝗛𝗼𝗼𝗱 Where I explain what React is actually doing behind the scenes. Here's what actually happens when you use index as key: You delete one item from a list. React doesn't know which item was removed. It just looks at positions. So it re-renders everything from that index downward. Input states get mismatched. Animations break. Bugs appear that you can't even reproduce consistently. And... No error. Just... wrong behavior. 🔑 Here's what React actually needs: A key isn't just something unique. It needs to be stable, unique, AND tied to the data — not the position. ❌ key={index} → breaks on delete, sort, filter  ❌ key={Math.random()} → new key every render = React destroys and recreates the node  ✅ key={item.id} → stable, reliable, React knows exactly who is who The rule is simple: If your list can ever be reordered, filtered, or deleted from... index as key will silently break your UI. Use your data's ID.  If it doesn't have one, generate it at creation — not during render. const newItem = { id: crypto.randomUUID(),   name: "New Task" } One tiny prop.  Massive impact on how React tracks your entire list. In Post 6 of React Under the Hood: What Happens When You Call setState Follow Farhaan Shaikh if you want to understand react more deeply. 👉 Read the previous post - Understanding diffing algorithm: https://lnkd.in/dzW3NP_V #SoftwareEngineering #ReactJS #WebDevelopment #JavaScript #FrontendDevelopment #BuildInPublic #LearnInPublic #ReactUnderTheHood

I stopped writing messy React code… and my projects became 10x easier to maintain. Here’s what changed 👇 Most developers focus on “making it work.” But clean code is what makes it scalable. One simple habit I adopted: 👉 Extract logic into reusable hooks Instead of this 👇 useEffect(() => { fetch("/api/users") .then(res => res.json()) .then(data => setUsers(data)) .catch(err => console.error(err)); }, []); I now do this 👇 // useFetch.js import { useState, useEffect } from "react"; export function useFetch(url) { const [data, setData] = useState(null); useEffect(() => { fetch(url) .then(res => res.json()) .then(setData) .catch(console.error); }, [url]); return data; } Then use it anywhere 👇 const users = useFetch("/api/users"); 💡 Why this matters: Cleaner components Reusable logic Easier debugging Better scalability Small improvements like this separate average developers from great ones. What’s one coding habit that improved your workflow? #React #JavaScript #CleanCode #WebDevelopment #Frontend

Most developers treat components like functions. Just input, output, done. But that thinking leads to a mess fast. What I was doing wrong: ❌ Putting everything in one giant component ❌ Fetching data directly inside UI components ❌ Ignoring the rules of hooks until bugs appeared ❌ Re-rendering everything because state lived in the wrong place What actually works: ✅ Separating concerns — UI, logic, and data each have a home ✅ Custom hooks to keep components clean and readable ✅ Lifting state only as high as it needs to go ✅ Memoization where it counts, not everywhere The real shift wasn't learning a new library or pattern. It was understanding that React rewards you for thinking about data flow before you write a single line of JSX. Your component tree is a reflection of how well you understand your data. Once I internalized that, debugging got easier, reviews got faster, and onboarding new teammates stopped being painful. React isn't hard. But writing React that other people can maintain? That takes intentional practice. Still learning. Still improving 🚀 #React #Frontend #WebDevelopment #JavaScript #SoftwareEngineering #ReactJS #CodeQuality

🤔 Wait… shouldn’t variables be deleted? How is it possible that a function still remembers a variable…even after the function where it was created has already finished executing? 😳 👉 Sounds impossible, right? 🚀 JavaScript’s one of the most powerful concepts: Closures 🧠 What is a Closure? A closure is created when a function is defined inside another function, and the inner function can access variables from its parent scope — even after the parent function has finished execution. ⚡Shouldn’t variables be deleted? Normally, yes ✅ 👉 Once a function finishes, its local variables are removed from memory (thanks to garbage collection) But closures change the game 👇 👉 If an inner function is still using those variables, JavaScript keeps them alive in memory 🔍 What’s really happening? The inner function “closes over” its parent’s variables 💡 That’s why it’s called a closure Even though the outer function is done… the inner function still has access to its scope 😮 🔐 Why Closures Matter (Real Use Cases) Closures aren’t just theory — they’re used everywhere: 👉 Encapsulation (Private Variables) Keep data hidden from global scope 👉 Debouncing & Throttling Control function execution (very common in React apps) 👉 State management patterns Maintain data across function calls 💡 Real Developer Insight Closures are powerful… but can be tricky 👉They can also hold memory longer than expected 👉 Misuse can lead to memory leaks 🚀 Final Thought: Most developers use closures unknowingly… But great developers understand how and why they work. #JavaScript #FrontendDevelopment #WebDevelopment #Closures #CodingTips #LearnJavaScript #BuildInPublic #100DaysOfCode #LearnInPublic

🚨 Using advanced tools for simple problems is not good engineering. AI can speed things up — but it can also turn simple solutions into complex ones. 👉 As developers, we should always ask: Is this approach really needed? Or is it more complicated than necessary? 💡 Example: Form handling in React A simple login form: Email Password Does this need a form library? 👉 No. ✅ Keep it simple const [email, setEmail] = useState(""); const [password, setPassword] = useState(""); Easy to read Easy to maintain Gets the job done 🚀 When to use a library (like React Hook Form) Use it when you have: Multiple fields Complex validations Dynamic forms Performance constraints ⚖️ The difference is not the tool. It’s the use case. ⚠️ Overengineering doesn’t improve code. 👉 It adds unnecessary complexity. 💬 Question: Have you ever used a heavy solution for a simple problem? ✉️ Repost if this helped you decide #reactjs #javascript #frontend #webdevelopment #softwareengineering #coding #developers #cleancode #architecture

When Your API Works… But Your UI Doesn’t Update (React Query Lesson) Today I built a “create-product” to Add products, feature in my Next.js project. I used: - useQuery to fetch products - useMutation to create a new product - router navigation after submission The product was created successfully, but I noticed an issue the UI didn’t update immediately after the mutation. I’m currently digging into how query invalidation and cache updates work in React Query to fix this. Even though it’s not fully resolved yet, it’s teaching me something important: frontend development isn’t just about making things work lit’s about keeping data in sync across the UI. Still learning. Still building. For developers……When debugging issues like this, do you prefer focusing on state management first or network/data flow first? Why? Seeing my posts for the first time? I am Irorere Juliet frontend developer and a builder. I believe in growth, consistency, and showing up even when it’s hard. #Nextjs #ReactQuery #JavaScript #WebDevelopment #FrontendDevelopment #BuildInPublic

🔎 I audited 10 production React apps — here's what I found Over the past year I've had the chance to review codebases across startups and mid-size teams. Different industries. Different team sizes. Different tech stacks. But the same mistakes kept showing up. Over and over again. 👇 💀 1. useEffect used for everything Fetching data? useEffect. Syncing state? useEffect. Transforming data for render? useEffect. Most of these didn't need useEffect at all. → Data fetching belongs in React Query, SWR, or Server Components → Derived state belongs in useMemo or just inline calculation → If you're fighting your useEffect, you're probably using it wrong 🧱 2. Massive components that do everything 500-line components mixing data fetching, business logic, and UI in one place. Hard to test. Hard to reuse. Hard to read. → Split by responsibility — one component, one job → Extract custom hooks for logic → Keep your JSX clean and declarative 🔁 3. No memoization strategy — or too much of it Half the apps had zero memoization on expensive renders. The other half had useMemo and useCallback wrapped around everything — including things that cost nothing to recompute. Both are wrong. → Measure first with React DevTools Profiler → Memoize only what actually causes pain 🌊 4. Prop drilling 5+ levels deep No Context. No state manager. Just props passed through components that don't need them. → Reach for Context API for genuinely global state → Consider Zustand or Jotai for more complex cases → Or restructure — sometimes composition solves it without any library 🔓 5. Zero error boundaries One unhandled JS error crashes the entire app. Not a single one of the 10 apps had error boundaries in the right places. → Wrap critical sections independently → Show graceful fallback UIs → Log errors to Sentry or similar — don't fly blind in production The uncomfortable truth? These aren't junior mistakes. I saw them in codebases written by experienced developers under deadline pressure. Good architecture is a habit, not a talent. It comes from deliberate review, team standards, and making space to refactor. Which of these have you seen most often? 👇 #react #frontend #webdevelopment #javascript #sofwareengineering #codequality #programming

🚀 Memoization in React — When useMemo & useCallback Actually Matter Most developers learn useMemo and useCallback… 👉 But very few understand when to use them correctly And that’s where performance is won (or lost). 💡 What is Memoization? Memoization is an optimization technique: 👉 Cache the result → Avoid recomputation In React, it helps prevent: Expensive calculations Unnecessary re-renders Function re-creations ⚙️ The Real Problem Every render in React: ❌ Recreates functions ❌ Recomputes values ❌ Triggers child re-renders 👉 Even if nothing actually changed 🔥 Where useMemo Helps const filteredData = useMemo(() => { return data.filter(item => item.active); }, [data]); ✅ Avoids expensive recalculations ❌ But useless for cheap operations 🔥 Where useCallback Helps const handleClick = useCallback(() => { console.log("Clicked"); }, []); 👉 Useful only when: Passing to child components Used with React.memo 🧠 The Real Optimization Rule 👉 Memoization only matters when: ✔ Expensive computation exists ✔ Reference equality affects rendering ✔ Component re-renders are costly ⚠️ Biggest Mistake Developers Make // ❌ Over-optimization const value = useMemo(() => count + 1, [count]); 👉 You added complexity without benefit 🔥 When NOT to use Memoization ❌ Simple calculations ❌ Small components ❌ No performance issue 👉 Premature optimization = bad code 💬 Pro Insight (Senior-Level Thinking) React is already optimized. 👉 Your job is NOT to optimize everything 👉 Your job is to optimize bottlenecks only 📌 Save this post & follow for more deep frontend insights! 📅 Day 16/100 #ReactJS #FrontendDevelopment #JavaScript #PerformanceOptimization #ReactHooks #SoftwareEngineering #100DaysOfCode 🚀

Today, I had a conversation with a friend 3+ years in React who hit a frustrating error: ❌ "React is not defined" His response? "But I'm not even using React. I only wrote JSX." That's when I realised — even experienced developers can have gaps in understanding what happens under the hood. And honestly, in the AI era, these fundamentals matter more than ever. 🔍 So what actually happens when you write JSX? You write this: <div className="hello">Hello World</div> Babel (your build tool) transforms it into: React.createElement("div", { className: "hello" }, "Hello World") That's it. JSX is NOT HTML. It's syntactic sugar that compiles down to React.createElement() calls. And since React.createElement is called behind the scenes — React must be in scope. That's why the old error appeared. (Note: React 17+ introduced a new JSX transform that auto-imports the runtime, so you may not see this anymore — but understanding WHY it existed is gold.) 🏗 The React Build Process (simplified) Your JSX code → Babel transpiles JSX → React.createElement() calls → React builds a Virtual DOM (a JS object tree) → React diffs the new tree vs the old one → Only the changed parts get updated in the real DOM This is why React is fast. Not because it touches the DOM often — but because it's surgical about when and what it touches. --- 💡 Why does this still matter in the AI era? AI tools write your components. AI tools fix your errors. But AI cannot debug what you don't understand. When something breaks at build time, at runtime, or in production — you need to know: → What is Babel doing to my code? → Why is the virtual DOM behaving this way? → What triggered a re-render? Basics are not boring. Basics are your debugging superpower. Don't let AI become a crutch that skips your foundation. Let it be the tool that sits on top of a strong one. 🧱 #ReactJS #JavaScript #WebDevelopment #JSX #FrontendDevelopment #Programming #SoftwareEngineering #100DaysOfCode #TechLearning #BuildInPublic