Repository navigation
plugin-calendar: calendar-view's allowCreate input is declared but inert — the handler it would drive is built and never passed #4454
Description
Observation-class, found while reading calendar-view-renderer.tsx for #4433. Nothing a user hits as a failure — the button simply never appears — so this carries finding and no pm:queue.
What is declared
packages/plugin-calendar/src/calendar-view-renderer.tsx registers the input:
{ name: 'allowCreate', type: 'boolean', label: 'Allow Create',
defaultValue: false,
description: 'Allow creating events by clicking on dates' }
and defaultProps sets allowCreate: false.
What consumes it
Nothing, on either side of the boundary:
-
CalendarViewPropsdoes not declareallowCreate, so the value rides the{...props}spread intoCalendarViewand is dropped there. -
The renderer builds the handler the flag would gate —
const handleAddClick = () => { onAction?.({ type: 'create', payload: {} }); };— and never passes it.
CalendarViewrenders its "New event" button behind{onAddClick && …}, so on the SDUI path that button never exists andhandleAddClickis unreachable dead code.
So the two halves of one feature are both present and never introduced to each other: an authorable key with no read site, and a handler with no caller.
Why it is filed and not fixed
Wiring onAddClick={handleAddClick} when allowCreate is true is a two-line change, but it turns a dormant declaration into a live capability that dispatches a create action — a capability question (does anything consume { type: 'create' } from this widget today?), not a bug fix, and outside #4433's scope. The alternative disposition is retirement: drop the input and the dead handler if nothing pulls on them. ADR-0049's enforce-or-remove framing applies either way — the current state, declared-but-unenforced, is the one state that should not persist.
Generated by Claude Code
Activity
yinlianghui commentedon Aug 13, 2026
CLAIM (paired with #4493, one dispatch, one PR) — session
session_017Qqyix2QcnpUC9XeYVDzx3, branchclaude/issue-4454-4493-calendar-inert-inputs.Ruling (delegated authority; open veto window): enforce-or-remove, opposite answers by measurement.
calendar-view'sallowCreateinput is declared but inert — the handler it would drive is built and never passed #4454allowCreate→ ENFORCE (wire it): the handler (handleAddClick) is BUILT and never passed — the intent existed and the wiring is the missing line. Wire it per the input's documented meaning:allowCreate: truepasses the add handler toCalendarView'sonAddClickhatch (now a declared function-typed hatch post-fix(plugin-calendar): calendar-view consumes or declares every forwarded prop — authored onEventClick can no longer crash a click (#4453) #4494). Default when ABSENT: measure what the component does with no handler (no affordance) and keep absent = today's behavior — only an explicitallowCreate: trueturns it on. Red-first: authoredallowCreate: true→ pre-fix no add affordance / handler never fires (capture); post-fix the affordance works. Must-not-change: absent/false byte-identical.calendar-view'scolorMappinginput is declared but inert — nothing reads it, so an authored colour map does nothing #4493colorMapping→ REMOVE (dead declaration, ADR-0049): no read site anywhere (confirmed twice — the filing and plugin-calendar:object-calendar/view:calendarspread the authored node into ObjectCalendar — authoredonDateClick/onNavigatethrow uncaught, authoredlocalekills the render #4492's census), no business pull on record. Delete the registry input declaration; sweep docs (content/docs/plugins/plugin-calendar.mdx, README) for mentions and remove them in the same PR; grade the removal per the export-surface precedent (registryinputsis authored-metadata-facing — if the emitted.d.ts/registry surface moves, minor with the removal described; else patch).Grading: one changeset,
@object-ui/plugin-calendar— expected minor (declared input removed = published vocabulary narrows, #4403/#4177 precedent; measure and say). Never major.Surface (mutual exclusion):
packages/plugin-calendar/**(renderer + registry declarations + tests) + docs mentions of colorMapping + one changeset. Calendar surface is free (nothing in flight). ⛔ NOT: the DOM-leak sweep file, core/fields, console/**,content/docs/releases/.Generated by Claude Code
Generated by Claude Code
fix(plugin-calendar): allowCreate works and colorMapping is retired (#…