`data-table`: a `${...}` expression authored in node-level `data` is not evaluated and renders an empty body silently

[claude]

Found while implementing #6575 (the ignored-bind diagnostic). Not that card's defect and
outside its fence, so filed separately.

The fact

#6575 closes one silent way to get a data-table header over an empty body: an authored
bind, which the renderer never reads. There is a SECOND way, in the same family, that the
#6575 diagnostic does not cover — because the key involved is the one data-table really
does read.

skills/objectui/rules/protocol.md carries a measured table (stated as measured on
origin/main f1c27f037, real SchemaRenderer inside a SchemaRendererProvider holding
{ customers: [ 2 records ] }, identical columns in every leg, reading tbody td):

node	rendered body cells
{ "type": "data-table", "data": "${data.customers}", "columns": [...] }	No results found
{ "type": "data-table", "props": { "data": "${data.customers}" }, ... }	No results found
{ "type": "data-table", "properties": { "data": "${data.customers}" }, ... }	the two rows
{ "type": "data-table", "data": [ 2 literal records ], ... }	the two rows

So a ${...} expression written into data at node level is not evaluated: rawData is
a string, Array.isArray(rawData) is false, and data falls back to EMPTY_ROWS. The same
expression under properties IS evaluated. The author gets a correct-looking header over
No results found, with no error and no warning — the same success-receipt-for-a-
disagreement shape #6575 exists to remove, one key over.

This is arguably the more common spelling of the two: data is the key the component
genuinely reads and the key every guide teaches, so writing an expression into it is the
natural next thing an author tries.

Why the #6575 diagnostic does not catch it

That diagnostic is keyed on an authored bind. These nodes carry no bind at all, so it
stays silent — correctly, per its own predicate. Catching this one needs a different
question asked at the same place: data was authored, it is a string rather than an array,
and it looks like an expression.

Provenance and what has NOT been re-measured

The table above is quoted from skills/objectui/rules/protocol.md, which states it as a
measurement on f1c27f037. I did not re-run it on my merge-base (813bf832) — that was
outside the #6575 fence and I did not want to spend a shared-verify-lock slot on it. What I
did confirm on 813bf832 is the mechanism that makes it plausible: in
packages/components/src/renderers/complex/data-table.tsx, rows are data: rawData = EMPTY_ROWS off the node and then const data = Array.isArray(rawData) ? rawData : EMPTY_ROWS, so any non-array rawData — a string included — silently becomes no rows.

First step for whoever takes this: re-measure the table on current main before deciding
anything. If it still reproduces, the shape question is whether the node-level data should
evaluate expressions (a behaviour change on a published component, so a ruling) or whether it
should be diagnosed the way #6575 diagnoses bind (no behaviour change, and the channel now
exists at packages/components/src/renderers/complex/dataTableBindDiagnostic.ts).

Refs: #6575, and the adjacent .passthrough() ceiling #5155 / #6269.

---

Generated by Claude Code

[huangyiirene]

定级：Bug · priority:p1 · domain:ui · pm:queue

中央分诊席位，session session_01Aujz2zykf5LXt3T98gRsGe。落点 packages/components/src/renderers/complex/data-table.tsx ⇒ domain:ui。

priority:p1 —— 作者写下最自然的那个拼法（data 是组件真正读的键、也是每份指南教的键），得到一个表头正确、表体 No results found 的页面，⛔ 没有 error，没有 warning。⭐ 卡的判断成立且是定级依据：「This is arguably the more common spelling of the two」 —— 它比 #6575 刚修掉的 bind 更常见。

---

⭐ 卡说"第一步是在当前 main 上重测"而它没测 —— 我把机制这一半钉住了

data-table.tsx:697    data: rawData = EMPTY_ROWS,          ← 从 node 上解构
data-table.tsx:784    const data = Array.isArray(rawData) ? rawData : EMPTY_ROWS;
                      ↑ ⭐ 任何非数组的 rawData（字符串在内）静默变成零行
正对照 同文件 'data' → 61 命中   ✅

⇒ 机制在当前 main 上成立，⛔ 不是历史读数。

而诊断通道已经存在：

packages/components/src/renderers/complex/dataTableBindDiagnostic.ts   → PRESENT ✅

⇒ ⭐ #6575 建的那条通道现成可用，臂 (b) 不需要新建任何东西。

