Uh oh!
There was an error while loading. Please reload this page.
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_01S3cP1eY1novcNhQEDBrSZDContributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
os-zhuang
marked this pull request as ready for review
August 1, 2026 10:48
Uh oh!
There was an error while loading. Please reload this page.
This was referenced Aug 1, 2026
Merged
akarma-synetal pushed a commit
to akarma-synetal/objectui
that referenced
this pull request
Aug 2, 2026
…a 的渲染死循环 (objectstack-ai#3149) (objectstack-ai#3166) objectstack-ai#3146 的 binding-reach 探针按设计看不见 record:* 家族——它们从 RecordContextProvider 取数，裸挂载什么都不做，"没有数据调用"因此不说明任何 问题。而那恰好是 objectstack#4413 待过的地方：四个 block 声明了没人读的 objectName/recordId，在真实记录页上渲染空白，全程门禁皆绿。 record-block-record-reach.test.tsx 把 11 个 public record:* block 挂在 record context 下，绑两条不同的同对象记录各挂一次，问 DOM 或数据调用有没有 变化。两道探针的行为覆盖 14 → 24 / 57。 几个刻意的设计决定： - 两条记录而不是"绑 vs 不绑"：不绑的对照组少一层 provider，useId 整体偏移， 于是每个块都"有差异"——探针自己制造绿。 - 差分而不是"渲染非空"：后者对无视全部输入的块也恒为真，正是 objectstack-ai#3149 记下 不覆盖展示原语的理由；在这里加一道同样的东西是自毁。 - 仪器本身被断言：每个块用记录 A 再挂一次，要求逐字节相同。这条一旦失败， "A 和 B 不同"就不再等于"记录到达了输出"，整个文件的绿就是噪声。 - 崩溃按崩溃报：SchemaRenderer 会把渲染期抛错画成错误卡片，而崩了的块对两条 记录渲染同一张卡片，不单独断言就会落进"无差异"档、被读成关于绑定的结论。 - 无外网：这家族有块直接调 fetch('/api/v1/security/explain')，happy-dom 下 打到 localhost:3000——原本"能跑"只是因为连接被拒。现在立即 reject，URL 进 同一份调用台账。 结果 8 个响应、3 个入 NO_RECORD_REACH 台账。台账条目必须写明宿主路径，因为 "宿主供数"只在真有宿主供数时才是理由：record:discussion（DiscussionContext， RecordDetailView 挂）和 record:reference_rail（entries 由 buildDefaultPageSchema 注入）都核得住，record:activity 核不住——见 objectstack-ai#3165。 顺带修掉一个探针挂不起来的缺陷：useMetadata() 的"优雅兜底"每次调用都新建对象， provider 外每渲染一次 getItem 就换身份；useMetadataItem 把它放在 effect deps 里并 setState 一个全新对象 → 无限循环，同步到能把 render() 卡住。注释说它存在 是为了让 provider 外的单测能渲染，它恰恰让那些消费者挂不起来。改成冻结的模块级 单例，并让清空分支在已清空时 bail。 objectstack-ai#3149 第 2 层同时落地，但原方案不存在：57 个 public block 没有任何一个声明 recordId 输入（全仓库仅 view:detail / detail-view 两处，都不 public）——和 objectstack#4472 方向 (d) 同一类结果。代之以 record:related_list / record:line_items 的 required relationshipField + childObject 必须进子查询、 且 scope 到绑定的父记录，两个都成立。 Closesobjectstack-ai#3149 Claude-Session: https://claude.ai/code/session_01S3cP1eY1novcNhQEDBrSZD Co-authored-by: Claude <noreply@anthropic.com>
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 freeto 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