React Strict Mode: Intentional Double Rendering in Dev

I made React slower trying to optimize it. Wrapped everything in useMemo. Added useCallback everywhere. Felt productive. Performance got worse. Here's what I didn't understand about re-renders 👇 4 things that trigger a re-render: > State change > Prop change > Parent re-renders (even if YOUR props didn't change) > Context update That third one is responsible of unnecessary re-renders I've seen in real codebases. The fix isn't memorizing APIs. It's this order: 1. Profile first Open React DevTools Profiler. Find the actual problem. Takes 2 minutes. 2. Wrap the right components in React.memo Not all of them. Only components that are expensive AND receive stable props. 3. Stabilise your functions with useCallback Without it - new function reference every render --> child always re-renders. Doesn't matter if you have React.memo. 4. useMemo for heavy calculations only Not for "this array map looks expensive." Only when Profiler proves it. The rule I follow now: Don't optimise what you haven't measured. One change in the right place beats 10 changes in the wrong ones. What's the most unnecessary useMemo you've ever written? 😄 #React #JavaScript #Frontend #WebDev

🚨 𝗥𝗲𝗮𝗰𝘁 𝗥𝗲𝗻𝗱𝗲𝗿𝗶𝗻𝗴 𝗧𝘄𝗶𝗰𝗲? 𝗜𝘁’𝘀 𝗡𝗼𝘁 𝗮 𝗕𝘂𝗴 — 𝗜𝘁’𝘀 𝗮 𝗙𝗲𝗮𝘁𝘂𝗿𝗲 You start your app in development mode… And suddenly notice: 👉 Components rendering twice 👉 API calls firing twice It feels like something is broken 😅 But actually… everything is working exactly as intended. --- 💡 In development, React’s Strict Mode deliberately runs certain lifecycle methods twice. Why does it do that? 👉 To expose hidden issues in your code early --- Here’s what React is testing for: • Side effects happening during render • Missing cleanup logic in useEffect • Code that isn’t safe to run multiple times For instance: If your useEffect directly triggers an API call without safeguards… 👉 You’ll immediately see duplicate requests And that’s React pointing out a potential problem. --- ⚠️ Key thing to remember: 👉 This behavior only happens in development 👉 In production, everything runs just once --- 🚀 The mindset shift: Don’t try to stop the double execution. 👉 Instead, write code that behaves correctly even if it runs multiple times Because in real-world applications: 👉 Reliable code matters more than code that “just works once” --- So next time your component renders twice… Relax 😄 React is helping you build stronger, more predictable applications. Have you run into this before? 👇 #ReactJS #Frontend #JavaScript #WebDev #SoftwareEngineering #Debugging #CleanCode

🚀 Starting a 10-part series on React things that make code harder than it needs to be. Not tutorials. Not “10 hooks you should know.” Just real patterns that show up in actual codebases and make simple work more annoying than it should be. Part 1: A lot of React problems are really state problems. Not React itself. Not JSX. Not even hooks most of the time. State living in too many places. Duplicated state. State doing jobs it was never supposed to do. That’s usually when an app starts feeling harder to reason about than it should. The more I work with React, the more I think good frontend code starts with good state decisions. If the state is messy, everything downstream gets harder: debugging feature work testing handoffs even basic collaboration Good React usually feels predictable. And predictable usually starts with state. What’s the most common state mistake you keep seeing? #React #ReactJS #StateManagement #FrontendEngineering #JavaScript #TypeScript #SoftwareEngineering

Stop disabling the exhaustive-deps linter in your React Effects ⚛️. we all did the same dirty hack: // eslint-disable-next-line 👇. It is the most common frustrating scenario in React development: You write a useEffect to connect to a websocket or track an analytics event. Inside that effect, you need to read the current value of a state variable—like a shopping cart count or a UI theme. But the moment you read that state, the React linter screams at you to add it to the dependency array. If you add it, your effect re-runs every time the state changes (destroying your websocket connection!). If you don't add it, your build fails. So, we all did the same dirty hack: // eslint-disable-next-line. React finally solves this permanently with useEffectEvent. ❌ The Legacy Way (eslint-disable): Forces you to break the rules of React. Creates a massive risk for stale closures and hidden bugs. Makes your code harder to maintain and review. ✅ The Modern Way (useEffectEvent): Extracts your "event" logic cleanly out of your "lifecycle" logic! • Always Fresh: It guarantees your callback will always read the absolute latest props and state. • Non-Reactive: It is intentionally ignored by the dependency array. It will never cause your useEffect to re-run. • Clean Code: You can finally turn your linter rules back on and trust your dependencies again. The Shift: We are moving away from fighting the framework and using dedicated primitives to separate reactive synchronization from non-reactive events. #ReactJS #React19 #WebDevelopment #Frontend #JavaScript #CleanCode #SoftwareEngineering #TechTips #WebDev #WebPerf #Tips #DevTips #ReactTips #FrontendDeveloper #DeveloperTips

⚛️ React Tip: When Should You Use useCallback? While working on React applications, one common performance issue developers face is unnecessary component re-renders. One hook that often comes up in this discussion is useCallback. But many developers (including me earlier) either overuse it or use it incorrectly. So here’s a simple way to understand it. 🔹 What does useCallback do? `useCallback` memoizes a function. This means React will reuse the same function instance unless its dependencies change. Example 👇 const handleClick = useCallback(() => { console.log("Button clicked"); }, []); Without `useCallback`, a new function is created every time the component re-renders. Most of the time this isn’t a problem. But it becomes important when passing functions to memoized child components. 🔹 Example scenario Imagine a parent component passing a function as a prop to a child component wrapped with `React.memo`. If the function reference changes on every render, the child component will also re-render unnecessarily. Using `useCallback` helps keep the function reference stable, preventing those extra renders. 🔹 When should you actually use it? ✅ When passing callbacks to memoized components ✅ When the function is a dependency in another hook ✅ When optimizing large component trees ⚠️ When NOT to use it: • For every function in your component • When there is no performance issue • Just because someone said it improves performance 💡 One important lesson I’ve learned: Optimization should be intentional, not automatic. React already does a lot of work under the hood. Use hooks like `useCallback` only when they actually solve a problem. Curious to hear from other developers 👇 Do you use `useCallback` often, or do you prefer optimizing only after profiling? #reactjs #frontenddevelopment #javascript #webdevelopment #reacthooks #softwareengineering #coding

Stop writing anonymous useEffect functions. Name them. This is one of the smallest changes you can make in React — and one of the most underrated. Most of us write this: useEffect(() => { fetchUser(id); }, [id]); But you can do this: useEffect(function fetchUserOnIdChange() { fetchUser(id); }, [id]); Same behavior. Completely different debugging experience. Here's why it matters: 🔍 Stack traces become readable When something goes wrong inside an effect, your browser's stack trace will show fetchUserOnIdChange instead of just useEffect. You'll know exactly which effect blew up — no more hunting through 8 anonymous functions. 🧠 Self-documenting code A named function is a contract. It tells the next developer (or future you at 11pm) why this effect exists, not just what it does. syncFormWithLocalStorage communicates more than any comment ever could. ⚡ React DevTools clarity The React profiler and DevTools display effect names. When you're profiling performance, named effects let you immediately identify what's running, when, and how often. 🤝 Easier code reviews Reviewers can scan for useEffect(function loadDashboardMetrics and instantly understand intent. No need to read the entire body just to grasp the purpose. The rule of thumb I follow: If an effect is longer than 3 lines or runs conditionally, it gets a name. No exceptions. It takes 2 seconds to type. It saves 20 minutes of debugging. Small habits compound. This is one worth picking up. 🚀 What's a small React habit that's made a big difference for your team? Drop it in the comments 👇 #React #JavaScript #WebDevelopment #FrontendEngineering #CleanCode #ReactJS #SoftwareEngineering

𝗠𝗼𝘀𝘁 𝗱𝗲𝘃𝗲𝗹𝗼𝗽𝗲𝗿𝘀 𝘁𝗵𝗶𝗻𝗸 𝗥𝗲𝗮𝗰𝘁 𝗶𝘀 “𝘄𝗮𝘀𝘁𝗶𝗻𝗴 𝗽𝗲𝗿𝗳𝗼𝗿𝗺𝗮𝗻𝗰𝗲” 𝘄𝗵𝗲𝗻 𝗲𝘃𝗲𝗿𝘆𝘁𝗵𝗶𝗻𝗴 𝗿𝗲-𝗿𝗲𝗻𝗱𝗲𝗿𝘀. It’s not. You’re just misunderstanding how it works. When state updates in a parent: The parent re-renders All children re-render (yes, even the ones not using that state) And people say: “Why doesn’t React just skip unnecessary re-renders by default?” Because that would break more things than it fixes. React would need to: Track exactly which component depends on which state Compare props deeply on every render Predict output without running the component That’s expensive. And sometimes more costly than just re-rendering. So React takes a different approach: Re-run everything (cheap JS work) Update only what actually changed (DOM optimization) That’s called reconciliation — and it works. If you want to skip re-renders: Use React.memo Keep props stable Optimize only where it actually matters Not every re-render is a problem. Unnecessary complexity is. Most performance issues in React don’t come from re-renders… They come from poor architecture and premature optimization. #ReactJS #FrontendDevelopment #WebDevelopment #JavaScript #SoftwareEngineering #ReactPerformance #CleanCode #FrontendArchitecture #ProgrammingTips #DevMindset #TechLeadership #CodingBestPractices #ReactMemo #PerformanceOptimization #LearnToCode

Ever clicked two dropdowns and both stayed open at the same time? 😾 Looks unprofessional. Feels broken. Users hate it. Here is how I fixed it in React with just 2 lines : 👉 When Explore opens → force "Degree" dropdown to close onClick={() => {  setIsExploreMenuOpen(!isExploreMenuOpen);  setIsDegreeMenuOpen(false); // ← this one line does it }} 👉 When Degree opens → force "Explore" dropdown to close onClick={() => {  setIsDegreeMenuOpen(!isDegreeMenuOpen);  setIsExploreMenuOpen(false); // ← same idea }} The logic is simple: When you open something → explicitly close everything else. React does not do this automatically. You have to tell it exactly what to close. Small detail. Big difference in user experience. #react #nextjs #javascript #webdevelopment #tailwindcss #buildinpublic #frontenddevelopment

I mean, it's pretty impressive to watch. #ClaudeCode (Sonnet) is writing me a little JavaScript app using idiomatic JS, nicely structured, using #TDD, or at least test-first. So I asked it: > You are describing this workflow as TDD, but do you actively refactor the code after getting the test to pass, so it is as simple as it can be? Or do you just go straight to writing the next failing test and move on? > Honestly — no, not explicitly. I've been doing Red → Green → next test, skipping the deliberate Refactor step. So I had a quiet word with CLAUDE.md. Still impressive though.

🔥 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