Verify Where the Prop Is Absent

Nine of Eleven, From One Optional Slot

A slot was added to the shared panel so a host could render something above the embedded frame. Two apps needed it. It was built, wired into both, and looked correct in both.

It broke the frame in nine of the eleven consumers — every app that passed nothing.

The mechanism is a grid detail with a large consequence. The slot node was rendered only when content was supplied, and a grid row does not collapse when its node is absent: the row remains, and everything below shifts up into it. The frame landed in a middle, auto-sized row, and an embedded frame in an auto row falls back to its intrinsic height. On one measured panel that turned a full-height frame into a small stub with a large empty region under it, and the embedded composer below the visible area.

The Sampling Error, Which Is the Real Lesson

Verification was done in two consumers, and it was thorough. The problem is which two: precisely the two that pass the slot. The entire sample consisted of the feature's users.

The majority — every consumer that passes nothing and therefore hits the new code path in its default state — was never opened. And that state is not an edge case. It is what the change does to almost everybody.

When a shared surface grows an optional prop, verify in a consumer that does NOT pass it. The author of an optional feature has its users open — that is where the work happened and where it is easy to check. Those are the least informative consumers to look at. The default case is the majority case, and it is the one nobody has open, so it has to be verified deliberately rather than incidentally.

Fixed Twice, So It Cannot Recur

Two changes rather than one, and the second is the interesting one. First, the slot node is now always present in the DOM and simply empty when unused, with the empty state dropping its own border — so absence and presence produce the same structure. Second, the frame and its alternative were pinned to an explicit grid row, so no future slot added above them could shift them at all.

The first fix repaired this bug. The second removed the entire class: the next person adding a slot could not reintroduce it, because the frame's position no longer depended on how many nodes preceded it. That is the difference between fixing an incident and fixing the shape that produced it — and it is worth the extra ten minutes precisely because the next person will not have read this story.

EV v3 · 2026-10-12: This lesson described a layout that had already been replaced by the time it was written. The grid did not survive the day of the fix. In the one host that renders the panel inside a native web view, WebKit resolved a grid item's percentage height against the whole grid container instead of its row: the frame came out panel-height, overflowed by exactly the header's height, and the clipping ate the bottom of the embedded composer. The ten browser-hosted apps resolved the same CSS correctly, which is why none of them showed it. The panel became a flex column — header and slot take their content's size, the frame takes the rest, an empty slot is zero height — and the shared stylesheet now says why at the top, as a survival rule for that engine rather than a matter of taste. The class-removing idea held: the frame's position still does not depend on how many nodes come before it. It is just held by a layout model with no rows to get wrong. A fix that removes a class of bug can itself be engine-specific, and this one needed a check in the single host that renders differently — the same sampling lesson, one level down.

Code

The conditional node, the collapse it caused, and both fixes·typescript

// BEFORE - the slot node exists only when content is supplied.
// Looks correct in the two apps that pass it. In the nine that do
// not, the grid row remains and everything below shifts UP into it.
<div className="panel">
  <Header />
  {beforeFrame && <div className="slot">{beforeFrame}</div>}
  <iframe className="frame" src={embedUrl} />
</div>

/*  .panel { display: grid; grid-template-rows: auto auto 1fr; }

    with the slot:      38px  |  90px   |  520px   frame fills 1fr
    without the slot:   38px  |  150px  |  460px
                                  ^^^^^
    the FRAME is now in the middle AUTO row, where an iframe falls
    back to its intrinsic 150px - a stub, with 460px of nothing
    under it and the embedded composer below the fold.            */


// FIX 1 - the node is ALWAYS in the DOM; absence and presence
// produce the same structure. :empty drops the border so an unused
// slot is invisible rather than a stray line.
<div className="panel">
  <Header />
  <div className="slot">{beforeFrame}</div>
  <iframe className="frame" src={embedUrl} />
</div>

/*  .slot:empty { border: 0; padding: 0; }                        */


// FIX 2 - the one that removes the CLASS. The frame is pinned to an
// explicit row, so no future slot added above it can move it at all.
// The next person adding a slot cannot reintroduce this bug, which
// matters because they will not have read this story.

/*  .frame,
    .unavailable { grid-row: 3; }                                 */

// LATER THE SAME DAY - the grid itself went. In a native web view,
// WebKit sized a grid item's percentage height against the whole
// CONTAINER, not its row, so the frame overflowed by the header's
// height. The panel became a flex column; the class stays removed:

/*  .panel  { display: flex; flex-direction: column; }
    .slot   { flex: none; }        empty slot = zero height
    .frame  { flex: 1; min-height: 0; }                           */


// THE TEST THAT WOULD HAVE CAUGHT IT - note the second case is the
// one nobody writes, because it is the case with nothing in it.
test("frame keeps its height WITHOUT the optional slot", () => {
  const { frame } = renderPanel({ beforeFrame: undefined });
  expect(frame.clientHeight).toBeGreaterThan(400);
});

Exercise

Find the most recent optional prop or configuration flag added to a shared component you maintain. List the consumers that pass it and the consumers that do not. Then open one from the second list and check the behavior. If nobody has ever looked at that case, you have found the same sampling error, whether or not it produced a bug this time.

Hint

Check the pull request that added the feature and read which consumers appear in it. If every consumer mentioned is one that passes the new prop, the default case was never observed — and the default case is what most of your users are running.

Nine of Eleven, From One Optional Slot

The Sampling Error, Which Is the Real Lesson

Fixed Twice, So It Cannot Recur

Code

External links

Exercise

Progress

Comments 0