feat(plugin-detail): declare hideEmpty on the detail-section node (objectui#10485) - #10552
Conversation
… (objectui#10485)
`DetailSection` reads `section.hideEmpty === true` (the all-empty hide), but
the `detail-section` registration and `DETAIL_SECTION_NODE_INPUTS` did not
declare it, so an authored `hideEmpty` drew `unknown-prop` and was dropped
before it reached the section.
The registration gains `{ name: 'hideEmpty', type: 'boolean' }` with a
description stating the node's omitted default (keep the all-empty section,
which is what an unauthored node already did), and the fold list gains
`'hideEmpty'`. No change to `DetailSection`'s hide logic.
New pin: detailSectionAuthoredHideEmpty-10485.test.tsx (validate rows, a lit
`name` control, and render rows through the real SchemaRenderer).
Co-Authored-By: Claude <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01BA3nKVUwKQJf8DBxrSVtNC
|
changeset-claim-re-read
|
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
…tail-section node (objectui#10485) Prose only; no code or assertion changes. - `.changeset/8626-detail-section-authored-node.md` (pending, same release): append an in-release paragraph. The registration now declares ten flat inputs (the eight plus `icon` and `hideEmpty`). Frontmatter untouched, no line deleted. - The comments in `DetailSection.tsx` (above `hideAllEmptySection`) and `renderers/record-details.tsx` (on `hideEmpty: s.hideEmpty ?? true`), and the header of `record-details.emptySectionDefault.test.tsx`: the `detail-section` node now declares `hideEmpty` and resolves no default. So an omitted key still keeps the skeleton there; only the premise changed, and the conclusion stands. Co-Authored-By: Claude <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01BA3nKVUwKQJf8DBxrSVtNC
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
1 participant
Fixes #10485
Clause-②: yes
Declares
hideEmptyon thedetail-sectionnode, following the objectui#9529 ruling (comment5724939941) that the triage (5828292064) reuses: declare a key the renderer already honours. The registration inpackages/plugin-detail/src/index.tsxgains{ name: 'hideEmpty', type: 'boolean', description }, andDETAIL_SECTION_NODE_INPUTSgains'hideEmpty', the same two edits PR objectui#10484 made foricon.DetailSection's hide logic is not touched: it already readssection.hideEmpty === true.What changed
packages/plugin-detail/src/index.tsxdetail-sectionregistration gainshideEmpty(boolean). Its description states the node's omitted default. NodefaultValue, since no other input of this node carries onepackages/plugin-detail/src/DetailSectionNode.tsxDETAIL_SECTION_NODE_INPUTSgains'hideEmpty', so the adapter folds it intosection. One comment phrase ("a ninth input") made count-freepackages/plugin-detail/src/__tests__/detailSectionAuthoredHideEmpty-10485.test.tsx.changeset/10485-detail-section-declares-hideempty.mdminoron@object-ui/plugin-detail. It names the one widened key and carries the Clause-② lineThe omitted default: one value for the node, so it is declared, not escalated
The triage asked me to stop if the
record:details/detail-viewdifference turned out to be a real semantic split rather than a default to declare. I measured all three paths on base0d5d66aee, each with a sibling control section that must render (it rendered every time). The node row comes from the new pin. The other two rows come from a throwaway probe, which is not committed:detail-viewthrough the realSchemaRenderer,record:detailsthroughRecordDetailsRenderer.hideEmptyomittedtruefalsedetail-sectionnode, baseunknown-prop, dropped by the fold)detail-sectionnode, this PRdetail-viewsectionsrecord:detailssectionshideEmpty: s.hideEmpty ?? trueon its own authored sections)trueandfalsemean the same thing on all three surfaces. Onlyrecord:detailsgives an omitted key a different meaning, and it does that by applying a default to its own authored sections, which never go through this node. On the node's own path nothing applies a default, andDetailSectionchecks=== true, so an omitted key has one meaning here: keep the section. That is exactly whatdetail-viewdoes. The description records that default, and nothing about the behaviour changes.Premises, measured on base
0d5d66aeebefore the editDETAIL_SECTION_NODE_INPUTSlives inDetailSectionNode.tsx,iconis in it, andhideEmptyis not. Held.hideEmpty. I checked with a manifest built the same waypage.tsxbuilds it: the result was codeunknown-prop, message "DETAIL-SECTION has no prop hideEmpty" (the tag name is spelled out to get past the body sanitizer). Held, with one correction to the mechanism. The validator does not drop anything. It only warns at authoring time. The drop happens in the fold:DetailSectionNodesends an undeclared key tohostPropsand not tosection, andDetailSectionignores that prop. SohideEmpty: trueon an all-empty section still drew its heading and skeleton (base: the pin'struerow is red with "expected span to be null").icon. Falsified: nothing to update, and PR objectui#10484 did not update them either. Each of the four console readers (registry-inputs-spec-parity,ga-honoured-inputs-author-reach,public-contract,component-input-union-specimens) has 0 hits fordetail-section, and they stay green.check:component-surface-parityis report-only and has no pin file.check:sdui-registration-pinspins registration KEYS derived from thesideEffectsarray. The script never readsinputs, and this diff adds no registration. The in-package readers stay green without changes: the finding(plugin-detail): everydetail-sectioninput is a FLAT prop the renderer never reads —DetailSectionreadssection.*only, and an authored node hands itsection === undefined#8626 fold-parity row (sorted, both directions), the finding(plugin-detail):DetailSectionrenderssection.icon, butdetail-section's authoring surface declares noicon— one affordance the renderer honours and no author can reach #9529 pin and thedetail-sectionstill offersheaderColoras a free-formstringinput, so the SDUI authoring surface invites values the published validator now refuses #6955 pin.sdui.manifest.json,sdui-intrinsics.d.tsorsdui-blocks.mdis checked in.git ls-filesfinds none of them; as a control, the same listing does findgen-manifest.ts.detail-sectionis also not inpublic-blocks.ts(0 hits), whilerecord:detailsis (1 hit). Nothing to regenerate.The pin:
detailSectionAuthoredHideEmpty-10485.test.tsx0d5d66aeed0f0649d8hideEmpty, in either polarityunknown-prophideEmptyas a declared BOOLEAN input ('yes'drawstype-mismatchnaminghideEmpty)unknown-propnamestill drawsunknown-prophideEmpty: truehides an all-empty section. A sibling node, identical except that it has no key, renders its heading and placeholder in the same renderhideEmpty: falsekeeps the heading and the label skeletonhideEmptykeeps the all-empty section (the declared default)Base:
Tests 3 failed | 3 passed (6). Head:Tests 6 passed (6). The last two rows are green on both sides on purpose. They pin the default this PR declares, so a later change of that default shows up as a red row and not as silence.Ablation: three legs, each proven on disk and restored by blob
Each mutation went through
node ../objectstack/scripts/ablation-replace.mjs --delete. The anchor had to hit exactly once, the blob had to change, and the restore isgit checkout HEAD --on an absolute path, verified by blob equality with HEAD and an emptygit diff HEAD. The wrapper has its owntrap ... EXIT INT TERM, which repeats that verification for both files. All legs ran on the committed implementationd0f0649d8. There is no build between mutation and assertion: the pin imports../indexrelatively, and the rootvitest.config.mtsaliases@object-ui/core,@object-ui/reactand@object-ui/sdui-parserto theirsrc. Expected directions were written down before each run, and every leg matched them.hideEmptyentry from the registration'sinputsbd23f817fto04615591bnamecontrol, all three render rows, the #9529 pinbd23f817fequals HEAD, diff empty'hideEmpty'fromDETAIL_SECTION_NODE_INPUTSd41d873c3to637368d62truerender row, #8626 fold parityfalseand omitted rowsd41d873c3equals HEAD, diff emptytruerender rowfalseand omitted rowsLegs A and C read
Tests 3 failed | 15 passed (18). Leg B read2 failed | 16 passed (18). All three ran over the #10485, #8626 and #9529 pins.Verification, at the final head
d0f0649d8pnpm exec vitest run packages/plugin-detail/plus the fourapps/console/src/__tests__readersTest Files 212 passed / 1 skipped (213),Tests 2301 passed / 8 skipped (2309). The readers on their own, verbose:Test Files 4 passed (4),Tests 240 passed (240), each file named in the outputpnpm exec turbo run build --filter='@object-ui/plugin-detail^...' --concurrency=2Tasks: 11 successful, 11 totalpnpm --filter @object-ui/plugin-detail type-checktsc -p tsconfig.test.json --listFileslists the new pin (1 hit)pnpm check:control-bytesOK, exit 0pnpm check:new-line-citations0 new citation(s), enforcement report-only -> exit 0node scripts/check-changeset-presence.mjs3 source file(s) of 1 released package(s) changed, and this change declares 1 changeset(s)node scripts/check-changeset-no-major.mjsNo changeset declares a major bumppnpm check:changeset-claimspackages/plugin-detail/src/index.tsx:9280-record-highlights-entry-icon-retired.md(therecord:highlightsfieldsdescription) andrecord-alert-cta-label-i18n-4998.md(record:alert'saction). I read both paragraphs and both are still true, because this diff touches neither registrationcheck:doc-types,check:registry-bare-names,check:icon-record-names,check:test-path-roots,check:pending-changeset-literals,check:vi-mock-specifiers,check:handler-key-reads,check:governed-queue-guard--teston the four paths answers NOT GOVERNEDpnpm check:component-surface-paritydetail-section.hideEmptyasinput-outside-keyset, next to eight pre-existingdetail-sectioninputs includingicon, for the same reason as those: the gate sees no named read throughDetailSectionNode, which folds by iterating the listpnpm check:sdui-registration-pinsNo console build to weigh(it needs a full console build). Left to CI. It reads registration keys, notinputsLint is narrowed, and I am declaring the narrowing.
eslint --no-inline-config --format jsonover the three touched source files: 3 files linted, 0 errors. Per-rule counts on the two edited files are equal to base (base read withgit show 0d5d66aee:PATHpiped toeslint --stdin --stdin-filename PATH):DetailSectionNode.tsxhas 1react-refresh/only-export-components;index.tsxhas 29react-refresh/only-export-componentsand 2@typescript-eslint/no-explicit-any. The new pin has 0 messages. The narrowing counts as a measurement because type-aware linting is not enabled:eslint --print-configonindex.tsxresolves an emptyparserOptions(noproject/projectService), so this diff cannot change the verdict on any file outside it. The repo-wide run belongs to CI.Acceptance notes
hideEmptyon the premise that the spec refuses it — the pin moved to spec 17.3.0 six days later and 17.3.0 DECLARES it, with a describe() promising the behaviour this repo removed #8603 design gave the node no default because it was "a section nobody could write the key on". Now the key can be written on the node in both polarities. Whether the node should therefore adoptrecord:details' hide-by-default is a product question. This PR does not take it up: the card forbids a behaviour change, and the spec'sdescribe()is scoped torecord:details. The node matchesdetail-view, the other non-spec surface.DetailSectionchecks=== true. Only their premise is out of date. I did not edit them, because they are outside the claimed surface. Each one is quoted by content:DetailSection.tsx, the comment abovehideAllEmptySection: "thedetail-sectionnode both synthesize one, and neither surface declareshideEmpty". Fix: drop the node from that sentence, or say it declares the key without a default.renderers/record-details.tsx, the comment onhideEmpty: s.hideEmpty ?? true: "Sections nobody can write it on stay out: the direct-fieldsfallback body below and thedetail-sectionnode". Same fix.renderers/__tests__/record-details.emptySectionDefault.test.tsx, the file header: "a section nobody could have written the key on — the direct-fieldsfallback body, thedetail-sectionnode". Same fix.packages/types/src/views.ts, theDetailViewSection.hideEmptydocblock: "This type is consumed by two authorable renderers". The node is now a third one, and it behaves likedetail-view(omitted keeps). This is an incomplete list, not a wrong statement about behaviour, and it ships in the.d.ts..changeset/8626-detail-section-authored-node.mdis unreleased and says in present tense that the registration "declares eight FLAT inputs". PR objectui#10484 already noted this wheniconmade the count nine, and it is ten now. I did not edit it, because it is outside the claimed surface.packages/plugin-detail/README.mdandcontent/docsdocument no input list fordetail-section, so no doc line became false. I added none, to stay inside the claimed surface.Dispatched by the
domain:uiseat #1; sessionhttps://claude.ai/code/session_01BA3nKVUwKQJf8DBxrSVtNC.Generated by Claude Code