plugin-calendar: calendar-view's colorMapping input is declared but inert — nothing reads it, so an authored colour map does nothing #4493

Measured while producing #4453's forwarded-prop census (every key calendar-view's renderer could carry, and where it lands). colorMapping is the one declared input with no read site at all.

The declaration

packages/plugin-calendar/src/calendar-view-renderer.tsx, the registry metadata:

{
  name: 'colorMapping',
  type: 'object',
  label: 'Color Mapping',
  description: 'Map field values to colors (e.g., {meeting: "blue", deadline: "red"})'
}

Published as calendar-view schema API in content/docs/plugins/plugin-calendar.mdx too (colorMapping?: Record< string, string >).

The read site

There is none. The renderer's event mapping takes the colour straight off the record:

const colorField = schema.colorField || 'color';
…
color: record[colorField],

grep -rn colorMapping packages/plugin-calendar/ returns exactly one hit: the declaration above. CalendarView has no such prop either — it resolves a colour from event.color (resolveEventColor). So an author who writes the documented colorMapping: { meeting: 'blue' } gets no mapping, no warning and no error: the raw field value is used as the colour, which for a picklist value like meeting is not a colour at all.

Before #4453 the key rode the renderer's {...props} spread into CalendarView, which does not declare it, so it was dropped there; after #4453 it is dropped at the renderer boundary. Neither is a behaviour change — the key has never done anything.

Same class as #4454

#4454 is the twin on the same widget (allowCreate declared, the handler it would drive built and never passed). Filed separately rather than as a sub-issue because the fixes are disjoint: allowCreate needs onAddClick wired, colorMapping needs a lookup in the events memo (or the declaration retired). Both are instances of "declared authorable surface with no implementation behind it", which is the enforce-or-remove question — worth deciding once for this widget rather than twice.

Fix shape (needs the same enforce-or-remove call)

1. Implement: color: colorMapping?.[record[colorField]] ?? record[colorField] in the events memo, plus a pin. Cheap, and it makes the documented example work.
2. Retire: drop the input and the doc line, on the grounds that no measured app authors it.

No pm:queue decision implied either way — recording the measurement so the next agent on this widget does not have to re-derive it.

Generated by Claude Code