DEV Community: Izak T

I Was Arrested for Guarding Too Much: A Trial About the Null Check That Never Fired

Izak T — Wed, 14 Oct 2026 12:00:00 +0000

The charge: three counts of over-guarding. The evidence: one ternary that had never run. I was not the hero of the trial that followed.

TL;DR A guard should test what can actually happen at that layer. If the view already guarantees a value is non-null, checking it again in the script adds no safety — it adds noise, hides the real contract, and quietly turns bugs into wrong output. The ruling: guard at the boundary, once. Let interior code trust it.

The Arrest

It happened over a schedule board. Two guards came for me — guards, yes, for a man who guards too much.

The charge: over-guarding. Three counts — which three, the paperwork didn't say. The evidence bag held only one exhibit — a Vue computed property, three lines long, the ternary bagged separately:

const pickTechName = computed(() =>
  pickTarget.value ? trayTechName(pickTarget.value) : ''
//  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ this part
)

It names the technician shown in the click-to-place banner on our schedule board. It also, per the arresting officer, stands guard against a null that could never reach it — a doorman paid to open a door that never gets a visitor.

The charge sheet was signed by the prosecutor — a colleague who had read the diff:

"Why do we check for null here when the view already guarantees it?"

I had no answer ready. The prosecution cannot compel a defendant to testify — so taking the stand was my counsel's last card: "The defense calls the defendant." What follows is the transcript of my cross-examination.

Exhibit A: The scene of the alleged crime

The computed has exactly one reader in the entire codebase:

<div v-if="pickTarget">
  <span class="font-semibold">Placing "{{ pickTarget.title }}"</span>
  <span v-if="pickTarget.techId">
    — click an open hour on {{ pickTechName }}'s row
  </span>
</div>

Note the two v-ifs already standing at the door. The banner exists only while pickTarget does; the hint, only when that job actually has a technician — an unassigned job is a real state here, not an exception. The computed is only ever read inside that block — after both checks have already passed.

Cross-Examination, Round One

Prosecutor: Why is that ternary there?

Me: Because pickTarget starts as null. trayTechName(null) would throw — it reads job.techId off the argument. The guard prevents a crash.

Prosecutor: When is the computed evaluated?

Me: When it's read.

Prosecutor: And it's read where?

Me: Inside the v-if="pickTarget" block.

Prosecutor: So at the moment of evaluation, can pickTarget be null?

The court reporter stopped typing.

My counsel rose: "Objection — the question assumes facts that haven't been established."

Overruled. The fact was about to be established anyway. computed in Vue is lazy: the getter does not run at setup. It runs on first read — and the only read is inside a subtree that requires pickTarget to exist. By the time my guard could fire, the condition it tests is already guaranteed false.

My counsel leaned over and whispered: "They have a point. Sit tight — let me see what else we have."

Cross-Examination, Round Two

Prosecutor: Very well. It's redundant today. But isn't it cheap insurance for the future? Someone might read it unguarded later.

Me: It's one comparison. It costs nothing.

Prosecutor: I am not asking what it costs. I am asking what it communicates.

My counsel tried again: "Objection — counsel is testifying."

Overruled. The prosecutor's point stood.

That is the question I had been avoiding. A guard is not a neutral act. It is a claim. It says: "this value can be null at this point." A reader arriving later now has to hunt for the scenario where that's true — and there is none. I had invented a hypothetical future reader to justify a check with no failure mode today.

"Cheap" was never the argument. "Honest" was.

Recess: The Three Kinds of Guards

During the recess, my counsel and I put together a table to explain our defense. Every guard is one of three things:

Kind	Ask yourself	Where it goes	Example
Boundary guard	"Can this outside data be wrong?"	Only where data comes in from outside	Reading `localStorage`, an API, a form
Invariant guard	"Can my guess be wrong?"	Inside, where it must shout if wrong	`assert(items.length > 0)` before indexing
Redundant guard	"Is it already known?"	Nowhere — someone already answered	Re-checking what the view already guarantees

Same question at every layer — and only three answers: yes, never (and say it loudly), or already answered. Only the first two need a check.

A guard should test what can actually happen at that layer — not re-test what a neighbor already guarantees.

The prosecutor rose to answer our table. "This distinction is not just opinion. P2053R1, a C++ committee proposal by Rostislav Khlebnikov and John Lakos, draws the same line: a check is 'defensive' when its assumption is expected to always hold. Human input and remote clients violate assumptions — those need validation at the boundary, not in trusted interior code."

