React useEffect dependency pitfalls and debugging

🧠 Day 24 — Optional Chaining (?.) & Nullish Coalescing (??) Tired of errors like “Cannot read property of undefined”? 🤔 These two operators will save you 🚀 --- ⚡ 1. Optional Chaining ?. 👉 Safely access nested properties const user = { profile: { name: "John" } }; console.log(user.profile?.name); // John console.log(user.address?.city); // undefined (no error) 👉 Stops execution if value is null or undefined --- ⚡ 2. Nullish Coalescing ?? 👉 Provides a default value only if value is null or undefined const name = null; console.log(name ?? "Guest"); // Guest --- ⚠️ Difference from || console.log(0 || "Default"); // "Default" ❌ console.log(0 ?? "Default"); // 0 ✅ 👉 || treats falsy values (0, "", false) as false 👉 ?? only checks null or undefined --- 🚀 Why it matters ✔ Prevents runtime errors ✔ Cleaner and safer code ✔ Widely used in APIs & React apps --- 💡 One-line takeaway: 👉 “Use ?. to safely access, ?? to safely default.” --- Once you start using these, your code becomes much more robust. #JavaScript #ES6 #OptionalChaining #WebDevelopment #Frontend #100DaysOfCode 🚀

🧠 The bug wasn’t in my code… It was in my assumption. I spent 2 hours debugging a UI issue where a list wasn’t updating correctly. The logic looked fine. The API response was correct. State was updating. So what was wrong? 👇 👉 I was using the array index as the key in a dynamic list. At first, everything worked. But the moment I added/removes items… things broke in weird ways. 💥 Items re-rendered incorrectly 💥 State got mixed up between components 💥 UI started behaving unpredictably 💡 Lesson learned: Keys in React are not just for removing warnings. They are how React tracks identity. Using index as a key = telling React: "Yeah, these items might change… but pretend they didn’t." 🛠️ Better approach: Always use a unique and stable id from your data. 🧠 Simple way to think: React uses keys like names in a classroom. If everyone has the same name (or changing names), things get chaotic. 🔥 Takeaways: • Avoid index as key (especially in dynamic lists) • Stable identity = predictable UI • Many “random bugs” come from small decisions like this 💬 Have you ever faced a weird UI bug that turned out to be something small? #ReactJS #FrontendDevelopment #JavaScript #WebDev #CodingMistakes

Day 8 — Today my frontend talked to the outside world for the first time. Fetched real data from a public API. Rendered it on screen. It's genuinely exciting every time. async/await cleaned up my fetch code significantly compared to chaining .then() everywhere. But I also finally understood why promises exist — it's not just about syntax. The part most tutorials skip: error handling. What happens when the API is down? What does your UI show? I spent extra time making sure loading and error states were actually handled, not just happy path. Also tried Axios for the first time. The automatic JSON parsing and nicer error messages are worth it for bigger projects. Built a small app that shows GitHub user info by username. Feels like a real tool now. How do you handle API errors in your projects? #javascript #webdev #reactjs #frontenddeveloper

🧠 React state is NOT a variable 🔍 The problem Most devs assume state updates instantly. That’s why you see: • Old values in logs • Confusing behavior in event handlers • setState not working as expected 💡 The shift State is not a variable It’s a snapshot per render 🧠 Mental model Think of React like a camera 📸 Each render = a photo • Fixed state • Fixed event handlers Once captured → it never changes ⚙️ What’s actually happening • setState → requests a new render • React stores state outside your component • Each render gets its own snapshot • Old handlers use old snapshots ⚠️ Common bug setCount(count + 1) setCount(count + 1) 👉 Both use the same snapshot ✅ Correct approach setCount(prev => prev + 1) 🚀 Practical takeaway If next state depends on previous state → use functional updates That single rule removes most “state bugs” in React #React #JavaScript #Frontend #WebDevelopment #LearnInPublic

I shipped a React dashboard with 40+ memoized components. The profiler was embarrassing. Here's what I found. Every component was wrapped in React.memo. Every callback was in useCallback. Every derived value was in useMemo. I thought I was being a good engineer. 𝗧𝗵𝗲 𝗽𝗿𝗼𝗳𝗶𝗹𝗲𝗿 𝘁𝗼𝗹𝗱 𝗮 𝗱𝗶𝗳𝗳𝗲𝗿𝗲𝗻𝘁 𝘀𝘁𝗼𝗿𝘆: → 200+ unnecessary renders per interaction → Memory allocation spiking on every keystroke → Frames dropping below 60fps during filter operations The irony? The memoization itself was causing the slowdown. Unstable object references being passed as deps. useCallback wrapping functions that didn't need stability. React.memo on components that rendered in 0.1ms anyway. Every "optimization" was a small tax. 40 components. Multiplied. I spent a day removing memo. Performance improved immediately. The lesson I took away: 𝗢𝗽𝘁𝗶𝗺𝗶𝘇𝗮𝘁𝗶𝗼𝗻 𝘄𝗶𝘁𝗵𝗼𝘂𝘁 𝗽𝗿𝗼𝗳𝗶𝗹𝗶𝗻𝗴 𝗶𝘀 𝗴𝘂𝗲𝘀𝘀𝗶𝗻𝗴. 𝗔𝗻𝗱 𝗰𝗼𝗻𝗳𝗶𝗱𝗲𝗻𝘁 𝗴𝘂𝗲𝘀𝘀𝗶𝗻𝗴 𝗶𝘀 𝘁𝗵𝗲 𝗺𝗼𝘀𝘁 𝗱𝗮𝗻𝗴𝗲𝗿𝗼𝘂𝘀 𝗸𝗶𝗻𝗱. Profile first. Memoize second. Only what the profiler tells you to. What React "best practice" did you have to unlearn? #React #Frontend #JavaScript #WebPerformance #SoftwareEngineering

