Split out of #454, which spotted it while sweeping for specs that assert a fallback. Unlike the rest of that issue this is a component defect, not a test one — the props work, they just also leak into the DOM, and the snapshot has been recording the leak as expected output.
What happens
src/runtime/components/Calendar.vue:259 lists the props to keep off the picker root:
const omittedProps = ['type', 'placeholder', 'range', 'modelValue', 'defaultValue', 'color', 'variant', 'size', 'monthControls', 'yearControls', 'viewControl', 'class', 'b24ui']
viewControl is there. Its four siblings are not, though they are declared the same way — Omit<ButtonProps, LinkPropsKeys>, an object of button configuration:
nextYear?: Omit<ButtonProps, LinkPropsKeys> // :62
nextMonth?: Omit<ButtonProps, LinkPropsKeys> // :73
prevYear?: Omit<ButtonProps, LinkPropsKeys> // :84
prevMonth?: …
So reactiveOmit keeps them, useForwardProps passes them on, and Vue renders each as an attribute whose value is the object stringified:
test/components/__snapshots__/Calendar.spec.ts.snap
nextmonth="[object Object]"
nextyear="[object Object]"
prevmonth="[object Object]"
prevyear="[object Object]"
Exactly four, and no others — the *Icon props do not leak, so the boundary is precisely these four.
Why it survived
viewControl being in the list is the tell: the class of bug was known and one of five was covered. Nothing downstream could catch the other four — the props do what they should, the calendar renders correctly, and the only symptom is four junk attributes in the markup, which the snapshot dutifully recorded as correct.
Reproducing
grep -o 'nextmonth="[^"]*"' test/components/__snapshots__/Calendar.spec.ts.snap
Or in a browser: render <B24Calendar :next-month="{ color: 'air-primary' }" /> and inspect the root element.
The fix
Add the four to omittedProps. Then regenerate the Calendar snapshots — the four attributes disappear and nothing else should move; verify that, because "nothing else should move" is the kind of claim this repository has learned to check rather than assert.
Worth considering while in there: the list is hand-maintained and one omission already slipped through it. Deriving it from the props that are b24ui's own rather than the primitive's would remove the class instead of the instance — every Omit<ButtonProps, …> prop belongs to us by construction and none of them should reach a reka root.
Acceptance
- No
[object Object] attribute in either Calendar snapshot file.
next-month, next-year, prev-month, prev-year still configure their buttons — a case per prop, asserting something the default does not already render, or this issue trades one vacuous test for another.
Priority: P3 — cosmetic in the DOM, invisible to users, and the props themselves work.
Split out of #454, which spotted it while sweeping for specs that assert a fallback. Unlike the rest of that issue this is a component defect, not a test one — the props work, they just also leak into the DOM, and the snapshot has been recording the leak as expected output.
What happens
src/runtime/components/Calendar.vue:259lists the props to keep off the picker root:viewControlis there. Its four siblings are not, though they are declared the same way —Omit<ButtonProps, LinkPropsKeys>, an object of button configuration:So
reactiveOmitkeeps them,useForwardPropspasses them on, and Vue renders each as an attribute whose value is the object stringified:Exactly four, and no others — the
*Iconprops do not leak, so the boundary is precisely these four.Why it survived
viewControlbeing in the list is the tell: the class of bug was known and one of five was covered. Nothing downstream could catch the other four — the props do what they should, the calendar renders correctly, and the only symptom is four junk attributes in the markup, which the snapshot dutifully recorded as correct.Reproducing
grep -o 'nextmonth="[^"]*"' test/components/__snapshots__/Calendar.spec.ts.snapOr in a browser: render
<B24Calendar :next-month="{ color: 'air-primary' }" />and inspect the root element.The fix
Add the four to
omittedProps. Then regenerate the Calendar snapshots — the four attributes disappear and nothing else should move; verify that, because "nothing else should move" is the kind of claim this repository has learned to check rather than assert.Worth considering while in there: the list is hand-maintained and one omission already slipped through it. Deriving it from the props that are b24ui's own rather than the primitive's would remove the class instead of the instance — every
Omit<ButtonProps, …>prop belongs to us by construction and none of them should reach a reka root.Acceptance
[object Object]attribute in either Calendar snapshot file.next-month,next-year,prev-month,prev-yearstill configure their buttons — a case per prop, asserting something the default does not already render, or this issue trades one vacuous test for another.Priority: P3 — cosmetic in the DOM, invisible to users, and the props themselves work.