(The full proposal, plus Lakos's CppCon talk summary in plain HTML, cover the same ground.)

My counsel leaned toward me. "But what about spacecraft? A bit flipped by radiation can turn an impossible state into a real one — that's why NASA votes outputs across triple-redundant avionics."

The prosecutor nodded. "Warranted, there — hardware itself can corrupt state. But this is a Vue component, not flight-control software. The template reads this computed only after pickTarget passes its v-if. This ternary doesn't guard against physics; it repeats a software guarantee."

The Prosecution's Case: Three Counts of Over-Guarding

When court resumed, the paperwork finally became specific. The prosecutor read out the three counts — and none of them concern performance.

Count one: it lies about the contract. The guard advertises a possibility that doesn't exist, taxing every future reader with a search for a phantom — after validation, later inconsistency is an internal error and should hard-fail (Michael Belivanakis).

Count two: it masks real bugs. If the invariant ever does break, the guard substitutes '' and renders a slightly wrong UI — instead of throwing a stack trace that points straight at the culprit. John Lakos's CppCon talk summary puts it as near-consensus: "Most would agree that a well-implemented library should do something other than silently continue when a pre-condition violation is detected." The pithier form comes from a heavily upvoted Software Engineering Stack Exchange answer: "isn't the null check, it's the silent fail" — programmer errors are best dealt with by failing immediately and loudly.

Count three: it breeds. Once neither caller nor callee can say who owns the check, every layer starts checking "just in case" — and the codebase fills with guards that guard nothing. This one has the best citation, and it comes from the man who invented the alternative.

The Evidence: Precedent from 1988

My counsel rose once more — keeping his promise from Round One to see what else we had. "I went looking for precedent that might excuse a 'just in case' guard, Your Honor. What I found is older than my client — and it is not on our side. The defense offers no opinions. Only precedent."

Bertrand Meyer's *Design by Contract* — the contract theory behind Eiffel — rests on a rule he calls non-redundancy. In his own chapter on the subject, Meyer states it as an absolute rule:

"Either you have the condition in the require, or you have it in an if instruction in the body of the routine, but never in both."

And he names the cost: redundancy "accumulated over a large system" buries "islands of useful processing in oceans of error-checking code."

The official Eiffel documentation states it operationally — "a routine body should never test for the precondition, since it is the client's responsibility" — and records the counterintuitive payoff: "one can get more reliable software by having fewer explicit checks in the software text."

And in "Applying Design by Contract" (IEEE Computer), Meyer dismantles the exact argument I made on the stand — the "just in case" guard:

"Adding possibly redundant code 'just in case' only contributes to the software's complexity... The result of such blind checking is simply to introduce more software, hence more sources of things that could go wrong at execution time, hence the need for more checks, and so on ad infinitum."

There it is: my "cheap insurance" answer, refuted in 1992 by the man who defined the contract. The court accepts the precedent. I had been arguing against case law I didn't know existed.

The Defense's Best Argument: "But what if a user edits localStorage?"

My counsel played his last card — our strongest argument. "What if a user opens devtools and hand-edits the stored JSON? Then the data genuinely can be wrong, and the guard is justified."

It deserved a real answer rather than a shrug.

The threat model is wrong. A dispatcher at a small business is not going to open devtools and hand-edit a JSON blob. If your safety depends on that being unlikely, you have larger problems than a null check — Instil's write-up is blunt that below the public boundary these checks are overhead meant for tests and review, not runtime guards.

And this is the part I got wrong: the real reasons storage needs care have nothing to do with attackers. They are mundane — an earlier version of the app wrote a different shape, the storage filled and the write silently died, two browser tabs raced to write the same key, a user cleared their browsing data. None of that justifies guards sprinkled through the app. All of it justifies one guard, at the read boundary, where bytes become objects.

So the objection doesn't defeat the rule — it confirms it. Reading localStorage is a boundary: data coming in from outside the app's control. And boundaries are guarded once, at the edge.

The Court's Finding: Where the Guard Belongs in Vue

Before the jury retired, the judge settled the one question the case actually turned on: in a Vue component, who owns the guarantee?

There is a twist specific to Vue worth entering into the record: the template is a boundary.

That is not just convention — it is design. Vue's docs describe the single-file component as "colocating the view, logic and styling of a component" — one component, one shared contract. Which is why they live in one file: split them, and neither side sees the whole guarantee — how duplicate checks get born.

TheCodeForge's guide to the classic Vue template crash explains why: "Templates don't wait. That first render is where nearly every Cannot read properties of undefined is born." Their fix is the same instinct: "fix at the data boundary in setup(), not with scattered guards in every template."

And the idiomatic Vue form is a container v-if — the pattern you already saw in Exhibit A. SoundsCode's lesson says it plainly: the condition narrows the type for everything in that subtree.

One condition. One owner. Compare that to sprinkling pickTarget?.title, pickTarget?.techId, and a ternary inside the computed — three checks, three places to drift, and no single line that states what is actually guaranteed.

One honest footnote, because a sharp reader will spot it: pickTarget is read a second time outside that subtree — :selected-job-id="pickTarget?.id || null", handed to the unscheduled tray, which is always mounted. That optional chain is not the same species of check, and it should stay. There, null is a legitimate value — the tray renders whether or not anything is picked, and the child's prop is typed to receive String | null. That is a boundary handoff, not a redundant guard.

The rule was never "never use ?.." It is "use it where the value can actually be absent" — and the taxonomy above discriminating between two reads of the same ref is exactly the point.

The Verdict

Guard at the boundary, once. Let interior code trust it. Where you can, structure the code so the invalid state is impossible; where you cannot, fail loudly rather than substituting a value.

The template's v-if="pickTarget" is the owner. The computed should not re-litigate it. The corrected exhibit:

const pickTechName = computed(() => trayTechName(pickTarget.value))

If someone later reads it unguarded, it throws — loudly, at the exact line that is wrong. That is not a bug. That is the contract doing its job.

A fair objection: a throw during render can blank the page in production. It is still the better trade — a silent '' hides the defect forever; a throw surfaces it. "Fail loudly" was never "crash the customer." It means fail where you can see it: the console in development, and an error boundary in production — Vue's onErrorCaptured or app.config.errorHandler, which reports the bug and renders a real error state instead of a card full of blanks.

The rule is not "never guard." It is "never silently substitute."

The jury was out for twenty minutes. When they filed back in, the foreman read the verdict to the judge.

Guilty on all three counts. The guard is released from duty — it never worked a day in its life.

Closing Remarks

The lesson was never about null checks. It is that my first two answers were shaped like reasoning while being motivated reasoning — an instinct, then a hunt for justifications instead of facts. The prosecutor was right the entire time; the record only changed when I read the sources and noticed the check I had been defending had never once executed.

The sentence was lighter than I deserved: one deleted ternary, and a paragraph in the project's decision log.

A guard that guards nothing is cheap.

Defending it in court is not.

The Case of the Missing `rem`: A Sherlock Holmes Guide to CSS Units in JavaScript

Izak T — Fri, 02 Oct 2026 02:19:48 +0000

Being the record of an investigation into CSS units, JavaScript geometry, and a very small missing value — as written by Dr. Watson.

A Matter of No Consequence

It began, as many of my friend's cases did, with a problem I thought too small to matter.

"A dropdown," I said, handing Holmes the ticket. "It should sit 0.25rem below its button. An hour's work, no more."

Holmes did not look up.

"You find it trivial, Watson. Yet it has long been an axiom of mine that the little things are infinitely the most important."

He was right. He usually was — and he never let me forget it. That 0.25rem would lead us through the CSS value pipeline, the geometry of the browser, and to the border of JavaScript itself, where a unit had gone missing and nobody had reported it.

The Impossible Request

The dropdown already used Floating UI — a small library that calculates where a floating panel should sit relative to its button. The positioning worked. We only needed to nudge the panel a little below its button.

I wrote the natural thing:

offset('0.25rem')

The library refused it. Its offset() middleware expects a numeric distance:

offset(4)

"Ha!" I said. "The library is simply rude. JavaScript cannot understand relative units. Case closed, Holmes."

Holmes looked up at last.

"The documentation plainly says a number — that part you read correctly. But the design says 0.25rem. Knowing the API wants a number does not tell us which number. That question is the whole case."

He tapped the code with one finger.

"Look closer. The number it wants is bare — no unit attached. Its geometry runs in CSS pixels, the same unit getBoundingClientRect() reports. Every number it takes is understood to mean px. No "4px" string ever crosses the boundary."

"Then why does CSS accept the very same value?" I asked, and showed him:

.dropdown {
  margin-top: 0.25rem;
}

Holmes smiled — the smile that meant the real work was starting.

"One door accepts the visitor. The other refuses him. The mystery is not at either door, Watson. It is at the border between them."

Clue the First: `rem` Is Not a Fixed Number

"The name tells us the first fact," said Holmes, writing on the hearth:

rem = root em

"One rem is based on the font size of the root element — usually <html>. If that size is 16px:"

1rem     = 16px
0.25rem  = 4px

"There," I said. "So it is 4px. Fixed. Done."

"You assume every visitor's browser agrees with your arithmetic, Watson. MDN describes rem as a root-relative length: the common default is 16px, but user preferences may change it. A reader with weak eyesight may set the root font size to 20px. A media query may change it. The application itself may change it."

He underlined his chalk:

0.25 × current root font size

"0.25rem is not a number, Watson. It is a recipe. And a recipe must be baked before it can be eaten."

Clue the Second: CSS Understands the Recipe

"Then the browser is the culprit," I said. "It cannot process relative units."

Holmes shook his head.

"Watch what the engine does with padding: 0.25rem. It knows four things:"

The number is 0.25.
The unit is rem.
rem points to the root font size.
So the final layout distance can be calculated.

"Relative units are not strangers in CSS — they are citizens. The browser resolves them during value processing: first into computed values, then into the final pixel geometry used for layout. MDN walks through this pipeline."

"So the browser is innocent," I said.

"Eliminated. And that is progress, Watson. When you have eliminated the impossible, whatever remains, however improbable, must be the truth. What remains is the strangest suspect of all: JavaScript itself."

Clue the Third: JavaScript Numbers Carry No Units

"In JavaScript," said Holmes, "this is a number:"

0.25

"It has no unit attached. And this is a string:"

'0.25rem'

"JavaScript can hold that string — but arithmetic does not know what it means:"

'0.25rem' * 2 // NaN

"There!" I said. "JavaScript cannot do the math. My own theory, Holmes — it cannot understand relative units."

Holmes looked at me with something between pity and patience.

"JavaScript is not bad at arithmetic, Watson. It multiplies perfectly — the moment it is given numbers. The problem is that an ordinary string carries no CSS meaning into a geometry calculation. The suspect was never arithmetic. The suspect is the border — the crossing between two realms: CSS, where values carry units, and JavaScript, where geometry speaks only in numbers."

He was quiet for a moment.

"JavaScript can ask the browser to resolve CSS values — through getComputedStyle(), or the more structured CSS Typed OM. The translation is possible. It is simply not automatic. And that, Watson, is where our criminal has been hiding all along: in the gap between what CSS says and what JavaScript can measure."

The Missing Translation

When Holmes finally wrote the fix, it was almost too small to believe:

const remToPx = (rem) =>
  rem * parseFloat(getComputedStyle(document.documentElement).fontSize)

Then:

offset(remToPx(0.25))

"If the root font size is 16px:"

0.25 × 16 = 4

"If it is 20px:"

0.25 × 20 = 5

"The result is a bare number — 4, never "4px". The unit lives in the meaning, not in the value."

I studied the little function. "So this fixes JavaScript's weakness with units."

"No, Watson. That theory died two clues ago. Nothing is wrong with JavaScript's arithmetic. This function translates: a CSS-relative length on one side, an absolute pixel number on the other. Every border needs a translator who speaks both languages."

"And this border has many crossings, Watson — canvas, scroll offsets, element measurements. All of them speak in bare numbers."

A Loose Thread

The case looked closed. Holmes, of course, did not think so.

"One thread remains, and it is the one a careless detective never pulls. Is this translation responsive? The function reads the root font size at the moment it runs:"

getComputedStyle(document.documentElement).fontSize

"Call it again after a font-size change, and it picks up the new value. But nothing calls it again on its own. If the result is cached — computed once at startup, or baked into a value created when the page loads — a later font-size change will be ignored until the code runs the conversion again."

"And our own dropdown, Holmes — which of its values are baked, and which stay fresh?"

"In the dropdown that began this case, the panel's maximum height is recalculated on every position update, so it always uses the current root font size. The offset and shift values are created once, when the positioning is set up, so they would only see a font-size change after a reload."

"Is there no way past this last hurdle, Holmes?"

"Floating UI's authors were not blind to the problem, Watson. The offset() middleware accepts not only a bare number, but a function that returns one:"

offset(() => remToPx(0.25))

"Pass the recipe instead of the baked dish, and Floating UI runs our translator on every position update. The gap now follows any font-size change while the page is open — no need to rebuild the middleware. The same trick works for shift()."

He wrote the rule beneath it:

CSS resolves rem dynamically.
JavaScript resolves it only when your code runs the conversion.

"And that, Watson, is why a matter you called trivial led through CSS value processing, browser geometry, and the internals of a positioning library."

"The rem was never missing at all, then," I said.

"It was never missing, Watson. It simply could not cross the border into JavaScript unescorted."

Case closed.

The Smallest Clues

I confess I had expected to waste the afternoon on a four-pixel gap.

Instead, I learned the lesson Holmes had been teaching me all afternoon: the tools you reach for tell you what you do not understand yet. I reached for a string because CSS had taught me that spacing carries units. The library refused it because geometry is spoken in numbers. Between those two truths stood a one-line translator — and behind it, a whole system I had never once thought to inspect.

The smallest clues sometimes open the largest cases.

The Dropdown Behind the Curtain: A Wizard of Oz Guide to CSS Overflow Clipping

Izak T — Wed, 16 Sep 2026 19:52:00 +0000

Somewhere over the rainbow, dropdowns render outside their containers. Down here in Kansas, they get cut in half.

TL;DR An absolute-positioned dropdown inside a scrollable modal gets cut: position: absolute carries the panel past the modal body's padding-box edge, and overflow-y: auto clips everything painted past it. Neither rule causes the bug alone. The fix: teleport the panel out of the scroll container and float it. This post does it in Vue (<Teleport> + Floating UI) — every framework has the same move (e.g. React: createPortal). The Popover API and CSS anchor positioning are the platform's version of it.

Kansas

Dorothy had a four-step setup form. On the second step, the team roster, adding a new team member opens a focused modal — and there their role is picked from a dropdown: Scarecrow, Tin Man, or Lion.

It was a plain <select>. It worked. It was also ugly — gray, boxy, and the dropdown list looked like Windows 95 no matter what she did to it. MDN puts it politely: the <select> element is noted for being hard to style consistently across browsers. A fully styleable <select> is finally landing — Chromium and Safari 27 ship it, Firefox does not yet — but landing and landed in every browser your users run are different things — and Dorothy had a deadline.

The native <select> has one big advantage, though: the browser draws its dropdown as its own layer, outside your boxes — no ancestor's overflow can clip it. That is also why it is hard to restyle: the parts developers want to touch live mostly outside CSS's reach (MDN: Customizable select elements).

So Dorothy did what any developer with a design system and a deadline would do. She swapped the native <select> for a Headless UI component — a Listbox with a styled button and a beautiful, dark, rounded options panel.

<div class="relative">
  <Listbox v-model="role">
    <ListboxButton class="select w-full">{{ role || 'Pick a role' }}</ListboxButton>
    <ListboxOptions class="absolute z-50 w-full mt-1 rounded-lg shadow-lg max-h-60 overflow-auto">
      <ListboxOption v-for="r in roles" :key="r" :value="r">{{ r }}</ListboxOption>
    </ListboxOptions>
  </Listbox>
</div>

The relative wrapper anchors the options to the button — the standard pattern.

She opened it. It was gorgeous.

Then the tornado hit.

The Tornado

The role dropdown sat near the bottom of the modal. When it opened, only the first option was fully visible. Scarecrow showed. Tin Man was cut halfway. Lion was gone — not hidden behind something, just not there.

Dorothy checked z-index. She raised it to 9999. Nothing. She checked the DOM — all three options were rendered, sitting right where they should be. The browser just wasn't drawing them.

Think of it like a stage. The DOM is everything backstage — all three actors exist, standing in their spots. Painting is what the audience sees through the curtain. Lion was on stage — just past the curtain's edge, where nothing gets through.

┌─ modal ───────────────────────────────┐
│  Add Team Member                      │
│ ┌─ modal body (overflow-y: auto) ───┐ │
│ │  Name  [ Ada Lovelace          ]  │ │
│ │  Role  [ Scarecrow           ▾ ]  │ │
│ │        ┌─────────────────────┐    │ │
│ │        │ ✔ Scarecrow         │    │ │ ← painted
│ │        │   Tin Man ▓▓▓▓▓▓▓▓▓ │    │ │ ← half-drawn
│ │════════╪═════════════════════│════│ │ ← the clipping edge
│ │        │   Lion              │    │ │ ← in the DOM, never painted
│ │        └─────────────────────┘    │ │
│ └───────────────────────────────────┘ │
│  [ Cancel ]            [ Add Member ] │
└───────────────────────────────────────┘

The modal body had this:

.modal-body {
  max-height: 70vh;
  overflow-y: auto;
}

That overflow-y: auto was the last ingredient of the tornado. (The max-height beside it is innocent — it limits the box's height but draws no clipping edge.) She didn't know it yet. But back in Kansas, Uncle Henry — who was a farmer — had a saying about the spring storms: no tornado is ever one thing; the storm is what happens when the factors line up. She had been searching for the one line to blame; the saying told her there was no one line to blame — only factors that lined up: the absolute positioning written back in Kansas, and the overflow-y: auto on the modal body. Each one alone was harmless. Together, they lined up.

The Yellow Brick Road

Remembering Uncle Henry's saying, Dorothy set off to find the Wizard — the one fix that would make the dropdown appear. Along the way she met three companions — the same three names she'd been fighting to see in that dropdown, now walking beside her — each with one piece of the answer.

The Scarecrow: "If I only had a brain (that understood overflow)"

The Scarecrow's problem was a mental model. Dorothy's too. She believed:

"overflow: auto lets the user scroll to see what doesn't fit. It reveals content. It doesn't hide anything."

Half right. Here is what the CSS spec via MDN actually says about auto:

"Overflow content is clipped at the element's padding box. When overflowing, the element box is a scroll container displaying scroll bars."

That sentence is doing more work than it sounds like. overflow: auto is two behaviors in one value:

It draws an invisible clipping edge around the element's padding box. Anything painted outside that edge is not drawn at all.
If the element's in-flow content is taller than the box, it adds a scrollbar so that content can be slid into view.

The first one is what people miss. auto clips. So do scroll, hidden, and the newer clip; only visible does not.

The scrollbar is a consolation prize. And the fine print — in-flow content — is the whole key, which is why the Tin Man shows up next.

The Tin Man: "If I only had a heart (in the document flow)"

In-flow just means the element takes up space in the normal layout; an absolutely positioned element is out of flow. MDN's definition of position: absolute puts it plainly:

"The element is removed from the normal document flow, and no space is created for the element in the page layout. The element is positioned relative to its closest positioned ancestor."

(MDN: position)

Read that carefully. The Witch sends two monkeys to make this clip, and each has the job the Winged Monkeys had in the book:

The first monkey is position: absolute — the carrier. In the book, one squad's job was hauling prisoners to the Witch's castle — Toto and the Lion included. Our first monkey's job is the dropdown: he grabs it, pins it to the closest positioned ancestor directly below the button, and lifts it out of the flow — no room reserved, nothing pushed down. Nothing stops him — he can carry it anywhere, even past an edge.
The second monkey is overflow-y: auto on the modal body — the wrecker. The other squad's job was leaving wreckage: the Scarecrow's straw in a tree, the Tin Woodman dented on rocks. Our second monkey's job is the clipping: he draws the scroll area with its invisible edge, and anything painted past it is cut — dented at the edge, or gone from the painting.

Reread the Tornado and you can watch them work: the Scarecrow showed, still inside the edge; the Tin Man was dented — half-drawn at the clip line; the Lion was carried off past the edge, in the DOM and never painted. Absolute positioning places it there; overflow does the clipping. Neither one causes the problem alone — the bug needs both monkeys.

(One bug, two faces: past the edge, the browser paints nothing — the Tin Man dented, the Lion gone. And the dropdown never left: scroll the modal body and the missing half appears, because the browser counts it as part of the container's scrollable area. Same bug wearing a scrollbar — not a fix.)

But the two monkeys don't strike every time. The modal hugs its content, so when the dropdown opens as the last field, it always sits at the curtain's edge and gets cut — every resolution, every monitor. Move it up the form, with fields below it, and the same two rules cut nothing. The cut doesn't care which screen you're on; it cares where in the form the dropdown lives.

As Godstime Aburu writes in Smashing Magazine: "Clipping and positioning are separate systems. They just happen to collide in ways that look completely random until you understand both."

The Lion: "If I only had the courage (to stop guessing)"

Dorothy tried fixes. Each one felt brave. Each one turned out to be another Winged Monkey — reinforcements the Witch sent after her first two, dressed up as fixes: dramatic, helpful-looking, and still working for the Wicked Witch, not her.

Attempt 1 — overflow: visible on the modal body.

The dropdown escaped! And then the modal grew taller than the viewport and the footer buttons disappeared off the bottom of the screen. visible does not clip, but it also does not scroll. She had traded one clipping problem for a different one.

Attempt 2 — position: fixed on the dropdown.

MDN says position: fixed is positioned "relative to its initial containing block, which is the viewport." The viewport is not inside the modal body, so nothing clips it. It worked — except top: 100% now meant "100% of the viewport," and the dropdown rendered at the bottom of the screen, nowhere near its button. Doing it by hand is a real job — code like this, re-run on every scroll and resize:

const rect = buttonEl.getBoundingClientRect()
dropdownStyle.value = { top: `${rect.bottom + 4}px`, left: `${rect.left}px`, width: `${rect.width}px` }

It also has a footgun she dodged: a transformed, filtered, or contained ancestor can hijack the containing block for fixed descendants (MDN: containing block) — and the modal's open/close animation used transform: scale().

Back in the Tornado, her first move was z-index: 9999 — and this is why it was always going to do nothing: z-index only wins fights inside a stacking context. Trapped in a context that already lost, the dropdown can carry the biggest number on the page and still paint underneath everything. The fix is not a bigger number; it is finding which ancestor built the walls.

Attempt 3 — A positioning library.

Teleporting the panel out of the modal solves the clipping — and creates a new job. A panel in <body> is nobody's child: someone must measure the button, follow every scroll and resize, and cap the height underneath. Doing that by hand is Attempt 2's math all over again, so Dorothy reached for Floating UI and wrapped it, with the Teleport, in one small component. A package, a composable, and a wrapper later, the role dropdown worked.

The Lion's courage is not fighting; it is out-thinking the Witch instead of swinging at every flying monkey.

The Emerald City

Dorothy reached the Wizard. Pulled back the curtain. And found:

.modal-body {
  max-height: 70vh;
  overflow-y: auto;
}

The same two rules from the beginning. There was no great and powerful fix. There was a scroll container with a clipping edge, and an absolutely positioned dropdown that had been painting past it.

"Pay no attention to the man behind the curtain" is exactly what a scroll container says. The container is the curtain. Everything behind its padding-box edge is calculated, positioned, real — and never drawn.

The Ruby Slippers

Glinda's line is the whole lesson: you had the power all along — understand what each tool actually does before you reach for the next one.

For a plain text-only dropdown, the ruby slippers really were the <select> Dorothy started with: the browser draws it outside your boxes — the freedom she ended up rebuilding by hand. Teams still swap it for real reasons (MDN: hard to style consistently), and Headless UI's Listbox rebuilds the accessibility for free while adding the styling she needed. The swap was real, not a mistake.

Two more things she learned the hard way:

If you need custom styling, move the positioned ancestor. The oldest trick in the book (CSS-Tricks: Popping Hidden Overflow): the closest positioned ancestor must live outside the overflow container while still being an ancestor of the dropdown. Absolute only clips against the scroll container if the container sits between the dropdown and that ancestor.

Check whether it is actually clipping today. The dropdown got cut because it opened below the modal body's visible edge; add fields beneath it and the same absolute code stops clipping. Nothing fixed itself — the geometry did. And "it fits on my screen" proves nothing: the cut cares where in the form the dropdown lives, not which screen it's on. That is why Dorothy's team wrote the rule structurally instead of hoping the form layout stayed lucky.

What Dorothy Actually Did

The clip is structural, and the only reliable, no-surprises answer is to take the dropdown out of the scroll container's DOM tree entirely. In a Vue + Headless UI app, that means:

Keep the <ListboxButton> inside the form so focus, v-model, and ARIA relationships stay intact.
Render the <ListboxOptions> through a <Teleport to="body"> while the dropdown is open.
Anchor the teleported panel with @floating-ui/vue, using strategy: 'fixed' — safe because the panel lives in <body>, where no transformed ancestor can hijack its containing block, and necessary because Headless UI (the 1.7.x line Dorothy's team ships) calls scrollIntoView() on the active option when the panel opens; with absolute the panel briefly renders at the document's origin, and that call drags the whole document through the modal's overflow: hidden scroll lock.

Concretely, the shared wrapper looks like this — trigger and panel stay in their Headless UI context; only the panel's mounting point changes:

<Listbox v-slot="{ open }" v-model="role">
  <FloatingDropdown :open="open">
    <template #trigger>
      <ListboxButton class="select w-full">{{ role || 'Pick a role' }}</ListboxButton>
    </template>
    <template #panel="{ panelClass, panelStyle }">
      <ListboxOptions static :class="panelClass" :style="panelStyle">
        <ListboxOption v-for="r in roles" :key="r" :value="r">{{ r }}</ListboxOption>
      </ListboxOptions>
    </template>
  </FloatingDropdown>
</Listbox>

The library hands you the mechanics; it does not hand you the product rules. Dorothy's team wrote three down, and each became a middleware choice:

Never flip. A panel that stays attached to its button beats one that repositions itself.
Never shift vertically — horizontally only, or the panel detaches from the trigger while the modal body scrolls.
Cap the height to the space underneath with size(), which publishes that space as a CSS variable the panel folds into its own max-height.

Order matters — offset before shift — and the trigger needs its own visibility check, or the panel lingers, orphaned, after the button scrolls away.

The rule: if a dropdown opens inside a scrollable modal, teleport it and float it. Do not negotiate with overflow. Page-level dropdowns, outside any scroll container, are fine with plain absolute.

Since Dorothy Built Her Form

The platform is catching up. The Popover API is broadly supported, and CSS anchor positioning crossed Baseline in January 2026 when Firefox 147 supplied the last engine. Together they do natively, in CSS, what Dorothy's stack did in JavaScript: the panel renders in the top layer above every clip, opens below its trigger and never flips, caps its height to the space underneath, hides when the trigger scrolls away, and gets light-dismiss and Esc for free.

But every one of those features is positioning. A dropdown is two problems wearing one component, and on behavior — listbox role, arrow keys, typeahead, focus management — the platform is silent. That is the work Headless UI was doing all along, and it does not migrate to CSS: the W3C's Select-Only Combobox pattern and its listbox siblings describe what a custom select owes its users, and hand-rolling it inherits the pattern's own warning — no ARIA is better than bad ARIA.

There's No Place Like Home

And one non-CSS fact: the tools you reach for tell you what you do not understand yet. None of Dorothy's guesses was "read what overflow: auto does."

When she finally did, the answer stopped being a guess. The companions' gifts were the ruby slippers — the understanding had been there all along.

The curtain was two rules of CSS. Often, it is.

Perry Mason in: The Case of the Drifting Timer

Izak T — Thu, 20 Aug 2026 00:47:41 +0000

Perry Mason in: The Case of the Drifting Timer

Opening Statement

You need a reactive "current time" in your Vue 3 app. A schedule grid with a red line showing "now." A live clock. A dashboard that updates every minute.

Every Vue developer reaches for setInterval first. It works. But "works" and "works well" are different things.

This is the story of taking a naive timer from "it ticks" to production-grade — and the four iterations it took to get there. The prosecution calls four exhibits. Let's begin.

Exhibit A: The Memory Leak

const currentTime = ref(new Date())

onMounted(() => {
  setInterval(() => {
    currentTime.value = new Date()
  }, 60000)
})

It works. Sort of. The defense rests — but the prosecution is just getting started.

Exhibits of negligence:

The interval is never cleared. When the component unmounts, the timer keeps firing every 60 seconds forever — updating a ref nothing reads anymore, and holding its closure (and everything the ref references) in memory for the lifetime of the page.
Silent. Invisible. The kind of leak that shows up in production after a user navigates around your app for 20 minutes.

Exhibit B: Component-Only Cleanup

const currentTime = ref(new Date())
let timeInterval = null

onMounted(() => {
  currentTime.value = new Date()
  timeInterval = setInterval(() => {
    currentTime.value = new Date()
  }, 60000)
})

onUnmounted(() => {
  if (timeInterval) clearInterval(timeInterval)
})

Now we clean up. The interval is stored in a variable, cleared on unmount. A step forward. But onUnmounted has a scope limitation worth understanding:

The limitation:

onUnmounted only works inside components. If someone calls this logic from a Pinia store or outside a component's setup() context, onUnmounted never fires. The timer leaks silently. (Composables called synchronously during setup() are fine — Vue's docs recommend exactly that. The problem is when there's no component instance at all.)
The timer fires 60 seconds after load, not at the top of the minute. If a user opens your app at 10:00:58, the clock won't update until 10:01:58. Your app looks broken — the system tray says 10:01 but your UI still shows 10:00.
The timer keeps running when the tab is hidden. Wasting CPU on a clock nobody is looking at.

Exhibit C: Scope-Safe Cleanup

Vue has a method for scope-safe cleanup: onScopeDispose. From the documentation:

This method can be used as a non-component-coupled replacement of
onUnmounted in reusable composition functions, since each Vue component's
setup() function is also invoked in an effect scope.

The implementation is just a push onto the currently active scope's cleanup list. From the Vue core source (roughly — packages/reactivity/src/effectScope.ts):

function onScopeDispose(fn, failSilently = false) {
  if (activeEffectScope) {
    activeEffectScope.cleanups.push(fn)
  } else if (__DEV__ && !failSilently) {
    warn(`onScopeDispose() is called when there is no active effect scope...`)
  }
}

"Currently active" is the key phrase. Every component's setup() runs inside an effect scope that Vue creates and activates for you, so inside a component the cleanup is automatic.

onScopeDispose() cleans up automatically when useNow() is called synchronously within an active Vue effect scope — such as component setup or setup-store creation. Outside one, callers must retain and call the returned stop() or create their own scope.

// In a component — Vue creates the scope, onScopeDispose just works
const { now: currentTime } = useNow()

Pinia setup stores also run inside their own effect scope. Pinia's $dispose() method stops the store's associated effect scope (its source calls scope.stop()), which invokes any onScopeDispose callbacks registered during setup. Note that unlike component unmount, $dispose() must be called intentionally — it is not automatic.

The only time you reach for effectScope() yourself is when there's genuinely no scope to hook into — app-level singletons, plugins, plain modules. In that case, either create a scope and remember to stop it:

// No component, no store — create a scope, and remember to stop it
const scope = effectScope()
scope.run(() => {
  const { now: currentTime } = useNow()
})
scope.stop() // triggers cleanup

…or skip the scope and call stop() manually:

// No scope at all — caller disposes manually
const { now: currentTime, stop } = useNow()
// ...later, when the owner is torn down:
stop()

One caveat, straight from the Vue docs: if onScopeDispose is called with no active scope, Vue logs a warning and the callback is never registered. Vue 3.5+ accepts a second argument, onScopeDispose(cleanup, true), which suppresses the warning — but the callback is still not registered. That's why the final composable uses failSilently = true and exposes stop() for manual disposal.

Exhibit D: Clock Alignment + Visibility Pause

The final composable (shown at the end of this article) addresses the human-perception problem and the battery-drain problem.

Clock Alignment

If you load at 10:00:58, you don't want to wait 60 seconds for the first tick. You want the clock to update at 10:01:00 — aligned to the next interval boundary (minute boundaries with the default 60,000 ms interval).

The composable reads the current time immediately on start, then schedules every subsequent tick at the next interval boundary. So the clock is correct from the moment it loads, and stays aligned on every tick.

const msUntilNextTick = interval - (Date.now() % interval)
setTimeout(() => {
  now.value = Temporal.Now.plainTimeISO()
  timer = setInterval(() => {
    now.value = Temporal.Now.plainTimeISO()
  }, interval)
}, msUntilNextTick)

With the default 60,000 ms interval, msUntilNextTick is the milliseconds remaining until the next minute boundary. The initial setTimeout fires at that boundary, then hands off to a recurring timer for all subsequent ticks. The clock feels synchronized with the system tray.

But there's a subtlety: setInterval drifts. Modern browsers under system load or low-power modes can slip a few milliseconds per tick. Over hours, the timer ends up firing 5–10 seconds past the top of the minute. The fix is a self-correcting recursive setTimeout that recalculates interval - (Date.now() % interval) on every tick — re-aligning to the real interval boundary each time. Delay does not accumulate from one tick to the next — if the browser runs a callback late, the next callback is scheduled toward the next clock boundary rather than inheriting the previous lateness.

Visibility Pause

When the user switches tabs, document.hidden becomes true. We stop the timer. When they come back, we immediately sync the time and restart the interval.

const onVisibilityChange = () => {
  if (document.hidden) {
    stop()
  } else {
    start() // immediately reads the current time, then starts ticking
  }
}

No wasted CPU when nobody is looking. No stale time when they return.

SSR Safety

If this composable runs during Server-Side Rendering (Nuxt, Vite SSG), document doesn't exist. Calling document.addEventListener at the top level would crash with ReferenceError: document is not defined.

The fix: wrap all DOM-dependent code in a typeof window !== 'undefined' guard. The DOM code is SSR-safe. Separately, if you use Temporal, the server needs it too — natively or through a polyfill imported at your app's entry point. These are two independent requirements: no DOM on the server, and Temporal availability on the server.

Hydration note: Rendering live time on the server can cause hydration
mismatches because the server and browser render at different moments — and
potentially in different time zones. The cleanest pattern for a live clock is
to render a neutral placeholder server-side and start the actual clock after
client mount.

Temporal Precision

Temporal.Now.plainTimeISO() defaults to nanosecond precision (e.g., 14:30:15.123456789). When bound directly to a template, those sub-second digits render as noise. The fix: round to seconds with .round({ smallestUnit: 'second' }) so now.value formats cleanly out of the box.

The Verdict: The Final Composable

import { shallowRef, onScopeDispose } from 'vue'

const isBrowser = typeof window !== 'undefined'

export function useNow(interval = 60000) {
  if (!Number.isFinite(interval) || interval <= 0) {
    throw new RangeError('interval must be a positive finite number of milliseconds')
  }

  // Round to seconds so default template rendering is clean (e.g., "14:30:15")
  const getNow = () =>
    Temporal.Now.plainTimeISO().round({ smallestUnit: 'second' })

  // shallowRef: Temporal.PlainTime is immutable — no need for Vue to proxy
  // its internals. We only ever replace .value, never mutate it.
  const now = shallowRef(getNow())
  let timer = null

  const stop = () => {
    if (timer !== null) {
      clearTimeout(timer)
      timer = null
    }
  }

  // Self-correcting recursive timeout: recalculates remaining ms to next
  // boundary on every tick — delay does not accumulate across ticks
  const scheduleNextUpdate = () => {
    stop()
    const msUntilNextTick = interval - (Date.now() % interval)
    timer = setTimeout(() => {
      now.value = getNow()
      scheduleNextUpdate()
    }, msUntilNextTick)
  }

  const start = () => {
    // Don't schedule if the page is already hidden (e.g. loaded in a
    // background tab) — visibilitychange only fires on state changes
    if (isBrowser && document.hidden) return
    stop()
    now.value = getNow()
    scheduleNextUpdate()
  }

  const onVisibilityChange = () => {
    if (document.hidden) stop()
    else start()
  }

  const dispose = () => {
    stop()
    if (isBrowser) {
      document.removeEventListener('visibilitychange', onVisibilityChange)
    }
  }

  // SSR Safe: only attach DOM listeners in the browser environment
  if (isBrowser) {
    start()
    document.addEventListener('visibilitychange', onVisibilityChange)
  }

  // failSilently=true: if no active scope, caller must call stop() manually
  onScopeDispose(dispose, true)

  return { now, stop: dispose }
}

Usage in a component:

// Vue creates the scope — onScopeDispose handles cleanup automatically
const { now: currentTime } = useNow()

Usage outside a scope (plugins, plain modules):

// No active scope — caller disposes manually
const { now: currentTime, stop } = useNow()
// ...later, when the owner is torn down:
stop()

The composable handles:

Clock alignment to interval boundaries (minute boundaries with the default 60,000 ms interval; self-correcting, non-accumulating delay)
Tab visibility pausing (including when the page loads already hidden)
Scope-safe cleanup when called inside an active scope (components, Pinia setup stores, effectScope)
Manual disposal via stop() when called outside a scope
SSR safety for DOM code (if you use Temporal, the server needs it too — import a polyfill at your app's entry point if needed)
Clean Temporal formatting (rounded to seconds)
shallowRef for immutable Temporal objects (no unnecessary proxying)

Many Clocks: Share One Instance

Each useNow() call creates its own timer and visibilitychange listener. That's fine for one or a few clocks, but if a page renders many clock components, consider sharing a single app-level useNow() instance via effectScope() and passing the ref down via props or provide/inject.

Closing Arguments: Why Recursive `setTimeout` Instead of `setInterval`?

setInterval: Fires on a fixed interval, but modern browsers drift under load or in low-power modes. A few milliseconds per tick compounds over hours — your clock ends up 5–10 seconds off the real interval boundary. Since we're building a clock UI, that drift is visible to users.

setTimeout (recursive): Each callback recalculates interval - (Date.now() % interval) before scheduling the next tick. This re-aligns to the real interval boundary on every tick. Delay does not accumulate — if the browser runs a callback late, the next callback targets the next clock boundary rather than inheriting the previous lateness. The callback reads Temporal.Now.plainTimeISO() — instantaneous — so there's no risk of overlapping calls.

requestAnimationFrame: Fires ~60x/sec, synced to screen refresh. Designed for smooth animations. Way too frequent for a 60-second clock.

nextTick: Not a timer at all. Fires once, after Vue's DOM update cycle. No concept of time or repetition.

For a clock that needs to stay in sync with the system tray over long sessions, self-correcting recursive setTimeout is the right tool. Browser timer scheduling is not exact — the event loop can be busy, and background tabs are commonly throttled — but self-correction ensures that lateness doesn't compound.

Expert Testimony: Why Temporal API Instead of `Date`?

Date is perfectly reasonable for a simple display clock — especially if your app doesn't already depend on Temporal. But if your app already uses Temporal for its date/time semantics, it's the natural choice here.

The Date object is mutable — setHours(), setDate(), setMinutes() all modify the instance in place. This leads to subtle bugs when the same instance is shared across reactive state.

Temporal.PlainTime and Temporal.PlainDate are immutable. Every operation returns a new instance. No mutation bugs possible. PlainTime represents wall-clock time without a date or time zone — exactly what a display clock needs.

// Date — mutable, error-prone
const d = new Date()
d.setDate(d.getDate() + 1) // tomorrow, but d is mutated in place

// Temporal — immutable, safe
const today = Temporal.Now.plainDateISO()
const tomorrow = today.add({ days: 1 }) // new instance, today unchanged

As of mid-2026 it's formally standardized as Stage 4 and being merged into the ES2027 specification (the TC39 finished-proposals list updated the target publication year from 2026 to 2027). It's available in current Chromium and Firefox, but full cross-browser support still requires a fallback or polyfill — Safari and iOS Safari remain unsupported. The proposal's implementation status and caniuse agree:

Chrome 144+ — shipped January 13, 2026
Firefox 139+ — shipped May 27, 2025
Edge 144+ — Chromium-aligned
Safari — Technology Preview only, disabled by default; the WebKit implementation bug is still open
Node.js 26+ — shipped May 5, 2026

If you need to support browsers without native Temporal, import a Temporal polyfill at your app's entry point. Two options are @js-temporal/polyfill (closest to the reference implementation, currently alpha) or temporal-polyfill (by FullCalendar, stable release). Pick the one that fits your needs.

Case Summary

"Works" is not "works well." The naive setInterval ticks. But it leaks, drifts from real time, and wastes CPU on hidden tabs.
Prefer onScopeDispose for reusable composables. It works inside any active Vue effect scope (components, Pinia setup stores, effectScope()) — and inside components it's literally equivalent to onUnmounted, per RFC #0041. But it's not magic: if there's no active scope, the callback is never registered. Always expose a manual stop() for unmanaged usage.
Clock alignment is a human-perception problem. Users don't know what "drift" means, but they know your clock looks wrong when it doesn't match their system tray.
Self-correcting beats fixed intervals. setInterval drifts under load. A recursive setTimeout that recalculates alignment on every tick ensures delay doesn't accumulate — the next tick always targets the next real clock boundary.
Guard against SSR. If your composable touches document or window, wrap it in typeof window !== 'undefined'. And if you use Temporal, make sure the server has it too — natively or via polyfill.
Use shallowRef for immutable objects. Temporal.PlainTime is
immutable — you only ever replace .value, never mutate its internals. shallowRef avoids unnecessary proxy conversion and is the appropriate model for external class instances.

The court finds setInterval guilty of negligence. The composable is released into production. Case closed. ⚖️

The Case of the Lying Clock: 5 Vue Mysteries Solved

Izak T — Thu, 13 Aug 2026 03:34:40 +0000

Every detective has their cold cases. These are mine — five Vue concepts that
confused me until I investigated them properly. Grab your magnifying glass.

Case #1: The Lying Clock

Imagine you set an alarm to go off every 60 seconds. You press start at
10:00:00.

First alarm: 10:01:00 — perfect
Second alarm: 10:02:00 — still good
But your phone is also doing other things: checking email, refreshing weather, running background tasks. Sometimes it fires the alarm a tiny bit late.
Third alarm: 10:03:01 (1 second late)
Fourth alarm: 10:04:02 (2 seconds off now)
Five hours later: your alarm fires at 15:05:12 when it should fire at 15:05:00

That gap growing bigger over time — that's drift. The timer slowly slides
away from where it should be.

Why Does This Happen?

JavaScript runs on a single thread — it can only do one thing at a time. When a
timer is supposed to fire, the browser puts it in a queue. But if the thread is
busy doing something else, the timer waits. The MDN documentation for
setTimeout
lists several reasons timers fire late:

Nested timeouts are throttled to a minimum of 4ms after 5 levels of nesting (per the HTML5 spec)
Background tabs are throttled to a maximum of once per second (MDN: "timeouts are throttled to firing no more often than once per second (1000 ms) in inactive tabs")
Chrome 88+ introduced intensive throttling for hidden pages: timers that have been hidden for more than 5 minutes are checked only once per minute
Tracking scripts in Firefox get even more aggressive throttling: 10 second minimum in background tabs

Does This Happen on New Devices Too?

Yes, but less. Modern devices are faster, so the delay per tick is smaller —
maybe 1-2 milliseconds instead of 10-20. But over hours, even 1ms per tick
adds up. And background tab throttling happens on every device, no matter how
fast — it's a browser policy, not a hardware limitation.

Is This Common Knowledge?

It's the kind of thing you learn when your boss says "why does the clock on
our dashboard show the wrong time after lunch?" and you Google it. Many
developers use setInterval and never notice because their app doesn't stay
open long enough for the drift to matter.

Case #1 Continued: How Recursive `setTimeout` Fixes the Drift

A fixed interval can fall behind its intended clock boundary when callbacks
run late — the lateness piles up:

Start at 10:00:00
→ fire at 10:01:00.002 (2ms late)
→ fire at 10:02:00.005 (5ms late)
→ fire at 10:03:00.009 (getting worse)
→ ...hours later, you're 10+ seconds off

Recursive setTimeout recalculates the next boundary from wall-clock time
each tick, so delay doesn't accumulate:

Start at 10:00:00
→ "next minute is 10:01:00, that's 60000ms away" → set timeout for 60000ms
→ fire at 10:01:00.002 (2ms late — same as before)
→ BUT NOW: check clock: "it's 10:01:00.002, next minute is 10:02:00, that's 59998ms"
→ set timeout for 59998ms
→ fire at 10:02:00.001 (only 1ms late! it corrected itself!)
→ check clock: "it's 10:02:00.001, next minute is 10:03:00, that's 59999ms"
→ fire at 10:03:00.000 — right on time

It's called "recursive" because the function calls itself — inside the
setTimeout callback, we call scheduleNextTick() again, which sets up the
next setTimeout. It's a loop that builds itself one step at a time.

Analogy:

setInterval = a runner who counts their steps and hopes they're on pace
Recursive setTimeout = a runner who checks their watch before every step

Case #2: The Box That Didn't Need Tracking — `shallowRef` vs `ref`

When you put an object inside ref(), Vue wraps every single property in a
reactive proxy. If your object has { hour: 14, minute: 30, second: 15 }, Vue
tracks all three properties — plus every method, plus any nested objects. This
is great when you need to change one property and have the UI update.

But Temporal.PlainTime is immutable — you can never change its properties.
You can only throw the whole thing away and make a new one. So Vue's deep
tracking is wasted effort.

shallowRef says: "only track .value itself, don't go inside." The Vue
documentation puts
it plainly:

Unlike ref(), the inner value of a shallow ref is stored and exposed as-is,
and will not be made deeply reactive. Only the .value access is reactive.

And the docs even tell you when to use it:

shallowRef() is typically used for performance optimizations of large data
structures, or integration with external state management systems.

Since we only ever do now.value = getNow() (replace the whole object) and
never mutate internal properties, shallowRef does exactly what we need — and
nothing we don't.

Analogy: ref is like putting a GPS tracker on every item inside a box.
shallowRef is like putting a tracker only on the box. If you never open the
box and change items inside — you only swap the whole box — the single tracker
is enough.

Case #3: The Cleanup That Worked Everywhere — Effect Scopes and `onScopeDispose`

The Problem

When a component unmounts, Vue needs to clean up — stop timers, remove event
listeners, cancel watchers. onUnmounted is the hook for this. But it only
works inside components. If you use a composable from a Pinia store or a
standalone module, onUnmounted never fires — there's no component to unmount.

The Solution

Vue 3.2 introduced effectScope and onScopeDispose via
RFC #0041.
The RFC explains the motivation:

In Vue's component setup(), effects will be collected and bound to the
current instance. When the instance gets unmounted, effects will be disposed
automatically. This RFC is trying to abstract the component's setup()
effect collecting and disposing feature into a more reusable API that can be
used outside of the component model.

In plain English: Vue already had this cleanup mechanism inside components. They
just made it available outside components too.

How It Works

Every component's setup() runs inside an effect scope — Vue creates it
automatically. onScopeDispose registers a cleanup callback on whatever scope
is currently active. The Vue docs
describe it as:

Registers a dispose callback on the current active effect scope. This method
can be used as a non-component-coupled replacement of onUnmounted in
reusable composition functions, since each Vue component's setup() function
is also invoked in an effect scope.

So inside a component, onScopeDispose and onUnmounted do the same thing.
But onScopeDispose also works in Pinia stores and standalone scopes.

Will `onMounted` and `onUnmounted` Go Away?

onMounted — stays forever. It's about the DOM being ready, not about cleanup. Neither effectScope nor onScopeDispose can replace it.
onUnmounted — mostly replaced by onScopeDispose for cleanup in composables. It still works, but onScopeDispose is more versatile.

What Happens If You Use Both Inside a Component?

Nothing bad — they both fire during teardown. No conflict, no error.
It's just redundant — using both for the same cleanup is unnecessary.

The Catch: No Active Scope

If onScopeDispose is called with no active scope (like from a plain module),
Vue logs a warning and the callback is never registered. The
Vue source
shows exactly why:

function onScopeDispose(fn, failSilently = false) {
  if (activeEffectScope) {
    activeEffectScope.cleanups.push(fn)
  } else if (!failSilently) {
    warn(`onScopeDispose() is called when there is no active effect scope...`)
  }
}

No activeEffectScope → no push → no cleanup. That's why our composable uses
failSilently = true (to suppress the warning) and exposes a stop()
function (so the caller can clean up manually).

Analogy: onUnmounted is like "tell me when the building is demolished."
onScopeDispose is like "tell me when my room is demolished" — works whether
your room is in a building, a store, or a standalone structure. But if you're
not in any room at all, nobody will tell you anything — so keep a fire
extinguisher (stop()) handy.

Case #4: The Server That Knew Too Much — Hydration

The Short Version

When using SSR (Server-Side Rendering, like Nuxt), the server generates complete
HTML and sends it to the browser. The user sees a full page immediately. Then
Vue loads in the browser and "takes over" that HTML — attaching event listeners,
making it interactive. That takeover is hydration.

Why It Matters for Clocks

The server renders at one moment — say 10:00:00. That HTML travels across the
internet for 500ms. The browser hydrates at 10:00:01. Vue compares the server
HTML to what it wants to render and finds a mismatch: the server wrote 10:00:00
but the browser wants 10:00:01.

The Nuxt hydration guide
lists this as a common problem:

Content that changes based on current time.

And Nazar Boyko's deep dive on hydration
explains why it matters:

The server runs this code at, say, 14:32:01. The client runs it at 14:32:03.
The text nodes do not match, and Vue complains.

It gets worse: the server might be in a different time zone than the user. A
server in New York rendering 10:00:00 EST is 15:00:00 for a user in Tokyo.

The Fix

The cleanest pattern is to render a placeholder on the server and start the real
clock only after the browser takes over. As the
Mastering Nuxt guide
recommends:

Render time only on the client.

Or use Nuxt's <ClientOnly>
component, or the
<NuxtTime> component which is
specifically designed for SSR-safe time rendering.

Analogy: It's like a restaurant menu printed yesterday with "Today's Special:
Soup." When you read it today, it's wrong. Better to leave the special blank on
the printed menu and write it in by hand when the customer sits down.

Does This Apply to Every Project?

No — if you're using plain Vite + Vue, not SSR, there's no hydration. But a
good composable handles it anyway with the typeof window !== 'undefined'
guard, which is good practice for reusable code that someone might use in Nuxt
someday.

Case #5: The Warning Nobody Needed — `failSilently`

When onScopeDispose is called with no active scope, Vue logs a warning:
"Hey, there's no scope to attach this to!" That warning can be noisy if you
intentionally call the composable outside a scope.

Passing true as the second argument tells Vue: "I know there might not be a
scope. Don't warn me. I'll handle cleanup myself with stop()."

Important: failSilently = true does not create cleanup. It just hides
the warning. The callback is still not registered. You still need stop().

Mini-note: Temporal Rounding — Temporal.Now.plainTimeISO() gives you
nanosecond precision (14:30:15.123456789). That's nine digits after the
seconds. .round({ smallestUnit: 'second' }) trims it to 14:30:15. Clean.
Like showing "$14.30" instead of "$14.300000001."

Case Closed

Timer drift — A fixed interval can fall behind its intended clock boundary; recursive setTimeout recalculates from wall-clock time each tick
shallowRef — Only tracks .value replacement, not internal property changes — perfect for immutable objects
Effect scopes + onScopeDispose — Scopes group reactive effects for disposal; onScopeDispose registers cleanup on the active scope — works in components, setup-store creation, and manual scopes, but not with no scope at all
Hydration — Server sends HTML, browser "takes over" — time-based content can mismatch between the two
failSilently — Suppresses the "no active scope" warning; does NOT create cleanup — you still need stop()

Stop Using Props + Watchers Just to Trigger Actions in Child Components (Vue 3.5 useTemplateRef + defineExpose)

Izak T — Fri, 07 Aug 2026 22:41:36 +0000

How many times have you seen (or written) code where a parent component passes a boolean prop to a child component solely to trigger a method inside that child?

<!-- ❌ Parent passing a trigger flag -->
<ChildComponent :shouldReset="isResetting"/>

Inside the child component, you end up writing an artificial watcher just to catch that state flip:

<!-- ❌ Child watching a prop just to run a method -->
<script setup>
import { watch } from 'vue'

const props = defineProps<{ shouldReset: boolean }>()

watch(() => props.shouldReset, (newVal) => {
  if (newVal) {
    resetForm() // Running internal logic based on prop change
  }
})
</script>

This is a classic Vue code smell. Passing state down when you actually mean to send a command creates awkward state-toggling hacks, extra reactivity cycles, and unnecessary watcher logic.

Here is how to clean up this anti-pattern using defineExpose and Vue 3.5’s useTemplateRef().

Why "Props + Watchers" as Action Triggers is a Smell

Artificial State Pollution: You have to manage boolean flags in the parent (isResetting = true, then back to false) just to fire a one-time event.
Reactivity Overhead: Vue has to track the prop dependency, queue the watcher, evaluate the callback, and schedule component re-renders—all to invoke a simple function.
Cluttered Child Logic: The child component needs boilerplate code to watch a prop, handle boolean states, and reset the flag.

Vue is primarily declarative, but UI actions are inherently imperative. Focusing an input, resetting a form, playing an animation, or stepping through a wizard are actions, not state.

The Better Pattern: `defineExpose` + `useTemplateRef`

Instead of forcing declarative props onto an imperative action, expose the child’s internal function directly to the parent.

Step 1: Explicitly Expose the Method in the Child

By default, components using <script setup> are closed. External components cannot access internal variables or functions unless you explicitly expose them using defineExpose.

<!-- ChildComponent.vue -->
<script setup>
import { ref } from 'vue'

const formState = ref({ name: '', email: '' })

// The internal action
const resetForm = () => {
  formState.value = { name: '', email: '' }
  console.log('Form reset executed!')
}

// Explicitly grant access to external parents
defineExpose({
  resetForm
})
</script>

<template>
  <form>
    <input v-model="formState.name" placeholder="Name" />
    <input v-model="formState.email" placeholder="Email" />
  </form>
</template>

Step 2: Call the Exposed Method in the Parent (Vue 3.5)

In Vue 3.5+, use useTemplateRef() to obtain a strongly-typed reference to the child component instance, then call the method directly.

<!-- ParentComponent.vue -->
<script setup>
import { useTemplateRef } from 'vue'
import ChildComponent from './ChildComponent.vue'

// Obtain the reference using Vue 3.5's useTemplateRef
const childRef = useTemplateRef('childRef')

const handleResetButtonClick = () => {
  // Directly invoke the exposed method on the child instance
  childRef.value?.resetForm()
}
</script>

<template>
  <div>
    <ChildComponent ref="childRef"/>
    <button @click="handleResetButtonClick">Reset Child Form</button>
  </div>
</template>

The Architectural Balance: When to Use What

A common rule in Vue is "Props Down, Events Up". Reaching into child components with refs should not replace standard data flow, but knowing when to use each pattern keeps your architecture clean:

Scenario	Recommended Pattern	Why
Passing data into a child	Props (`:data="..."`)	Declarative state rendering
Notifying a parent about child actions	Emits (`@submit="..."`)	Decoupled event notification
Triggering imperative child UI actions	`defineExpose` + `useTemplateRef`	Direct command execution without state hacks

Summary

If your component requires a prop and a watch solely to trigger an internal function, you are using reactivity as a workaround for command execution.

Leverage defineExpose alongside Vue 3.5's useTemplateRef() to keep component logic clean, imperative, and free of artificial state flags.

DEV Community: Izak T

I Was Arrested for Guarding Too Much: A Trial About the Null Check That Never Fired

The Arrest

Exhibit A: The scene of the alleged crime

Cross-Examination, Round One

Cross-Examination, Round Two

Recess: The Three Kinds of Guards

The Prosecution's Case: Three Counts of Over-Guarding

The Evidence: Precedent from 1988

The Defense's Best Argument: "But what if a user edits localStorage?"

The Court's Finding: Where the Guard Belongs in Vue

The Verdict

Closing Remarks

The Case of the Missing `rem`: A Sherlock Holmes Guide to CSS Units in JavaScript

A Matter of No Consequence

The Impossible Request

Clue the First: rem Is Not a Fixed Number

Clue the Second: CSS Understands the Recipe

Clue the Third: JavaScript Numbers Carry No Units

The Missing Translation

A Loose Thread

The Smallest Clues

The Dropdown Behind the Curtain: A Wizard of Oz Guide to CSS Overflow Clipping

Kansas

The Tornado

The Yellow Brick Road

The Scarecrow: "If I only had a brain (that understood overflow)"

The Tin Man: "If I only had a heart (in the document flow)"

The Lion: "If I only had the courage (to stop guessing)"

The Emerald City

The Ruby Slippers

What Dorothy Actually Did

Since Dorothy Built Her Form

There's No Place Like Home

Perry Mason in: The Case of the Drifting Timer

Perry Mason in: The Case of the Drifting Timer

Opening Statement

Exhibit A: The Memory Leak

Exhibit B: Component-Only Cleanup

Exhibit C: Scope-Safe Cleanup

Exhibit D: Clock Alignment + Visibility Pause

Clock Alignment

Visibility Pause

SSR Safety

Temporal Precision

The Verdict: The Final Composable

Many Clocks: Share One Instance

Closing Arguments: Why Recursive setTimeout Instead of setInterval?

Expert Testimony: Why Temporal API Instead of Date?

Case Summary

The Case of the Lying Clock: 5 Vue Mysteries Solved

Case #1: The Lying Clock

Why Does This Happen?

Does This Happen on New Devices Too?

Is This Common Knowledge?

Case #1 Continued: How Recursive setTimeout Fixes the Drift

Case #2: The Box That Didn't Need Tracking — shallowRef vs ref

Case #3: The Cleanup That Worked Everywhere — Effect Scopes and onScopeDispose

The Problem

The Solution

How It Works

Will onMounted and onUnmounted Go Away?

What Happens If You Use Both Inside a Component?

The Catch: No Active Scope

Case #4: The Server That Knew Too Much — Hydration

The Short Version

Why It Matters for Clocks

The Fix

Does This Apply to Every Project?

Case #5: The Warning Nobody Needed — failSilently

Case Closed

Stop Using Props + Watchers Just to Trigger Actions in Child Components (Vue 3.5 useTemplateRef + defineExpose)

Why "Props + Watchers" as Action Triggers is a Smell

The Better Pattern: defineExpose + useTemplateRef

Step 1: Explicitly Expose the Method in the Child

Step 2: Call the Exposed Method in the Parent (Vue 3.5)

The Architectural Balance: When to Use What

Summary

Clue the First: `rem` Is Not a Fixed Number

Closing Arguments: Why Recursive `setTimeout` Instead of `setInterval`?

Expert Testimony: Why Temporal API Instead of `Date`?

Case #1 Continued: How Recursive `setTimeout` Fixes the Drift

Case #2: The Box That Didn't Need Tracking — `shallowRef` vs `ref`

Case #3: The Cleanup That Worked Everywhere — Effect Scopes and `onScopeDispose`

Will `onMounted` and `onUnmounted` Go Away?

Case #5: The Warning Nobody Needed — `failSilently`

The Better Pattern: `defineExpose` + `useTemplateRef`