Solving the Wrong Problem: What a Closed PR Taught Me

The whole story hinges on a handful of React and CSS concepts. I was throwing these words around before I could have cleanly defined them, so here is what each one actually means and how it showed up in this bug.

• Re-render. React calls your component function again to recompute what it should look like (a fresh virtual-DOM tree). It’s triggered when state or props change, or when a parent re-renders. The key point: a re-render is just React recomputing in memory, it does not necessarily change anything on screen. My children re-rendered on every save, but that by itself was not what the user saw.
• Remount. React throws the old component instance away and builds a brand-new one: it runs cleanup, discards all local state, then re-creates the element and re-runs its mount effects (and any enter animations). It is far more expensive than a re-render, and it is what makes a dialog visibly “pop” or replay its animation.
• Reconciliation. After a re-render produces a new tree, React diffs it against the previous tree and applies only the minimal real-DOM changes. This is why “re-rendered” and “changed on screen” are not the same thing: a component can re-render and reconcile to zero DOM edits.
• React.memo. A wrapper that lets a component skip re-rendering when its new props are “the same” as last time. The catch: “the same” is a shallow comparison, which checks objects by reference rather than by content. Hand it a new object and memo concludes the props changed.
• Object identity (referential equality). Two objects are only equal to === (and therefore to memo) when they are the same object in memory. {a: 1} === {a: 1} is false. Every response.goal was a brand-new object, so prevGoal !== nextGoal even when the values matched, and memo re-rendered anyway. Primitives (strings, booleans, numbers) compare by value, so passing showPause instead of the goal object finally gave memo something stable to trust.
• useCallback. A hook that hands back the same function instance across renders until its dependencies change. Without it a component builds a new function every render, and any memoized child receiving that function as a prop re-renders anyway, the same identity trap as objects. I used it to keep the click handlers stable.
• Layout shift. A purely visual change where an element’s size or position moves its neighbours. The real bug: adding a spinner as an extra child made the button wider, shoving the buttons beside it. That is geometry and CSS, not React reconciliation, which is exactly why a render-focused fix never touched it.
• display: contents + invisible. How the shipped fix hid the label without collapsing the button. display: contents removes an element’s own box so its children lay out as if the wrapper were not there, and Tailwind’s invisible (visibility: hidden) hides the label while keeping the space it occupies. Together they let a centered spinner overlay sit on top while the button holds its exact width, with no shift.

In one line: a hook is a use-prefixed function that lets your component borrow a memory slot from React, so a value can survive from one render to the next.

Why hooks exist

A component is just a function. It runs top to bottom on every render, so any plain variable inside it is created fresh and thrown away each time. A hook is how you keep a value between those runs. Without one, a component can never remember anything.

How React keeps them straight: numbered slots

We can picture a row of lockers that React owns. Each useState call is handed the next locker, in the order the calls run:

const [name, setName]   = useState("");   // call #1 -> slot 1
const [age, setAge]     = useState(0);    // call #2 -> slot 2
const [email, setEmail] = useState("");   // call #3 -> slot 3

• First call gets slot 1, second gets slot 2, and so on.
• React matches calls to slots by position, not by name.
• Every render re-runs the calls in the same order, so each one reads back its own slot.

That is the whole reason for the rule “never call a hook inside an if or a loop.” Skip a call and every later slot shifts by one, so React hands back the wrong data.

The argument is just the starting value (the “seed”)

• useState("") starts that slot empty; useState(0) starts it at zero.
• The seed is used once, on the first render, to fill the slot.
• After that the setter drives the value and the seed is ignored, even though the useState(...) line runs again every render.
• You can have many useState(0) calls; position tells them apart, not the value.

Changing state is what re-renders the UI

user action -> setState(newValue) -> React updates the slot -> re-render -> UI shows the new value

Repeated actions just repeat that loop, each one building on the stored value. A plain variable could not do this: it would reset every render and the UI would never move.

How long does state last?

State lives in memory for the life of the component. A remount, a refresh, or closing the tab empties the slot. To outlive that, you save the value somewhere external and re-seed from it on load.

That split was the whole point in this bug: the dialog’s useState held only my in-progress draft, while the real goal lived on the server. Saving was a network request, so a mid-edit refresh would lose the draft but keep the saved goal.

The five you will meet most

• useState stores a value and re-renders when it changes.
• useEffect runs side effects after render, with cleanup (the [goal, open] re-seed effect was one).
• useCallback keeps a function’s identity stable across renders.
• useMemo keeps a computed value from being recalculated every render.
• useRef holds a value that survives renders without causing one.