Repository navigation
docs(types): ObjectChartSchema.series says its copy omits the per-series type and names chartType (objectui#10584) - #10768
Conversation
…ies type and names chartType
The zod mirror's `.describe()` on `ObjectChartSchema.series` called the
element "the arm ChartRendererProps declares", which stopped being true
member for member when that arm gained a per-series `type` (objectui#8086).
The description now says the copy is the `{ dataKey }` arm minus that
`type`, and names `chartType` as this node's per-series family override.
The TypeScript docblock says the omission is deliberate: taking `type` up
widens a published accept set and waits for a named producer. Wording
only; neither face's accept set moves.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_014fWVhLzhxR8qrFsJ5o8TYW
|
changeset-claim-re-read
|
✅ Console Performance Budget
The eager closure is every chunk the entry reaches through static imports — what the browser fetches and parses before the app renders. The entry chunk on its own is a small fraction of it. 📦 Bundle Size Report
Size Limits
|
|
Contract review ABSENT at head
Generated by Claude Code |
Contract reviewServed-tier: ① Derived judgmentsDiff read three-dot against objectui
② Semver level
③ Boundary flags
Implemented-by: VERDICT: PASS Rendered at tier by the director seat (summon #30 续) on the fetched head. Not a governed path; the landing pre-checks are met on this head (fresh PASS, CI green, no conflict), so Generated by Claude Code |
2 participants
Fixes #10584
Clause-②: no. The accept set does not move; this is a
.describeand docblock wording fix.yeswould be owed only if a named producer turned the card to widening, and then the dev stops and reports.What changed
packages/types/src/zod/objectql.zod.ts, theseriesmember ofObjectChartSchema: the.describe()no longer calls the element "the arm ChartRendererProps declares". It now says the copy is that{ dataKey }arm minus the arm's per-seriestype, which this copy does not declare, and that this copy's per-series family override ischartType(bar|line|area). A short comment above the member points at the TS twin for the ground.packages/types/src/objectql.ts, theseriesmember docblock: "this copy has not taken up" (which read as a lag) now says the omission is deliberate. Takingtypeup widens a published accept set and waits for a named producer that writes it on anobject-chartnode. The docblock also states what atypewritten anyway meets on each face (measured below)..changeset/10584-object-chart-series-describe.md:@object-ui/typespatch, since the.describe()string is published text.Both edits stay inside the
ObjectChartSchemablock, which is the file surface the claim names. No member, type or schema node changes.Premise check on
origin/mainat0896838deb.describe()said "the arm ChartRendererProps declares", while both arms ofChartRendererProps.schema.seriescarrytype?: string(objectui#8086). The TS docblock already named the omission ("every member of it excepttype... this copy has not taken up"). It now says the omission is deliberate.main, so this card's serial predecessors on the block have landed. The text was re-read onmain; the card's line numbers were not used.git grepfor the old describe text ("ChartRendererProps declares", "plotted series in the renderer", "has not taken up") matches only the two source files. No test, generated artifact or doc asserts the string, and no describe-verdict pin (INTERNAL/AUTHORABLEprefix) reads it.Stop condition: producer census for a per-series
typeonobject-chartNo producer found, so the work did not stop. Each reading has a control that hits:
type: 'object-chart'literal outside tests is in one of the relays: app-shellObjectView, plugin-viewObjectView, plugin-listListView, plugin-dashboardDashboardRendererandDashboardGridLayout. Each writesseriesas{ dataKey, label }, and none writestype. app-shell forwardsviewDef.chart.seriesverbatim, but the spec'sListChartConfigSchemais astrictObjectwith noseriesmember, so no conforming stored view carries one.chartConfigPresentationemits noseries. The only{ dataKey, type }literals are inplugin-chartstests of thechartrenderer.16c5a33):command-center.page.tswritesobject-chartnodes with noseries.renewals-pipeline.page.tswritesseries={[{ name: 'total', label: 'Invoice value' }]}on the ObjectChart react block: the{ name }arm, with notype.2f7b232): zeroobject-chart/ObjectCharthits, and zeroseriesin the 15 files undersrc/**/dashboardsandsrc/**/reports. Control: 34 charttype:literals across those files (five dashboards and two reports).What each face does with a per-series
type(measured, unchanged by this PR)Measured on the rebuilt
distat HEAD5dc9a71e02, with the same readings on the base build:ObjectChartSchema.safeParseofseries: [{ dataKey: 'margin', type: 'line' }]givessuccess: true, and the parsed series is[{"dataKey":"margin"}](the plainz.objectelement stripstype).{ dataKey, chartType: 'line' }keepschartType.{ label }alone is stillinvalid_typeatseries.0.dataKey. The base build gives the same result for each.tsc --stricton a literal typedObjectChartSchemagivesTS2353("'type' does not exist in type ...") for{ dataKey, type }and compiles{ dataKey, chartType }.distdiff, base vs head: the non-comment lines ofobjectql.d.tsare byte-identical.zod/objectql.zod.d.tsandzod/index.zod.d.tsdiffer only in union-member emission order on members this PR does not touch ("json" | "csv" | "xlsx"versus"json" | "xlsx" | "csv",positionandoperatorunions).zod/objectql.zod.jsdiffers only in the comment and the describe string.Verification (all on HEAD
5dc9a71e02, working tree clean)pnpm --filter @object-ui/types build:VERDICT command-exit 0. The dependency closure@object-ui/types^...has no build script, so it is empty.pnpm --filter @object-ui/types type-check:VERDICT command-exit 0(the script name is echoed astype-check).pnpm exec vitest run --maxWorkers=2 packages/types/:Test Files 245 passed (245),Tests 5327 passed (5327), exit 0.pnpm exec vitest run --maxWorkers=2 packages/plugin-charts/:Test Files 82 passed (82),Tests 964 passed (964), exit 0. Direction: the downstream consumer of@object-ui/typesnamed in the dispatch, run to confirm no fixture reads the describe string.objectql.ts/objectql.zod.tsfrom disk (app-shellrelayRungCensus-7559,chartConfigForward-7891; plugin-grid, plugin-kanban, plugin-tree and react census pins; and eightscripts/__tests__suites):Test Files 15 passed (15),Tests 602 passed (602), exit 0.--no-inline-config --format jsonon the two touched sources: exit 0, 2 files linted, 0 errors, and 35no-explicit-anywarnings, none on an edited line. Type-aware linting is not enabled (eslint.config.jshas noparserOptions.project/projectService), so this diff cannot move a verdict on any untouched file.node scripts/check-changeset-presence.mjs0 ·node scripts/check-changeset-no-major.mjs0 ·pnpm check:new-line-citations0 (VERDICT new-cross-file-line-citations: 0 new citation(s)) ·pnpm check:control-bytes0 ·pnpm check:spec-symbols0 ·pnpm check:test-path-roots0 ·pnpm check:changeset-claims0 (report-only). The pending objectui#8086 changeset's sentence "that copy of the internal arm does not carrytype, and its type is unchanged" is still true.pnpm check:component-surface-parity0 ·check:designer-field-key-parity0 ·check:doc-types0 ·check:installed-pin-claims0 ·check:handler-key-reads0 ·check:action-forward-parity0.node scripts/check-governed-queue-guard.mjs --teston the three paths:NOT GOVERNED.pnpm check:doc-examples, exit 2, prerequisite not met. It needs the dist of about 30 workspace packages, and that full build is CI's. This diff adds no@exampleblock or fence (zero added lines match), so the gate's population is unchanged.serieselement is a local copy ofChartRendererProps' arm and binds no@objectstack/specsymbol. The emittedobjectql.d.tsis non-comment byte-identical, so compiling against any spec cannot move.Acceptance notes
INTERNAL (relay-composed)prefix. It is objectui#7946's ruled verdict. The census above measured a channel it does not name: the ObjectChart react block. The spec'sreact-blocksentry hasschemaType: 'object-chart'andschema: ChartConfigSchema, and it listsseriesindataProps.ChartSeriesSchemais the{ name }arm and carries the per-seriestype. The showcase'srenewals-pipelinepage writesseries={[{ name, label }]}through that block onto anobject-chartnode, and the published zod face refuses that node (invalid_valueatchartType,invalid_typeatseries.0.dataKey). That belongs to the same family as objectui#10518 / objectui#10608 (theobject-chartcopy against the spec's ChartConfig contract), and it is reported to the seat rather than acted on here. It does not change this card's answer. On this node the spec's per-seriestyperides the{ name }arm, and the spec refusesdataKeyby name, so a{ dataKey, type }entry is not spec-authorable onobject-charteither.chartTypebecause it is this copy's declared per-series override. It is not a new authoring recommendation: the member staysINTERNAL.Refs: objectui#8086 · objectui#7946 · PR #10554
Generated by Claude Code