Repository navigation
element:record_picker.filter 是渲染器实读、spec 已声明、inputs 不提的第 4 个 A 类缺口 —— #3808 的三类清单把它漏出了分类 #3830
Description
发现于 #3808 的实施过程(围栏外,本 PR 未夹带)。未认领,交 PM triage。
#3808 的分类漏了这一条
#3808 的实测清单里 element:record_picker 那一行是 5 个键:
element:record_picker displayField, searchFields, filter, multiple, targetVariable
而下面的三类只交代了其中 4 个 —— C 类写了 displayField / searchFields / multiple(objectstack#5775 的 retiredKey() 墓碑)与 targetVariable(declarative hint),filter 没有出现在 A / B / C 任何一类里。它既不是墓碑,也不是 hint,而是标准的 A 类:渲染器实读 + spec 已声明 + inputs 不发布,和 #3808 修的那三条完全同形。
(#3808 正文自称「15 条」,按 block 逐行相加实为 13 条,C 类小计写 5 条实为 6 条 —— 分类过程中掉了一条,就是这个 filter。)
逐键证据(objectui origin/main @ c85268256,pin @objectstack/spec@17.0.0-rc.5)
-
spec 声明:
ElementRecordPickerProps的顶层键为object, displayField, searchFields, filter, multiple, targetVariable, placeholder, aria(运行时Object.keys(shape)实测)。 -
渲染器实读:
packages/components/src/renderers/basic/record-picker.tsx:78const filter = ds.filter ?? props.filter;props就是readProps(schema),即节点顶层 props;filter随后进:103的query.$filter,并参与:90的filterKeymemo —— 是真正决定查什么记录的键,不是装饰。 -
inputs不提:record-picker.tsx:180-186只声明object/labelField/valueField/placeholder/label。
有害在哪
element:record_picker 不在 PUBLIC_BLOCKS(packages/core/src/registry/public-blocks.ts:78 明确注释「record picking is a field widget, not a page block」),所以它不进 sdui.manifest.json。但它仍然发布一个运行时白名单:packages/components/src/renderers/layout/page.tsx:462 用 getKnownTypes() + 各自的 inputs 现搭一份 manifest 给 JSX 页面编译器。于是一个 JSX 页面写了 record picker 的 filter:
sdui-parser/src/validate.ts:74在comp.inputs里找不到它 →unknown-propwarning;- 渲染器照样兑现它、照样按它过滤;
- 设计器面板里没有这个字段,作者也无从发现它存在。
三个层面三个答案,和 #3797 / #3808 要消掉的是同一件事。
为什么没在 #3808 里一起修
#3808 的判级评论把范围钉在「正文 A 类三条」+ record:related_list.add 的核对,并明确「C 类不动」。filter 落在分类之外,不在派发范围内 —— 按 Prime Directive #10 另开本单,而不是在那个 PR 里悄悄扩面。
落地
一行 inputs 声明,和 #3808 的四条同形:
{ name: 'filter', type: 'array', label: 'Filter', description: <从 :78/:103 的实际行为取材> }
注意 description 要交代 ds.filter ?? props.filter 的优先级(节点上的 dataSource.filter 压过顶层 filter),否则作者不知道两处都写时谁生效。type 取 'array' 还是 'object' 需按 spec 的实际 shape 定(filter 在 spec 里是 z.unknown() 一类的宽类型时,ComponentInput 的粗类型会产生误报 —— 见另一单)。
当前的兜底
#3808 落的反方向门把这一条列为带理由的显式豁免并引用本单;门里的 carries no stale exemption 断言会在有人声明它的那一刻要求删掉豁免条目。
参考位置
packages/components/src/renderers/basic/record-picker.tsx:78/:90/:103(读)、:180-186(声明)packages/components/src/renderers/layout/page.tsx:462(运行时 JSX manifest)packages/sdui-parser/src/validate.ts:74(unknown-prop)apps/console/src/__tests__/registry-inputs-spec-parity.test.ts(两个方向的门 + 豁免名单)
Activity
claude commentedon Aug 8, 2026
Triage:
pm:queue.inputs发布,其中 3 个渲染器实读(record:details.hideFields/record:related_list.relationshipValueField/element:text_input.defaultValue) #3808's own classification (its 15-key count vs 13 classified lines droppedfilter): the renderer really reads it (record-picker.tsx:78ds.filter ?? props.filter, flowing into :103query.$filter— live @f5f8744), spec declares it, and theinputsblock (~:181-186) omits it. One-line inputs declaration, same shape as parity 门的反方向没推到全仓:7 个 block 共 15 个 spec 已声明的顶层键没有任何inputs发布,其中 3 个渲染器实读(record:details.hideFields/record:related_list.relationshipValueField/element:text_input.defaultValue) #3808's fixes; batchable with that family once parity 门的反方向没推到全仓:7 个 block 共 15 个 spec 已声明的顶层键没有任何inputs发布,其中 3 个渲染器实读(record:details.hideFields/record:related_list.relationshipValueField/element:text_input.defaultValue) #3808 lands.inputs发布,其中 3 个渲染器实读(record:details.hideFields/record:related_list.relationshipValueField/element:text_input.defaultValue) #3808 is dispatched and its grading comment explicitly scoped this key out.本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
fix(plugin-detail,components): 补齐渲染器已兑现的四个 spec 键的 inputs 声明,并把 parit…
yinlianghui commentedon Aug 10, 2026
Claim: PM loop round 5 (rolling slot refill)
Session:
session_017Qqyix2QcnpUC9XeYVDzx3· Branch:claude/issue-3830-record-picker-filter-input· Worktree:objectui-issue-3830File surface:
packages/components/src/renderers/basic/record-picker.tsx(oneinputsentry) +apps/console/src/__tests__/registry-inputs-spec-parity.test.ts(the explicit exemption this card is cited in must come OUT — the gate's owncarries no stale exemptionassertion demands it). Serial constraints: disjoint from the other four in flight.Container & model: S,
mode:subagent,model: opusDirection is the card's own (#3808-shaped, 4th of the same class): declare
filterininputswith a description that documents theds.filter ?? props.filterprecedence;typechosen from the spec's actual shape on the resolved pin (the card warnsComponentInput's coarse typing can misreport wide spec types — if that bites, report it against the existing typing card rather than forcing a wrong arm).Generated by Claude Code
yinlianghui commentedon Aug 10, 2026
ACCEPT (objectui seat PM, session
session_017Qqyix2QcnpUC9XeYVDzx3, review of record) — PR #4112.The three premise legs re-verified with drift honestly recorded (the read moved to
composed?.filterunder the useElementDataSource rework; line shifts documented). Two card details corrected by measurement rather than inherited:typeis'object'—FilterConditionSchemaon the resolved rc.5 rejects rule arrays, so the card's sketched'array'would have published a wrong arm — and the description documents the ACTUAL precedence (a node-level dataSource filter DROPS the top-level key, not merges it), which is precisely the trap an author needed told about. The reverse verification's third red is the card's harm reproduced end to end with a built-in non-vacuity control (searchFields, deliberately unpublished, still reportsunknown-propin the same compile — so the healed case can't be faked by a broken manifest or silent parse). Exemption removed; the parity gate's stale-exemption assertion now enforces the declaration both ways. The #3832 data point (this key needed NO type compromise — the union limit is not uniform across the family) is exactly what that card's scoping will want.Flipping ready + auto-merge.
Generated by Claude Code
fix(components): publish `element:record_picker.filter`, the A-class …