Uh oh!
There was an error while loading. Please reload this page.
fix(plugin-calendar): allowCreate works and colorMapping is retired — no declared-but-inert inputs left (#4454, #4493) - #4516
Merged
Conversation
…4454, #4493) `calendar-view` had two registry inputs declared and read by nobody — the one state ADR-0049's enforce-or-remove framing says must not persist. Measurement answered them in opposite directions. ENFORCE `allowCreate` (#4454). The handler it would gate was already built in the renderer (`handleAddClick`, dispatching `{ type: 'create', payload: {} }` on the widget's own `onAction` channel) and simply never passed, so `CalendarView` — which renders its "New event" button behind `onAddClick` — never saw a handler and the button never existed. An authored `allowCreate: true` now supplies the handler through the DECLARED `onAddClick` hatch rather than around it via a second prop, so the pre-existing React-host path keeps working and keeps its precedence (a host handler replaces the action dispatch). Only the boolean `true` turns it on: absent, `false` and off-type spellings all get the absent-key answer, which on this prop is what makes the button not render. REMOVE `colorMapping` (#4493). No read site anywhere — the renderer takes the colour straight off the record (`color: record[colorField]`) and `CalendarView` resolves it from `event.color` — and no measured app authors it, so the declaration is retired rather than given an implementation nobody pulled on. The docs line publishing it goes with it. Verified red-first: on the pre-fix tree the four new assertions that need the wiring/removal fail (no add affordance for an authored `allowCreate: true`; the registry still declares `colorMapping`), and the must-not-change cases are green on both sides. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_017Qqyix2QcnpUC9XeYVDzx3
The latest updates on your projects. Learn more about Vercel for GitHub. |
Contributor
✅ Console Performance Budget
📦 Bundle Size Report
Size Limits
|
yinlianghui
marked this pull request as ready for review
August 13, 2026 03:25
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
2 participants
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.
Closes#4454
Closes#4493
calendar-viewhad two registry inputs that were declared and read by nobody — the one state ADR-0049's enforce-or-remove framing says must not persist. Per the ruling on #4454, measurement decided them in opposite directions.#4454 —
allowCreate: ENFORCEMeasured first
What
CalendarViewrenders with and withoutonAddClick(CalendarView.tsx:333):(JSX tags elided above — GitHub's body sanitizer eats a bare
<followed by a letter.)Present, the header renders a New event button (accessible name
New event, the English default ofcalendar.newEvent). Absent, the button does not exist at all —undefinedis literally what suppresses the affordance.What
handleAddClickdoes, and whether it survived the #4453/#4494 consume-or-declare refactor. It is still correct — not stale. It dispatches throughdispatchAction, the narrowedonActionthe refactor introduced, exactly like its siblinghandleEventClick:So it dispatches
{ type: 'create', payload: {} }on the widget's own action channel, and an authoredonAction: 'NOT-A-FUNCTION'cannot turn the newly-live affordance back into #4453's uncaught handler crash. No STOP condition.The fix
The wiring goes through the declared
onAddClickhatch, not around it via a second prop.onAddClickis already one of the renderer's function-typedHOST_CALLBACKS(#4453), so a React host can switch the affordance on today;allowCreatesupplies that hatch's value for the SDUI path, where an author writing JSON can never produce a function.Same precedence rule as the
onEventClickline directly above it: a host handler replaces the action dispatch rather than running alongside it.Only the boolean
trueturns it on. Absent,false, and the off-type spellings JSON invites ('true',1, an object) all resolve toundefined— the absent-key answer every other resolver at this boundary gives, and on this prop the thing that makes the button not render. That is what keeps today's behaviour byte-identical for every node that never authored the key. Off-type input is not coerced (AGENTS.md #0.1).#4493 —
colorMapping: REMOVENo read site anywhere, confirmed by the filing and by #4492's census: the renderer's event mapping takes the colour straight off the record (
color: record[colorField]) andCalendarViewresolves a colour fromevent.color. An author writing the documentedcolorMapping: { meeting: 'blue' }got no mapping, no warning and no error — the raw field value was used as the colour, which for a picklist value likemeetingis not a colour at all.Retired rather than implemented: no measured app authors it, and a declared capability with no pull behind it is not worth building.
Swept in this PR:
packages/plugin-calendar/src/calendar-view-renderer.tsx— registryinputsdeclarationcontent/docs/plugins/plugin-calendar.mdx— "CalendarView Schema API" linepackages/plugin-calendar/README.mdexamples/schema-catalog/src/schemas/plugin-calendar/*.jsonfixturesA repo-wide
grep -rn colorMappingnow returns only the retirement comment, the new pin file, and the open-tail canary incalendar-view-renderer.propsContract.test.tsx(where the key now legitimately belongs — it is an ordinary unknown authored key).Red-first
New pin file
packages/plugin-calendar/src/calendar-view-renderer.inertInputs.test.tsx, run before the fix — 4 failed, 8 passed:The 8 green pre-fix are the must-not-change cases, green on both sides: absent
allowCreate, explicitfalse, the three off-type spellings, the pre-existing hostonAddClickpath, host-replaces-dispatch precedence, and "an authoredcolorMappingchanges nothing" (already true — the key never had a read site to lose, which is exactly why retiring it is not a behaviour change).After the fix, 12/12 green:
Green
Sibling pins from #4433 / #4452 / #4453 / #4492 all stay green inside that run (
eventsCollision,currentDate,propsContract,object-calendar-renderer.propsContract).Out of surface but verified unaffected, because turning an affordance on changes what reaches the DOM:
Changeset grade: minor
Measured both ways by building
@object-ui/plugin-calendaron this branch and again with the renderer reverted toorigin/main:Emitted
.d.ts: byte-identical.dist/index.d.tsdoes not move — it typesObjectCalendarRendererasReact.FC< { schema: any; [key: string]: any } >and never expressescalendar-view's authorable vocabulary. So "the.d.tsmoved" is false, and saying otherwise would have been the easy wrong answer here.Published registry surface: it moved. The vocabulary lives in the runtime registry metadata in
dist/index.js, andcalendar-view'sinputsarray loses a member —colorMappinggoes from 1 emitted declaration to 0:onAddClickoccurrences go 3 → 4 (the new wiring line).A declared input removed narrows the published authorable vocabulary, and a second declared input starts producing a user-visible affordance — minor, matching the #4403 / #4177 precedent. Never major (AGENTS.md §版本号策略: objectui's major follows
@objectstack, so even breaking changes here are minor).One changeset:
.changeset/calendar-inert-inputs-4454-4493.md,'@object-ui/plugin-calendar': minor, describing both changes.Surface
packages/plugin-calendar/**+ the onecolorMappingdocs mention + one changeset. Untouched: the DOM-leak sweep file,core/fields,console/**,content/docs/releases/. No overlap with the in-flight siblings (#4497, #4468, #4419, #4446, #4475).Generated by Claude Code