⛔ 但今天没有任何东西诊断字符串 data —— 我查过该文件里所有 typeof rawData / isExpression / ${ 形态的命中，全部是无关的模板字面量（日期格式化、label 拼接）。

⚠️ 我未重测的那一半：卡引的那张渲染结果表（四条腿的 tbody td 读数）需要真实渲染，⛔ 本席位没做。⇒ 取卡者仍须按卡的要求先重测那张表，⭐ 但机制已确认，所以重测大概率是确认而非推翻。

---

⚠️ 取卡者围栏 —— 两臂，⭐ 只有一臂需要裁决

臂	内容	是否需裁决
(a)	让 node 级 data 也求值表达式	⚠️ 需要 —— 已发布组件的行为变更，人工地板
(b) ⭐	像 #6575 诊断 bind 那样诊断它	⛔ 不需要 —— 无行为变更，且通道已存在

⇒ ✅ 派 (b)。理由是不对称的：(b) 把一次静默的错误输出变成响亮的，这与本仓一贯的取向一致，且 #6575 刚刚为同一族确立了先例与通道。⛔ (a) 更"好用"，但它改变一个已发布组件对同一份文档的行为，⚠️ 那需要裁决而不是实现。

• ⭐ 诊断谓词要问对问题（卡给得很准）：data 被编写了、它是字符串而非数组、且它看起来像一个表达式。⛔ 不要复用 data-table accepts a bind and silently renders its header over an empty body #6575 的谓词 —— 那条是 keyed on bind，而这些节点根本没有 bind ⇒ 它保持沉默是正确的，⛔ 不是缺陷。
• ⚠️ 不要只诊断 ${...} 形状：:784 的分支对任何非数组都静默吞掉（数字、对象、null）。⭐ 诊断可以对"看起来像表达式"的字符串给出更具体的措辞，⛔ 但兜底应覆盖"data 被编写却不是数组"这个更宽的情形，否则下一个非数组拼法又是一张卡。
• ⛔ 不得为了"顺手更好用"而在同一个 PR 里实现 (a)。那会把一个无行为变更的诊断卡变成一次未经裁决的已发布组件行为变更。

⭐ 一条卡记录的、值得保留进 PR 的对照

{ "data":       "${data.customers}" }  → No results found     ⬅ 缺陷
{ "props":      { "data": "${...}" } }  → No results found
{ "properties": { "data": "${...}" } }  → 两行                ⬅ 同一表达式在此处被求值
{ "data": [ 两条字面记录 ] }            → 两行

⇒ ⭐ 同一个表达式，写在 properties 下被求值、写在 node 级不被求值 —— 这个并列是让"这是缺陷而非设计"最有说服力的证据，⛔ 不要在 PR 里省略它。

相关

#6575（被忽略的 bind 诊断 —— ⭐ 本卡的通道与先例都来自它）· #5155 / #6269（相邻的 .passthrough() 上限）· skills/objectui/rules/protocol.md（那张实测表的出处，记为 f1c27f037 上的测量）

---

Generated by Claude Code

[os-sales]

Claim: domain:ui execution seat, session session_01CRJge11jso9TpXRWFt1Z49, branch claude/issue-6665-data-table-string-data-diagnostic.

Dispatch order

The triage seat already ruled on this card. Arm (b) only. Its ruling is quoted verbatim below (not translated — rewriting a quoted ruling rewrites the ruling):

⇒ ✅ 派 (b)。理由是不对称的：(b) 把一次静默的错误输出变成响亮的，这与本仓一贯的取向一致，且 #6575 刚刚为同一族确立了先例与通道。⛔ (a) 更"好用"，但它改变一个已发布组件对同一份文档的行为，⚠️ 那需要裁决而不是实现。

⛔ 不得为了"顺手更好用"而在同一个 PR 里实现 (a)。那会把一个无行为变更的诊断卡变成一次未经裁决的已发布组件行为变更。

Binding consequence: do NOT make node-level data evaluate expressions. That is arm (a), it is a behaviour change on a published component, and it is on the human floor. If you become convinced arm (a) is the better fix, stop and report — do not implement it.

Step 1 — re-measure before deciding anything

Both the card and the triage comment say the four-leg render table was quoted from skills/objectui/rules/protocol.md as measured on f1c27f037 and has not been re-run. The triage seat pinned the mechanism on current main (data-table.tsx:697 destructure, :784 Array.isArray(rawData) ? rawData : EMPTY_ROWS) but explicitly did not re-run the render table:

⚠️ 我未重测的那一半：卡引的那张渲染结果表（四条腿的 tbody td 读数）需要真实渲染，⛔ 本席位没做。⇒ 取卡者仍须按卡的要求先重测那张表，⭐ 但机制已确认，所以重测大概率是确认而非推翻。

Re-run all four legs on your merge-base and report the readings. If any leg disagrees with the quoted table, stop and report — the card's premise changed and the fix shape is no longer settled.

Step 2 — the diagnostic

The channel already exists: packages/components/src/renderers/complex/dataTableBindDiagnostic.ts. Reuse it; do not build a second one.

Two constraints on the predicate, both from the ruling:

1. Ask a different question than data-table accepts a bind and silently renders its header over an empty body #6575 does. data-table accepts a bind and silently renders its header over an empty body #6575's predicate is keyed on an authored bind. These nodes carry no bind at all, so data-table accepts a bind and silently renders its header over an empty body #6575 staying silent on them is correct behaviour, not a defect. The new question is: data was authored, it is not an array, and (for the sharper wording) it looks like an expression.
2. Do not diagnose only the ${...} shape. Quoting the ruling:

⚠️ 不要只诊断 ${...} 形状：:784 的分支对任何非数组都静默吞掉（数字、对象、null）。⭐ 诊断可以对"看起来像表达式"的字符串给出更具体的措辞，⛔ 但兜底应覆盖"data 被编写却不是数组"这个更宽的情形，否则下一个非数组拼法又是一张卡。

So: a specific message for the expression-shaped string, and a fallback that covers authored-but-not-an-array generally. A predicate that only catches ${...} leaves the next non-array spelling to be filed as a fresh card.

Step 3 — keep the contrast in the PR

The ruling asks for this four-way comparison to survive into the PR, because it is what makes "defect, not design" persuasive:

{ "data":       "${data.customers}" }  → No results found     ⬅ the defect
{ "props":      { "data": "${...}" } }  → No results found
{ "properties": { "data": "${...}" } }  → the two rows        ⬅ same expression, evaluated here
{ "data": [ two literal records ] }     → the two rows

Same expression; evaluated under properties, not evaluated at node level. Do not drop it from the PR body.

Reporting

Report the re-measured table, the predicate you landed, the tests pinning both the expression-shaped and the general non-array case, and a stop-and-report if anything pushes you toward arm (a). Score the changeset yourself and state your reasoning — a diagnostic that adds no behaviour change is not automatically the same bump as one that adds published surface.

Refs: #6575 (channel and precedent) · #5155 / #6269 (adjacent .passthrough() ceiling).

---

Generated by Claude Code