Filed by the repo:objectui PM seat (round 6, session session_01RV6yuVCxymHYE16PL9vQkE) at the explicit instruction of #5236, which scoped itself to the broken example and said the registry question "should not be inferred from this one example… file the registry-normalisation question on its own if it is wanted." The dev who fixed #5236 (PR5244) reached the same conclusion independently and flagged it rather than implementing it.
The mechanism
packages/core/src/registry/Registry.ts resolves through plain Map lookups — this.components.get(namespacedType) / this.components.get(type) in get(), and the same in has() / getEntry(). There is no toLowerCase anywhere in packages/core/src/registry/, so lookup is exactly case-sensitive. Registered spellings are lowercase (page, card, text, button, …).
A node typed Page therefore misses page and falls through to the OBJUI-001 "Unknown component type" panel. Because the failure is per-node and the mistake is usually uniform across a document, the observed symptom is not one broken widget — it is the entire page rendering as error panels.
Two measured instances, both self-inflicted
The honest framing, and it cuts against acting: both instances are our own artifacts, not user reports. Each was fixed at its source, and neither is evidence that an outside author reached for PascalCase — only that we did, twice. Nobody should read "two instances" as measured user pull; it is measured authoring pull, from authors who had the registry in front of them.
The question
Should Registry lookup normalise case, so Page and page resolve to the same component?
- A. Leave it case-sensitive. One spelling is correct and the tooling already names the failure:
objectui check reports the unknown type, and (as of PR5245) it does so without the noise that hid it. Costs nothing, changes nothing, and keeps one key = one string. - B. Normalise at lookup.
Page and page become the same key everywhere, for every registered component, permanently. Removes a class of silent total-render failure and matches what a React-shaped mental model reaches for first. But it is a contract change across the whole stack: it makes two spellings valid forever, which the docs, the designer, sdui-intrinsics.d.ts and every registration site then have to mean consistently — and it makes a typo class (PAGE, pAge) resolve too, not merely the PascalCase convention. - C. Keep lookup strict, but make the failure teach. When a lookup misses and a case-insensitive match exists, the OBJUI-001 panel (and/or
objectui check) names it: "Unknown component type Page — did you mean page?" Keeps one canonical spelling while removing the part that actually hurts, which is that the failure is silent about the cause.
PM recommendation: C. It addresses what both measured instances actually cost — not that the wrong spelling failed, but that the failure gave the reader nothing to act on — without making a second spelling permanently valid. A does nothing about the recurrence; B pays a permanent contract cost to buy tolerance for a mistake C can simply name. If B is chosen, it should be decided as the contract change it is, not as a fix to an example.
This is on the human floor: B is a public-contract change to how every component key resolves, and even C touches published error text.
Refs #5236 / PR5244 (the example, fixed), #4061 (closed, same shape at the scaffold), #5127 (why the CLI warning was invisible until today), #5237 / PR5245 (the CLI's blocking arm).
Filed by the
repo:objectuiPM seat (round 6, sessionsession_01RV6yuVCxymHYE16PL9vQkE) at the explicit instruction of #5236, which scoped itself to the broken example and said the registry question "should not be inferred from this one example… file the registry-normalisation question on its own if it is wanted." The dev who fixed #5236 (PR5244) reached the same conclusion independently and flagged it rather than implementing it.The mechanism
packages/core/src/registry/Registry.tsresolves through plainMaplookups —this.components.get(namespacedType)/this.components.get(type)inget(), and the same inhas()/getEntry(). There is notoLowerCaseanywhere inpackages/core/src/registry/, so lookup is exactly case-sensitive. Registered spellings are lowercase (page,card,text,button, …).A node typed
Pagetherefore missespageand falls through to the OBJUI-001 "Unknown component type" panel. Because the failure is per-node and the mistake is usually uniform across a document, the observed symptom is not one broken widget — it is the entire page rendering as error panels.Two measured instances, both self-inflicted
objectui initscaffolds an app whose component registry is empty: generatedsrc/App.tsxnever imports@object-ui/components, so every node renders "Unknown component type" #4061 (closed) —objectui initscaffolded an app whose registry was empty, so every node rendered "Unknown component type". Fixed at the scaffold.Page/Card/Text/Button) and the registry lookup is case-sensitive #5236 (fixed in PR5244, this round) —examples/hello-world/schema.json, the smallest example in the repo and the first thing a newcomer opens, used PascalCase for all four node types. Every node rendered an error panel.objectui checkhad been reporting it all along, buried under 45 false positives frompackage.json(that wasobjectui check把每个 JSON 文件的根type都当成组件键判定,于是在任何 Node 工程里都对 package.json 的"type": "module"报未知类型 #5127).The honest framing, and it cuts against acting: both instances are our own artifacts, not user reports. Each was fixed at its source, and neither is evidence that an outside author reached for PascalCase — only that we did, twice. Nobody should read "two instances" as measured user pull; it is measured authoring pull, from authors who had the registry in front of them.
The question
Should
Registrylookup normalise case, soPageandpageresolve to the same component?objectui checkreports the unknown type, and (as of PR5245) it does so without the noise that hid it. Costs nothing, changes nothing, and keeps one key = one string.Pageandpagebecome the same key everywhere, for every registered component, permanently. Removes a class of silent total-render failure and matches what a React-shaped mental model reaches for first. But it is a contract change across the whole stack: it makes two spellings valid forever, which the docs, the designer,sdui-intrinsics.d.tsand every registration site then have to mean consistently — and it makes a typo class (PAGE,pAge) resolve too, not merely the PascalCase convention.objectui check) names it: "Unknown component typePage— did you meanpage?" Keeps one canonical spelling while removing the part that actually hurts, which is that the failure is silent about the cause.PM recommendation: C. It addresses what both measured instances actually cost — not that the wrong spelling failed, but that the failure gave the reader nothing to act on — without making a second spelling permanently valid. A does nothing about the recurrence; B pays a permanent contract cost to buy tolerance for a mistake C can simply name. If B is chosen, it should be decided as the contract change it is, not as a fix to an example.
This is on the human floor: B is a public-contract change to how every component key resolves, and even C touches published error text.
Refs #5236 / PR5244 (the example, fixed), #4061 (closed, same shape at the scaffold), #5127 (why the CLI warning was invisible until today), #5237 / PR5245 (the CLI's blocking arm).