useEffect fires multiple times due to unstable dependencies

I built a Pomodoro timer into ACE and honestly it's been one of those features I didn't know I needed until I had it. The idea was simple. I was using ACE to study and kept switching tabs to find a timer. So I just built one in. 25 minutes. Focus. Break. Repeat. If you're building something, don't sleep on the small features. Sometimes the thing that makes your product actually usable isn't the AI or the fancy architecture. It's the 25 minute timer sitting quietly in the corner. #buildinpublic #nextjs #webdevelopment #javascript #frontenddevelopment

Real talk — useEffect almost broke my brain today. 😅 My React journey continues, and I came across one of the trickiest hooks so far. useEffect. At first I felt completely lost. The Codecademy lesson talked about cleanup functions, dependency arrays, side effects — and honestly? My head was spinning. But after stepping back and breaking it down in simpler terms, here's what finally made sense to me: useEffect lets you run code at SPECIFIC MOMENTS in your component's life. Three moments to remember: ```jsx // 1. Run AFTER EVERY render useEffect(() => { }); // 2. Run ONLY ONCE when the page loads useEffect(() => { }, []); // 3. Run WHEN a specific value changes useEffect(() => { }, [forecastType]); ``` The array at the end is called the dependency array — and it controls WHEN the code runs. The analogy that helped me? Think of it like a home security camera 📹 - No array — records 24/7 - Empty array — only records on day one - With a value — only records when that thing changes It's still not 100% clear to me yet — and that's okay. Some concepts take time to really click. 🙏 The lesson today wasn't just about useEffect though — it was about being honest with myself when something is hard, taking a break, and coming back to it instead of forcing it. Still learning, still building, still showing up every day. 💪 Is there a React concept that confused you when you first learned it? Drop it below 👇 #React #JavaScript #useEffect #Frontend #LearningInPublic #100DaysOfCode #SelfTaught

I thought useRef was only for accessing DOM… 😅 But I was wrong. 💡 For a long time, I used useRef like this: const inputRef = useRef(); 👉 Focus input, access DOM — that’s it. ⚠️ Then I faced a problem: I needed to store a value 👉 without causing re-render Using useState was triggering re-renders ❌ 💡 Then I discovered: useRef can store mutable values 👉 without re-rendering the component 🧠 Example: const countRef = useRef(0); countRef.current++; 👉 Value updates 👉 But component doesn’t re-render ✅ Result: • Better performance • No unnecessary re-renders • More control over values 🔥 What I learned: useRef is not just for DOM 👉 it’s for persisting values across renders #ReactJS #FrontendDeveloper #JavaScript #ReactInterview #CodingTips #WebDevelopment

Just wrapped up a highly satisfying 𝗧𝘆𝗽𝗲𝗦𝗰𝗿𝗶𝗽𝘁 task: a fully playable 𝗠𝗲𝗺𝗼𝗿𝘆 𝗖𝗮𝗿𝗱 𝗚𝗮𝗺𝗲! 💻✨ As I progress through my 𝗜𝗧𝗜 𝗠𝗼𝗯𝗶𝗹𝗲 𝗖𝗿𝗼𝘀𝘀-𝗣𝗹𝗮𝘁𝗳𝗼𝗿𝗺 𝘁𝗿𝗮𝗰𝗸, I am focusing on writing 𝗰𝗹𝗲𝗮𝗻, 𝘀𝘁𝗿𝗼𝗻𝗴𝗹𝘆-𝘁𝘆𝗽𝗲𝗱 𝗢𝗯𝗷𝗲𝗰𝘁-𝗢𝗿𝗶𝗲𝗻𝘁𝗲𝗱 code. This project was the perfect playground to connect strict 𝗯𝗮𝗰𝗸𝗲𝗻𝗱-𝘀𝘁𝘆𝗹𝗲 logic with 𝗳𝗿𝗼𝗻𝘁𝗲𝗻𝗱 𝗨𝗜. 𝗧𝗲𝗰𝗵 𝗦𝘁𝗮𝗰𝗸 & 𝗔𝗿𝗰𝗵𝗶𝘁𝗲𝗰𝘁𝘂𝗿𝗲 𝗛𝗶𝗴𝗵𝗹𝗶𝗴𝗵𝘁𝘀: 🛠️ 𝗧𝘆𝗽𝗲𝗦𝗰𝗿𝗶𝗽𝘁: Heavily utilized Interfaces to define data structures and Classes (Game, Card, SoundManager) to handle states, matches, and the Fisher-Yates shuffle algorithm. 🏗️ 𝗛𝗧𝗠𝗟: Created a clean, semantic layout for the game board and progress tracking. 🎨 𝗖𝗦𝗦: Managed the grid layout and brought the cards to life using smooth, 3D CSS transforms and hover states. Mastering these strict OOP concepts and state management in TypeScript is the perfect stepping stone before diving into cross-platform mobile frameworks! https://lnkd.in/dUj-piVP #TypeScript #JavaScript #WebDev #SoftwareDeveloper #ITI #Coding #Frontend

