DEV Community: BlackJosh007

My Timer Kept Doubling — and It Took Me a Real Bug to Actually Understand useEffect

BlackJosh007 — Fri, 04 Sep 2026 00:28:21 +0000

I finished my Tenzies capstone project (built with React) and I want to talk about the one bug that taught me more than any tutorial did.

🔗 Live demo: tenzies-six-silk.vercel.app
🔗 Code: github.com/BlackJosh007/tenzies

I was adding a timer — track how long it takes a player to win. Simple feature, I thought. I set up useState for the elapsed time, useRef for the interval ID, and a useEffect to start the interval once the player held their first die.

It worked... sometimes. Other times my timer would double up out of nowhere, ticking twice as fast. And at one point, after a few touches, it stopped running entirely.

Here's why.

The wrong belief I was carrying

I thought the cleanup function in useEffect only ran once — when the component unmounted. That's what I'd taken away from the tutorial. Knowledge, filed away, never tested.

What actually happens: the cleanup function runs before every re-run of the effect, not just on unmount. Every time your dependency changes, React cleans up the previous effect first, then runs the new one.

I didn't have that cleanup wired in properly. So every time my dependency array changed, a new setInterval was created — without the old one being cleared. Two intervals running at once. Then three. My timer wasn't buggy, it was doing exactly what I told it to do.

It got worse before it got better

My first instinct for triggering the timer was checking diceNo.includes({ isHeld: true }) inside the effect, with seconds as my dependency array. That's a double mistake: .includes doesn't do the deep comparison I wanted (switched to .some(die => die.isHeld) later), and using seconds as the dependency meant the effect was re-running every single tick — re-arming a new interval on top of the old one, every second.

I also had a second wrong belief here: I assumed that if I wrapped my interval logic in an if statement inside the effect, only the code inside the if block counted as "the effect." Not true — the entire function body passed to useEffect is the effect, condition or no condition. React doesn't care what's inside your if; it re-runs the whole thing whenever the dependency changes.

Once I fixed the dependency array (moved to diceNo, gated by a timerStarted ref so the interval only ever arms once) and got the cleanup returning clearInterval(intervalRef.current) properly, the doubling stopped.

The bonus realization

While staring at setInterval(() => setMilliSeconds(prev => prev + 10), 10), I genuinely wondered if React was re-rendering every 10ms because of it. Turns out — no. setInterval is handed off to the browser, not React. React only re-renders when the state update inside the callback actually fires, and it's the state update — not the timer itself — that's on React's clock.

Knowledge vs. understanding

I'd "learned" useEffect and its dependency array from a tutorial before this. I could've told you the definition. But I didn't understand it until a real bug forced me to. That's the difference — knowledge is something you can repeat, understanding is something you can debug.

One thing I changed my mind on

Last post, I said I wanted to add full keyboard navigation to this game. I'm not doing that anymore. Tenzies is an abstract, casual game — realistically, almost everyone playing it will be on a phone, not a desktop with a keyboard. Building out keyboard nav for a demographic that mostly won't use it didn't make sense once I actually thought about who's playing. Instead, I put that time into a timer, roll counter, restart button, and a highscore overlay — features that matter regardless of device.

Onto the next build.

# I Shipped a Working Win-Check... That Could Be Wrong 9 Times Out of 10

BlackJosh007 — Sat, 29 Aug 2026 20:40:51 +0000

While building Tenzies (my React capstone from freeCodeCamp), I hit a problem that looked simple on the surface: check if the player won.

The rule is easy to say out loud: all 10 dice must be held, and all 10 must show the same value. Turning that into code taught me more about array logic than any tutorial had so far — mostly because my first version had a bug I didn't even know to look for.

My First Attempt

I reached for a for loop and a counter:

let count = 0;
for (let i = 0; i < diceNo.length - 1; i++) {
    if (diceNo[i].isHeld && (diceNo[i].value == diceNo[i + 1].value)) {
        count += 1;
        if (count === diceNo.length - 1) console.log("you won");
    }
}

The logic, in my head: compare each die to the next die. If they match in value and the current one is held, count it. With 10 dice, there are 9 pairs — so if all 9 comparisons pass, count hits 9, and that means everyone matches. Right?

It worked. I tested it, saw "you won" print at the right time, and felt genuinely proud — until I looked at the instructor's solution and saw the whole thing done in three lines with .every(). My first reaction was honestly "that feels like cheating." My second, more useful reaction was: wait, is my version even correct?

The Bug I Almost Missed

Look closely at the loop bounds: i < diceNo.length - 1. With 10 dice, i runs from 0 to 8. The isHeld check only ever runs on diceNo[i] — the last die, at index 9, never gets its isHeld checked at all.

So picture this scenario: dice 0 through 8 are all held and all show a 4. Die 9 shows a 4 too, purely by chance, but the player never held it. My loop would still count 9 matches and declare a win — even though one die was never actually locked in by the player. The bug isn't loud; it only shows up in a specific edge case, which is exactly why I didn't catch it just by playing the game normally.

The Fix

let gameWon = false;
if (
    diceNo.every(die => die.isHeld) &&
    diceNo.every(die => die.value === diceNo[0].value)
) {
    gameWon = true;
}

Two separate, symmetric checks: are all 10 held? and do all 10 match the first die's value? Every die gets checked, every time, with no off-by-one gap hiding at the edges. That's the real reason this version is better — not brevity for its own sake, but that it's structurally impossible to skip a die.

The Lesson

The takeaway for me isn't "loops bad, array methods good." It's this: when a loop's bounds don't map 1:1 to "check every item," ask what you're actually excluding — and whether that exclusion is intentional. .every() forced correctness by construction. My loop left a gap I had to go looking for.

