test(console,sdui-parser): public block 声明的 objectName 必须真的到达数据层 (objectstack#4472) - #3146
Merged
Merged
Conversation
…ectstack#4472) framework 那边拿 sdui.manifest.json 去 diff spec 的 zod schema，而那道检查在叫 check:react-conformance 的时候，被它自己的文件头当成"确认组件 ACTUALLY implement 了 spec 声明的 props"。它做不到：diff 的两边都是**声明**，其中一边就是本仓库产出的 ——`manifestFromConfigs` 原样抄 `config.inputs`，看不到渲染器读不读。所以两边都声明、 没人读的 prop 在那边就是"一致"，objectstack#4413 的四个 record:* 块正是这么带着没人读 的 objectName/recordId 渲染成空白还一路绿灯的。 渲染路径上的证据只能从渲染路径上取，所以它落在这里。 apps/console/src/__tests__/public-block-binding-reach.test.tsx 把每个声明了 objectName 输入的 public block 经 SchemaRenderer 挂载（只给这一个绑定），provider 的 dataSource 是 一个记录所有调用的 Proxy，断言至少有一次调用带上了这个对象名。刻意窄：问的是"这个绑定 接上了吗"，不是"每个声明的 input 都被消费了吗"——后者在外部无启发式不可判定。每个没达标 的块都要在台账里写下理由，并且台账被**双向**断言等于实测集合：接上了就强制删条目，断了 就红。红的两个方向都验证过。 首跑：八个里五个到达，三个没到。record:related_list 是合理的——它必须先从 RecordContext 拿到父记录 id 才允许取数，否则会列出整张子表（@objectstack/spec 的 #4413 台账已写明）。 list-view 和 embeddable-form 不是，是同一形状的真缺陷：这两个注册都没有像 object-form / object-kanban / object-calendar 那样把 schema-renderer context 桥接到组件的 dataSource prop 上，而 SchemaRenderer 从不注入它，于是在注册表/SDUI 路径上两者都渲染空壳，同时把 objectName 声明为 **required**。单独开了 objectui#3144 而不是顺手改：给它们接上数据源会 改变所有裸挂载处的渲染结果。 manifestFromConfigs 和 scripts/dump-public-manifest.mjs 现在在自己的文档里写明：它们 emit 的是注册**声明**了什么，不是渲染器读了什么。 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01S3cP1eY1novcNhQEDBrSZD
|
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
❌ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
三处，都是上一提交暴露出来的：
1. `import React` 在自动 JSX runtime 下没被用到 → `tsc` TS6133。这一条同时炸了
Type Check 和 Bundle Analysis（后者的 `@object-ui/console build` 就是
`tsc && vite build`），两个红叉是同一个根因。
2. 探针的 dataSource 是 `new Proxy({}, …)`。任何 `{...dataSource}` 派生复制的都是
**自有可枚举属性**，而空 target 一个都没有——于是派生出来的源是个空壳，方法全被
悄悄剥掉。`embeddable-form` 恰好这么做（`{...dataSource, create: stub}`，为公开
表单中和写操作），所以它被记成"没到达数据层"，而那是探针造的假信号。改成用真实
自有属性播种，Proxy 只兜底未播种的键。
3. 订阅方法（`onMutation`）返回的是**退订函数**，块在卸载时会调用它。探针一律返回
Promise，于是卸载阶段 `unsub is not a function`——又一个与被测块无关的失败。
同时把挂载的 schema 从"objectName + required 输入"改成"每个声明的输入都给一个合理
值"，数组给非空。理由是 read 路径可能挂在**可选**输入上：`embeddable-form` 只有在
`config.fields` 非空时才构造它内层 ObjectForm 取数用的只读源；不给就等于没问过它，
却会被读成"没绑上"。数组给 `[]` 是同一个坑的另一面——空 `columns` 会让列表直接渲染
空态，压根不去取数。
`list-view` / `embeddable-form` 的台账条目因此更准了：已验证这两条是接线问题而不是
探针够不着——`embeddable-form` 在同样的挂载下，桥接一存在就立刻 `getObjectSchema`，
不存在就不会。objectui#3144 仍然单独修。
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01S3cP1eY1novcNhQEDBrSZD
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
os-zhuang
marked this pull request as ready for review
August 1, 2026 10:48
This was referenced Aug 1, 2026
Merged
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
objectstack#4472 的实现侧（方向 (b)）。配套 PR：objectstack-ai/objectstack#4491。发现的缺陷：#3144。
为什么这个测试该在这里
framework 拿
sdui.manifest.json去 diff spec 的 zod schema。那道检查叫check:react-conformance的时候，被它自己的文件头当成"确认组件 ACTUALLY implement 了 spec 声明的 props"。它做不到：diff 的两边都是声明，其中一边正是本仓库产出的——manifestFromConfigs原样抄config.inputs，看不到渲染器读不读。所以"两边都声明、没人读"的 prop 在那边就是一致。objectstack#4413 的四个
record:*块正是这么带着没人读的objectName/recordId渲染成空白，还一路绿灯到缺陷生命周期结束的。渲染路径上的证据只能从渲染路径上取，那是这里。这个测试问什么
apps/console/src/__tests__/public-block-binding-reach.test.tsx：每个声明了objectName输入的 public block，经SchemaRenderer挂载（只给这一个绑定 + 声明为 required 的输入），provider 的dataSource是一个记录所有调用的 Proxy——刻意窄：问的是"这个绑定接上了吗"，不是"每个声明的 input 都被消费了吗"（后者在外部无启发式不可判定）。到达 ≠ 渲染正确；"没到达"也有合理原因，所以每个没达标的块都要在台账里写下理由，并且台账被双向断言等于实测集合：接上了就强制删条目，断了就红。
红的两个方向都验证过：把
list-view从台账删掉 → 红；把object-form（实际到达）塞进台账 → 红。首跑结果
八个候选，五个到达数据层，三个没到：
record:related_list— 合理。它必须先从RecordContext拿到父记录 id 才允许取数，否则会列出整张子表。@objectstack/spec 的 objectstack#4413 台账已写明这一点。带理由记账。list-view/embeddable-form— 真缺陷，同一形状。两个注册都没有像object-form/object-kanban/object-calendar那样把 schema-renderer context 桥接到组件的dataSourceprop 上，而SchemaRenderer从不注入它。于是在注册表/SDUI 路径上两者都渲染空壳，同时把objectName声明为 required。→list-view/embeddable-form在 SDUI 注册表路径上拿不到 dataSource——声明为 required 的 objectName 是死的（objectstack#4413 同形） #3144没在本 PR 顺手修：给它们接上数据源会改变所有裸挂载处的渲染结果，那个 blast radius 值得单独 review。修好之后本测试会强制删掉对应台账条目——台账写的是"欠债"，不是"接受"。
顺带
manifestFromConfigs和scripts/dump-public-manifest.mjs现在在自己的文档里写明：它们 emit 的是注册声明了什么，不是渲染器读了什么。这是同一个谎言在生产端的那一半。验证
apps/console全套测试：2 files / 21 tests 全绿，13sno-explicit-anywarning，与该目录既有风格一致）🤖 Generated with Claude Code
https://claude.ai/code/session_01S3cP1eY1novcNhQEDBrSZD
Generated by Claude Code