Uh oh!
There was an error while loading. Please reload this page.
refactor(layout)!: delete PageNodeRenderer, the unregistered page-node renderer - #3225
Conversation
…e renderer
`@object-ui/layout`'s `PageNodeRenderer` (`./Page`, named `Page` before
objectui#3161 batch 7) was registered under no component key and imported
by nothing — a whole-repo grep finds zero call sites. It reached consumers
only through `export * from './Page'`, and `registerLayout()` already
carried a note telling the next reader NOT to register it: the `page` key
belongs to `@object-ui/components`'s `PageRenderer`, which is the renderer
that supports page types, named regions and `PageVariablesProvider`.
Removed under ADR-0049 (enforce-or-remove). Wiring it up instead would mean
two renderers for one key — a fork nothing is asking for — while leaving it
in place kept telling every reader that `@object-ui/layout` is where page
rendering lives. Its props were also `{ schema: PageNodeSchema; … } & any`,
and an intersection with `any` absorbs the whole type, so the signature
asserted nothing beyond "there is a schema" (objectui#3221 mechanism, fourth
spelling).
- delete `src/Page.tsx` and its barrel re-export; the `registerLayout` note
now records why no second `page` renderer belongs here
- add `page-node-renderer-stays-deleted.test.ts`: a source-level tombstone
so re-adding the export is a red test naming the decision, not a one-line
gap-fill (verified red by reintroducing the export)
- keep the batch-7 type pins, including the repo's only pin of
`PageNodeSchema['type'] === 'page'` — that is the wire key `PageRenderer`
answers to, and it outlives the component it was written beside
- `tsconfig.test.json` names `types: ["node"]` for the tombstone's source
scan, matching `packages/types/tsconfig.test.json`; it stays out of
`tsconfig.json` so package source still cannot compile against Node APIs
- README stopped documenting `<Page>` (an example already stale since the
batch-7 rename) and points at `PageRenderer` instead
Fixes#3223The latest updates on your projects. Learn more about Vercel for GitHub. |
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
os-zhuang
commented
Aug 2, 2026
范围外发现,已按 Prime Directive #10 单独立 issue、未在本 PR 修:
在 Generated by Claude Code |
os-zhuang
commented
Aug 2, 2026
PM 验收:ACCEPT,放行合并队列CI 15 项 13 绿 2 skipped、零红,已独立复核。 三件做对了、且值得记住的: 1. 先自证前提再动手。 派发时要求「若找到真实消费者就停下报告,而不是照令删除」——复查覆盖了 2. 没有只是删掉,而是让它「保持被删」。 把 3. 删组件,但不删它旁边那条 wire 契约的钉扎。 这是派发时划的线,执行到位了。 两处判断我都同意
顺带一条实测收获: Bundle 侧也印证了这是真死代码: 越界发现 #3226 已立案,我单独分诊(见该单)。 Generated by Claude Code |
Uh oh!
There was an error while loading. Please reload this page.
Fixes#3223
按 PM 在 issue 上的处置执行:删除,依据 ADR-0049(enforce-or-remove)。
动手前先自证前提
处置的前提是「没有任何调用点」。删之前把这条重新验证了一遍(全仓,含
apps/、content/docs/、skills/):PageNodeRenderer(全仓)packages/layout自己内部 + batch 7 的 changeset 表格from './Page'/from '../Page'export * from './Page'和 batch 7 测试的 importimport { … Page … } from '@object-ui/layout'(ts/tsx)@object-ui/layout的下游包app-shell与apps/console,只用到resolveHref/NavigationRenderer/AppShell结论:前提成立,没有真实消费者,可以删。
改了什么
src/Page.tsx及 barrel 里的export * from './Page'。 它注册在任何组件键之下都不存在、也没人 import,只通过 barrel 出现在公开 API 里;而registerLayout()里那条 NOTE 本来就在劝阻把page注册回来——page键归@object-ui/components的PageRenderer(它支持 record/home/app/utility 页面类型、命名 region 和PageVariablesProvider,被删的这个只画一个 header 加 children)。registerLayout()的 NOTE 补上了这段历史:一个键一个渲染器;page节点若需要 layout 侧的东西,加到 components 的渲染器里,不要在这里再开一个。page-node-renderer-stays-deleted.test.ts(墓碑测试)。 单纯删掉,下一个人重新加回export只是一行、而且看起来像在补缺口。这个测试让「加回来」直接变红并指向要先推翻的决定。它是包内源码级的禁令,不是对组合后 registry 的证明——注释里写明了这个边界。已用反向变更验证过它会红(把export加回去 + 建空Page.tsx,对应两条断言失败,随后已还原)。PageNodeSchema[ 'type' ]==='page'的断言。 这条钉的是 wire 契约——PageRenderer就是注册在这个键上的——所以它比被删的组件活得更久,不随组件一起删;测试头部的注释改写成了「重命名的对象已被删除,活下来的是分层拆分本身」。tsconfig.test.json显式声明types: ["node"],供墓碑测试的源码扫描使用,写法与packages/types/tsconfig.test.json一致;没有放进tsconfig.json,这样包源码依旧无法编译过 Node API(这个包是发到浏览器的)。import { Page, PageHeader } from '@object-ui/layout'的示例删掉了——它在 batch 7 改名之后其实已经过期(而且示例用的 children 写法与组件真实签名也对不上),换成PageHeader的用法,并指向PageRenderer。package.json的 description 同步改为AppShell, PageHeader, SidebarNav。PageNodeRendererfrom@object-ui/layout→PageRendererfrom@object-ui/components,并说明 schema 驱动的消费者不受影响({ type: 'page' }节点一直是经 registry 落到PageRenderer,从来不是这个导出)。顺带说明:props 那半边
issue 的第 2 点(
{ schema: PageNodeSchema; … } & any会把整个类型吸收掉)在这个方案下自动消失——类型随组件一起没了,不需要单独收敛。验证
第一次跑
type-check时墓碑测试的node:fs报 TS2591 —— 因为@object-ui/layout是会类型检查自己测试的包(有tsconfig.test.json),而packages/core里同类的*-stays-unwired测试之所以能直接用node:fs,是它的tsconfig.json把测试 exclude 掉了、根本没人编译。按packages/types的既有写法补types: ["node"]解决。范围
只动
packages/layout/(加一个.changeset/)。未触碰packages/app-shell/src/views/metadata-admin/(#3218)、packages/fields/(#3221)、scripts/check-spec-symbol-derivation.mjs。草稿状态,不自行合并;issue 也未关闭,交 PM review。
🤖 Generated with Claude Code
https://claude.ai/code/session_01PRJtkgUAaVG11FsJQbvZWA
Generated by Claude Code