you upgraded to React 20. suddenly your code breaks. defaultProps is gone. string refs throw errors. you're migrating code from 2018. welcome to the cleanup. why it breaks: React 20 removes patterns deprecated since React 16. defaultProps on function components, string refs (ref="myRef"), legacy context API — all gone. if your code still uses these, React 20 errors immediately. run npx @react-codemod/cli react-20 to auto-migrate. #reactjs #typescript #webdevelopment #buildinpublic #react20

Three useEffects, all anonymous. A production bug. Spent 40 minutes fixing what should have taken 5. Not again. useEffect(() => { ... }) will tell you nothing when it breaks. No stack trace, no clues in react devtools. Just anonymous in the profiler 15 times. This is what happened to us. Three effects in a single component - all of them anonymous. The error referred to the component, but didn’t specify the effect. Three senior engineers manually debugging the issue, staring at the same file. The tool wasn’t the solution, the tool was a naming convention: useEffect(function syncCartWithLocalStorage() { ... }) One small change. Then I set a rule for the team: → Every useEffect should be a named function. → The name should describe what the effect does, not when. → syncCart, fetchUserProfile, subscribeToSocket are preferred over onMount or handleChange. The results after 2 months were: - 30% reduction in time spent debugging. - Stack traces were self documenting. - New developers were onboarded quickly - effects read like a table of contents. - Code reviews were shorter. The name alone explained what was expected. Debuggability is not a feature you add later, it’s a habit you embed in every line. What’s your small syntax habit that saved you hours of debugging? #ReactJS #FrontendEngineering #WebDevelopment #CodeQuality #DeveloperProductivity

I keep running into the same issue when building forms with React Hook Form + MUI. At the beginning everything feels clean. Then you start adding: - conditional fields - validation rules - async data …and suddenly: - Controller everywhere - watch() scattered across the component - manual error wiring - logic split between JSX and form config It works, but it doesn’t feel right anymore. After working on several enterprise projects, I noticed this pattern keeps repeating. Forms are simple… until they aren’t. Curious how others are dealing with this. Do you keep scaling with RHF + MUI as-is, or do you introduce some abstraction at some point? #reactjs #frontend

Nobody told me this when I started React. I learned props. I learned the state. I thought I understood both. I didn't. I was putting everything in state. User data. Config values. Things passed in from the parent. Didn't matter — if I needed it inside a component, it went into useState. It worked. Until it didn't. On a client project, I had a component receiving a userId from its parent. I was also storing that userId in local state. Then the parent updated. My local state didn't. Two different values. One component. Complete mess. The bug took me hours to find. The fix was deleting four lines of code. Here's what nobody told me: Props and state are not two ways to store data. They are two completely different things with two completely different jobs. Props are data that comes from outside. The parent owns it. The parent controls it. Your component just receives it and uses it. You don't store it. You don't copy it. You use it directly. State is data that lives inside. Your component owns it. Your component controls it. When it changes, the component re-renders. Nothing outside knows it exists unless you explicitly pass it down. One simple test I use now: Does this component own this data — or is it just receiving it from somewhere else? If it owns it → state. If it's receiving it → props. Use it directly. Never copy it into state. That one question has saved me from every props-vs-state bug I've ever faced. The bug I had on that client project? I was copying props into the state. The parent updated the prop. My state copy didn't follow. UI showed stale data. Classic mistake. Extremely common. Nobody warns you about it early enough. #React #JavaScript #Frontend #ReactJS #WebDevelopment #Programming #100DaysOfCode #SoftwareDevelopment

most developers don't know about the optional chaining operator gotcha. they use it everywhere. it silently hides bugs. the problem: optional chaining (?.) returns undefined if property doesn't exist. you think it's safe. bugs slip through. why it breaks: when you use optional chaining, you're not validating — you're hiding. undefined gets passed around. downstream code breaks. you spend 2 hours debugging something that should have failed immediately. the real issue: optional chaining makes bad data look safe. it lets undefined flow through your app like it's normal. the solution: validate early. fail loud. don't let undefined silently propagate. when to use optional chaining: - reading optional properties - not for safety - for convenience only when NOT to use it: - critical data paths - anything you depend on - anything that should always exist one rule: optional chaining is a convenience. validation is safety. use both. #reactjs #typescript #webdevelopment #buildinpublic #javascript