Uh oh!
There was an error while loading. Please reload this page.
fix(fields): percent/progress 单元格让数值优先于装饰条,窄 chip 不再裁掉数值 (objectstack#5066) - #3927
Merged
Merged
Conversation
…#5066) percent 显示渲染器把「不可缩的 64px 装饰条」排在「可缩的数值文本」前面, 于是在带裁剪的窄容器里牺牲了错的那一半:`record:highlights` 的 chip 是 `basis-[9rem]`、随 chip 数量收缩到 `min-w-[7rem]`、并用 `truncate` 裁剪, 条(64px)加 gap(8px)吃掉内容盒,`truncate` 静默抹掉剩下的数值。库里存的 `33.33` 在 DOM 里是 `33%`,在屏上只剩 `3`(实测:裁剪盒 79px、文本节点 32px、 右溢出 25px),既无省略号,可访问名里也没有任何截断信号 —— 这是静默错数, 不是观感瑕疵。下游应用被迫把高亮项的渲染类型改写成 `number` 才能拿回数字, 代价是丢掉 `%` 与进度条。 现在按「数值是内容、条是装饰」反转优先级:数值 span 加 `shrink-0`,条的外层 改为 `min-w-0 shrink`,`w-16` 只作为它的首选宽度,容器一挤先把条挤没、数字 完整保留。行容器补 `min-w-0`,否则负空间传不到条上。 刻意没有用正文建议里的 `flex-1`:那会让条同时可以**变宽**,把每个宽表格单元 里的条拉长,改动一个本来没有 bug 的面。`w-16` 仍是上界,宽容器渲染与改动前 逐像素一致,只有收缩方向变了。内容宽度低于约 40px 时条已缩为 0,数值和其他 单行单元一样开始裁剪 —— 这就是「自闭环渲染器修法」能到的下界(chip 自身宽度 是记录高亮项数量的函数,高亮条上的 `@container` 看不到它)。 同文件相邻的 number 渲染器未动(objectstack#5067 的面)。 测试(jsdom 无布局引擎,故按 class 语义钉,同 objectui#3466 的 cell-truncation 做法): - `packages/fields/src/__tests__/PercentCellRenderer.test.tsx`:数值 `shrink-0`、 条 `min-w-0 shrink` 且非 `shrink-0`、无 `flex-1`/`grow`、DOM 文本仍是完整 格式化值(33% / 33.33% / 0.8 → 80% / progress 整数百分比)。 - `packages/plugin-detail/src/__tests__/RecordHighlightsRenderer.percentClip.test.tsx`: 从消费侧钉整条 authored metadata → chip → renderer 路径,并钉住 chip 自己 仍然 `truncate`(让位的是渲染器,不是 chip 的裁剪)。 Claude-Session: https://claude.ai/code/session_01GTRjn8xBqp75dk7kFupVRt
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
yinlianghui
commented
Aug 9, 2026
CollaboratorAuthor
✅ 验收通过(objectui 分片 PM,session 实物核验:base 验收要点:
范围外 finding objectstack#6950(chip truncate 对多元素渲染器的静默裁剪通用面)立单规范,冻结期不派,归后续分诊。 Generated by Claude Code |
yinlianghui
marked this pull request as ready for review
August 9, 2026 06:24
Uh oh!
There was an error while loading. Please reload this page.
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
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.
Fixesobjectstack-ai/objectstack#5066
现象与机制
percent 显示渲染器把「不可缩的 64px 装饰条」排在「可缩的数值文本」前面,于是在带裁剪的窄容器里牺牲了错的那一半。
record:highlights的 chip 是basis-[9rem]、随 chip 数量收缩到min-w-[7rem]、并用truncate裁剪:条(64px)加gap-2(8px)吃掉内容盒,truncate静默抹掉剩下的数值。库里存
33.33,DOM 里是33%,屏上只剩3—— issue 正文的量测:裁剪盒 79px、文本节点 32px、右溢出 25px,既无省略号,可访问名里也没有任何截断信号。这是静默错数,不是观感瑕疵;下游应用被迫把高亮项的渲染类型改写成number才能拿回数字,代价是丢掉%与进度条。改法(issue 正文建议一)
按「数值是内容、条是装饰」反转收缩优先级,只动
PercentCellRenderer:flex items-center gap-2flex min-w-0 items-center gap-2w-16 … shrink-0w-16 min-w-0 shrink …tabular-nums whitespace-nowrapshrink-0 tabular-nums whitespace-nowrapw-16从「硬宽度」降级为「首选宽度」,容器一挤先把条挤没、数字完整保留;行容器补min-w-0,否则负空间传不到条上。刻意没有用建议里的
flex-1。flex-1会让条同时可以变宽,把每个宽表格单元里的条拉长 —— 那是一个本来没有 bug 的面。w-16仍是上界(flex-grow保持 0),宽容器渲染与改动前一致,只有收缩方向变了。也没有叠加容器查询降级。 高亮条的
@container在 section 上,而 chip 的实际宽度是「这条记录有几个高亮项」的函数,section 的宽度查询看不到它 —— 容器查询在这个形态下无法表达真正的判据,加了只是换一种猜。内容宽度低于约 40px 时条已缩为 0、数值和其他单行单元一样开始裁剪,这就是自闭环渲染器修法能到的下界;这条残余与整个 chip 侧的通用机制已单独记为 objectstack-ai/objectstack#6950(observation-class,未入队)。同文件相邻的 number 渲染器未动(objectstack#5067 的面)。
测试
jsdom 没有布局引擎,像素测不了也不该造脆弱的像素测试,因此按 class 语义钉(与 objectui#3466 的
cell-truncation.test.tsx同一做法),再叠 DOM 文本断言:packages/fields/src/__tests__/PercentCellRenderer.test.tsx(7 例):正常宽度下条与数值都在;数值shrink-0;条w-16 min-w-0 shrink且非shrink-0;条无flex-1/grow/basis-(不许变宽);DOM 文本仍是完整格式化值(33%/precision: 2→33.33%/ 分数存储0.8→80%/progress整数百分比)。packages/plugin-detail/src/__tests__/RecordHighlightsRenderer.percentClip.test.tsx(4 例):从消费侧钉 authored metadata → chip → renderer 整条路径,含 7 个 chip 挤压最狠的形态;并钉住 chip 自己仍然truncate—— 让位的是渲染器,不是 chip 的裁剪。实跑证据:
反向验证(方向事先预判为红):把三处 class 还原成修前拼写后重跑两个新文件 ——
7 failed | 4 passed,失败点正是expect(value).toHaveClass('shrink-0')与expect(bar()).toHaveClass('w-16', 'min-w-0', 'shrink')。如实说明它证明了什么:class 名断言在修前拼写下必然红,所以这一跑证的是「测试真的接在被改代码上、查询非空转」,不是独立证明了布局后果 —— jsdom 评估不了布局。为把 class 名与真实 CSS 属性对上,另用仓内 Tailwind 4.3.3 编译过这几个 utility:w-16→width: calc(var(--spacing) * 16)、min-w-0→min-width: 0px、shrink→flex-shrink: 1、shrink-0→flex-shrink: 0。没有浏览器实证:本容器里没有任何 Chromium 二进制(
ms-playwright缓存为空、系统无 chromium/chrome),所以 issue 里那 25px 溢出没有在改后重新量过一遍,也没有截图。这一格如实留白,而不是拿别的东西凑。changeset:
.changeset/percent-cell-value-over-bar-os5066.md(@object-ui/fieldspatch)。🤖 Generated with Claude Code
https://claude.ai/code/session_01GTRjn8xBqp75dk7kFupVRt
Generated by Claude Code