Also — I've officially learned to check whether a built-in method already solves my problem before I hand-roll a loop and a counter. Lesson paid for in stress, but paid.

What's Next

I'm planning to extend the game with:

A timer + roll counter, to track how fast you can win
Dice styled with actual pips instead of numbers
Full keyboard navigation for accessibility

Live demo: https://tenzies-six-silk.vercel.app/
Repo: https://github.com/BlackJosh007/tenzies

Wait, Square Brackets Aren't Just for Arrays? — A Controlled Component Gotcha

BlackJosh007 — Fri, 21 Aug 2026 15:21:08 +0000

While building a meme generator with React (following freeCodeCamp), I hit a moment where my mental model of JavaScript syntax completely betrayed me — and untangling it taught me something I won't forget.

I was building a controlled component: two text inputs (top text, bottom text) that update state as the user types. Here's the handler:

function handleChange(event) {
    const { value, name } = event.currentTarget

    setMemeText(prevMeme => ({
        ...prevMeme,
        [name]: value
    }))
}

That [name]: value line stopped me cold. In my head, square brackets meant one thing: arrays. So my brain tried to read this as some kind of array operation happening inside an object spread, and none of it made sense.

What was actually going on

[name] is a computed property name. name is a variable holding a string — in this case, either "topText" or "bottomText" (pulled from the input's name attribute). Wrapping it in square brackets tells JavaScript: "don't use the literal word name as the key — evaluate this variable and use its value as the key instead."

Without the brackets, { ...prevMeme, name: value } would spread the previous state and then literally add a property called name set to whatever was typed. That's not what I wanted — I wanted the actual key to be topText or bottomText, depending on which input fired the event. The brackets are the difference between "the key is the word name" and "the key is whatever name currently equals."

One line, one small syntax convention, and suddenly one function could handle both inputs instead of writing a separate handler for each.

Full context — the input side

<input
    type="text"
    name="topText"
    onChange={handleChange}
    value={memeText.topText}
/>

The name="topText" on the JSX element is what flows into event.currentTarget.name — which is then the value that [name] computes from. Once I traced that full loop — JSX attribute → event object → destructured variable → computed key — it clicked.

Takeaway

If square brackets in an object literal ever throw you off, ask whether you're looking at a computed property name rather than an array. It's a small piece of syntax that does a lot of quiet work.

Still working through the freeCodeCamp React course — challenge sections left before I move on to real project builds.

🔗 Code: [https://github.com/BlackJosh007/chef-claude-app]

The React Concept That Broke My Brain (And Why It Was Actually Simple)

BlackJosh007 — Tue, 28 Jul 2026 23:53:11 +0000

I almost skipped past this. It looked like a small refactor. It ended up being the first time React's "one source of truth" idea actually clicked for me instead of just being a phrase I nodded along to.

Here's the project: a grid of colored pads that toggle on/off when clicked. Simple UI, simple idea.

Where I started: derived state

My first instinct was to create state based on data that lived somewhere else in the component tree — what's usually called derived state. It technically worked. Buttons rendered, colors showed up. But something about it felt fragile, and I couldn't articulate why yet.

Where I ended up: one source of truth

The fix was to move the actual state up into App.jsx, and have everything else just receive data and functions as props. My folder looks like this:
1. App.jsx — holds the single source of truth:

export default function App() {
  const [pads, setPads] = React.useState(padsData)

  function toggle(idR) {
    setPads(prevPads => prevPads.map(item => {
      return item.id === idR ? { ...item, on: !item.on } : item
    }))
  }

  const buttonElements = pads.map(pad => (
    <Pad
      key={pad.id}
      color={pad.color}
      on={pad.on}
      toggleFunc={toggle}
      id={pad.id}
    />
  ))

  return (
    <div className="pad-container">
      {buttonElements}
    </div>
  )
}

2. pads.js — the raw data the state is initialized from:

export default [
  { id: 1, color: "#F18D8B", on: true },
  { id: 2, color: "#F5C280", on: false },
  // ...
]

3. Pad.jsx — a dumb component that just renders and reports back:

export default function Pad({ color, on, toggleFunc, id }) {
  return (
    <button
      style={{ backgroundColor: color }}
      className={on ? "on" : undefined}
      onClick={() => toggleFunc(id)}
    >
    </button>
  )
}

The part that actually confused me

Not the state move itself — that part I could follow. What genuinely took time to reconcile was passing a function as a prop and tracking two different names for the same value:

In Pad.jsx: onClick={() => toggleFunc(id)} — here, id is the real value, the actual id of the button that got clicked.
In App.jsx: function toggle(idR) — here, idR is just a placeholder name, a parameter waiting to receive whatever value gets passed in.

I kept reading idR like it meant something special, like it was doing extra work. It isn't. It's just a name. The moment I stopped trying to find hidden meaning in idR and just traced the value — click happens → id gets passed → toggle receives it as idR → idR gets compared against each item in state — the whole thing clicked into place.

The full loop, in plain language

App.jsx holds pads state, seeded from padsData.
It maps over pads and renders a Pad for each one, passing down color, on, id, and the toggle function itself.
Pad.jsx attaches toggle to its button's onClick, wrapped in an arrow function so it can pass along which button was clicked.
toggle receives that id (as idR), and calls setPads, mapping over the previous state and flipping on only for the item whose id matches.
React re-renders with the updated state, and only the clicked button's color state changes.

Why this matters more than it looks like

The bug I would've eventually hit with derived state is the classic one: two sources of truth drifting out of sync. Lifting the state up removes that possibility entirely — there's exactly one place the "real" data lives, and everything else is just a reflection of it.

This is day-something of learning React in public, building toward real projects instead of just finishing tutorials. If you've hit this same wall with props/state, I'd like to hear how you reasoned through it.

Repo's on GitHub if you want to see the full thing — link in my profile.