We started naming our useEffect functions some time ago. Tiny change. Outsized impact. ❌ The "Mystery" Way useEffect(() => { fetch(`/api/users/${userId}`) .then(res => res.json()) .then(setUser); }, [userId]); Four effects like this in a component? You're reading every line just to understand what's happening. ✅ The "Self-Documenting" Way useEffect(function fetchUserProfile() { fetch(`/api/users/${userId}`) .then(res => res.json()) .then(setUser); }, [userId]); Now the name tells the story. You only open it when something breaks. But the real wins were unexpected: → If you can't name it without "and" — split it. "fetchUserAndLoadPermissions" is two effects in a trench coat. → Vague names expose effects that shouldn't exist. "updateStateBasedOnOtherState" isn't an effect. It's derived state. Move it out. → Stack traces go from useless to useful. "at (anonymous)" → no idea. "at fetchUserProfile" → straight to the bug. Want to enforce it across your team? "prefer-arrow-callback": ["error", { "allowNamedFunctions": true }] Zero new libraries. Zero new patterns. Just a name. So, start naming your effects. #React #JavaScript #FrontendDevelopment #WebDev

React journey continues — and today's lesson was all about Components. 🧱 A few days ago I talked about JSX. Then the DOM and Virtual DOM. Today? Components made my brain light up in the best way. Here's what I learned: A component is just a JavaScript function that returns JSX. That's it. ```jsx function AnimalFacts() {  return <p>Fun fact about animals!</p>; } ``` But what surprised me the most? You can use it like an HTML tag: ```jsx <AnimalFacts /> ``` That one line renders your entire component. Mind = blown. 🤯 The analogy that made it all click for me? LEGO bricks 🧱 Each component is its own brick — built separately, snapped together to make something bigger. And the best part? They're REUSABLE. One component can work for a dolphin, a lobster, and a starfish! Self taught, learning in public, and taking it one concept at a time. 💪 If you're on a similar journey, let's connect! And if you're experienced — what's YOUR favourite analogy for explaining components? Drop it below 👇 #React #JavaScript #Frontend #Components #LearningInPublic #100DaysOfCode #SelfTaught

setTimeout(fn, 0) looks simple. Until a Promise shows up… and breaks your expectations. You write this: setTimeout(() => console.log("timeout"), 0); Promise.resolve().then(() => console.log("promise")); And you think: “Timeout has 0 delay… it should run first.” But the output is: ->promise ->timeout So what’s actually happening? Not magic. Not randomness. Just how JavaScript is designed. When your code runs, this is the order: Run all synchronous code Execute all Promises (microtasks) Then execute setTimeout (macrotasks) Now read that again. 👉 Promises are not faster 👉 They are just scheduled differently Here’s the hidden detail most devs miss: Even if your setTimeout is ready… JavaScript will pause it until every single Promise is finished. So in reality: setTimeout(fn, 0) → “Run me later” Promise.then() → “Run me right after this code” That’s why Promises always win. Not because they’re special… But because the event loop always clears microtasks first. The simple mental model: 👉 sync → promises → timers Once you understand this, you stop guessing async behavior… …and start predicting it. #javascript #webdev #eventloop #programming #promises #settimeout #nodejs #javascript #nestjs #backend #softwareengineering

Most React performance advice is wrong. Not because the patterns are bad but because developers apply them without understanding what React is actually doing. Here’s what I’ve learned: React.memo without useCallback is just theater. memo tells React: “Only re-render if prop references change.” But if you pass a new function reference on every render, memo does absolutely nothing. // ❌ Kills memo on every render <ProductCard onSelect={(id) => handleSelect(id)} /> // ✅ Actually works const handleSelect = useCallback((id) => { dispatch({ type: "SELECT", payload: id }); }, [dispatch]); useMemo has a cost use it surgically. React still performs dependency comparison on every render. For cheap computations, the memoization overhead can be higher than simply recalculating. Use useMemo only when: the computation is genuinely expensive the result is passed to a memoized child you’ve measured it, not assumed it Before reaching for memo or useMemo, ask: What is actually triggering the re-render? Can you eliminate the trigger instead of memoizing around it? Structural state changes beat memoization every time. What’s the nastiest React performance bug you’ve hit in production? #React #ReactJS #Frontend #TypeScript #WebDevelopment #MERN #JavaScript #SoftwareEngineering

var was forgiving. Sometimes too forgiving. You could use a variable before declaring it and JavaScript would just... let you. No error. Just undefined. let and const changed that. Now the same pattern throws a ReferenceError. But here's what most explanations miss: the variable is hoisted. It exists. The engine knows about it. It just refuses to let you touch it. That window between the start of the scope and the declaration line has a name — the Temporal Dead Zone. The TDZ exists for a reason: catching bugs that var would silently swallow. Using a variable before it's defined is almost always a mistake. Now JavaScript tells you that instead of guessing. One place it catches even experienced devs off guard — default parameter values that reference each other. Do you always know where your TDZ is? 👇 #JavaScript #WebDevelopment #Frontend #JS #SoftwareEngineering

`Date.now` is an impure function. Calling an impure function can produce unstable results. . . This error appears because React 19 is stricter about component purity. example: Your component is being rendered, and during render you call: >> Date.now() React considers that impure. What React Expects ? A React component should behave like a math function: >> f(input) = output - React wants your component to work the same way. Why Date.now() ? - 'Date.now()' Breaks This Rule Because every call gives a different value. So even if props didn't change, render output can change. This doesn’t mean you shouldn’t use non-idempotent functions like new Date() at all – you should just avoid using them during render. In this case, we can synchronize the latest date to this component using an Effect. By wrapping the non-idempotent new Date() call in an Effect, it moves that calculation outside of rendering. If you don’t need to synchronize some external state with React, you can also consider using an event handler if it only needs to be updated in response to a user interaction. Final truth React components are not templates. They are contracts with the rendering engine. Break the contract, and bugs appear. Respect the contract, and React becomes powerful. #ReactJS #Frontend #WebDevelopment #JavaScript #SoftwareEngineering #CleanCode #Programming #React19 #UIEngineering #TechLeadership