fix(plugin-calendar): ObjectCalendar's renderer consumes or declares every forwarded prop (#4492)

[yinlianghui]

Closes #4492.

The defect

One shared ObjectCalendarRenderer is registered under both plugin-calendar:object-calendar and view:calendar, and it ended in the same raw spread #4453 removed from the calendar-view renderer next door:

{(bound) => < ObjectCalendar schema={bound} dataSource={dataSource} {...props} />}

props is everything SchemaRenderer hands a registered widget: the node's authored keys, the contents of its props container, the injected runtime props and a host's trailing props — an unbounded set, spread onto a component whose props are a closed list. ObjectCalendarProps declares eight callbacks and a locale, so an authored value under any of those names landed on the declared prop, and an SDUI author writing JSON can never produce a function.

authored	gesture	pre-fix result
onDateClick: 'NOT-A-FUNCTION'	click an empty day cell	window.error: onDateClick is not a function
onNavigate: 'NOT-A-FUNCTION'	click Next period	window.error: onNavigate is not a function
locale: 'en_US'	render	SchemaErrorBoundary / Incorrect locale information provided

The two handler cases are worse than an error boundary: React does not route event-handler errors to SchemaErrorBoundary, so they surfaced as uncaught window errors while the calendar kept looking fine and that gesture was dead. onDateClick is additionally the unconditional shape — ObjectCalendar.tsx tests if (onDateClick) and a non-empty string is truthy — and onNavigate?.(date) guards nullish, not non-callable.

locale is fatal at render: toLocaleDateString('en_US') throws RangeError. The underscore spelling is the one a producer writes by accident.

The contract

The #4425 phase-2 ruling (option 1, whitelist bounded by declaration) applied to this renderer, exactly as #4453 / PR #4494 applied it to calendar-view. The forward set is now exactly ObjectCalendarProps, each key resolved to the type that prop declares; everything else is dropped. rest is READ for declared keys and never spread — that is the whole of the fix.

A deny-list could not close this: the leak is the open tail of author-supplied keys, which no enumeration can finish. This list is finishable because ObjectCalendarProps declares it — and dropping the tail costs nothing, because ObjectCalendar destructures a closed list and reads no other prop. That is the census proof that nothing is lost.

Both registrations share one implementation, so one fix closes object-calendar and view:calendar together; both are pinned.

Census — every key the old spread could carry

Injected or forwarded by SchemaRenderer:

key	disposition
schema	consumed — replaced by the gate's bound schema
className (merged node className + scope class)	consumed then forwarded
events, the props container, properties, bind	dropped
ariaLabel / ariaDescribedBy / role and the resolved aria-*	dropped — unchanged from today, where the component ignored them
disabled (always __disabled or undefined)	dropped
data-obj-id, data-obj-type, data-obj-schema-invalid, data-debug-*	dropped
id, name, label, description, … (BaseSchema keys)	dropped
the OPEN TAIL — any authored key at all	dropped; the half a deny-list structurally cannot close

Declared registry inputs (both registrations declare the same two), plus the flat spelling ObjectView / ListView emit — all consumed through schema, never through the props channel, so none needs a forward:

input	disposition
objectName	consumed via schema.objectName
calendar	consumed via getCalendarConfig(schema)
startDateField, endDateField, titleField, colorField, allDayField, defaultView, filter, sort	consumed via schema

Declared ObjectCalendarProps — all 14 audited:

key	forwarded when
schema	always, as the gate's bound schema
dataSource	consumed from useSchemaContext(); a host-passed adapter still wins, now validated by its call surface (find)
className	consumed then forwarded
data	the value is an array (the parent pre-fetch path ObjectView uses)
loading	the value is a boolean
onEventClick, onRowClick, onDateClick, onEdit, onDelete, onNavigate, onViewChange, onEventDrop	the value is a function
locale	the value is a string Intl.getCanonicalLocales accepts

Three census notes:

• No numeric knobs exist on this component. CalendarView has slotMinutes; ObjectCalendarProps declares no numeric key, so that resolver has no counterpart here — census-confirmed rather than assumed.
• onEdit / onDelete are declared but never destructured by ObjectCalendar (the record drawer builds its own edit/delete from dataSource), so forwarding them is inert. They are listed anyway because the hatch is bounded by the DECLARATION; a key that is declared, inert and silently dropped would be a second, quieter contract. Behaviour is identical before and after: a value under either name does nothing.
• dataSource is two different things sharing one name — the spec's element dataSource BINDING and the runtime ADAPTER. SchemaRenderer already strips the binding off the node, and deliberately preserves a host's explicit React dataSource prop; that host path is kept at its old precedence, but type-checked, so a binding-shaped object arriving through the props container falls back to the context adapter instead of shadowing it (the shape behind dataSource.find is not a function, objectstack#5576).

Red-first (verbatim)

packages/plugin-calendar/src/object-calendar-renderer.propsContract.test.tsx run against the pre-fix renderer (git checkout origin/main -- index.tsx, restored after): 9 failed | 10 passed (19) — the 9 new pins red, the 10 must-not-change pins green on BOTH sides.

Handler errors do not reach SchemaErrorBoundary, so the pins capture the window error event, a synchronous throw out of fireEvent, and console.error, and assert on the UNION — the environment does not get to decide the verdict by moving the report between channels.

FAIL … > drops an authored `onDateClick` string written on the NODE — the day-cell click is a no-op
AssertionError: expected [ …(2) ] to deeply equal []
+   "window.error: onDateClick is not a function",
+   "console.error: onDateClick is not a function",

FAIL … > drops an authored `onDateClick` string written in the `props` CONTAINER
+   "window.error: onDateClick is not a function",
+   "console.error: onDateClick is not a function",

FAIL … > drops an authored `onNavigate` string written on the NODE — the Next-period click is a no-op
+   "window.error: onNavigate is not a function",
+   "console.error: onNavigate is not a function",

FAIL … > drops an authored `onNavigate` string written in the `props` CONTAINER
+   "window.error: onNavigate is not a function",
+   "console.error: onNavigate is not a function",

FAIL … > renders through an authored `locale` that `Intl` rejects, instead of throwing out of render
AssertionError: expected null not to be null
           failed to render
          Incorrect locale information provided

FAIL … > renders through a rejected `locale` written in the `props` CONTAINER
          Incorrect locale information provided

FAIL … > drops an authored `onEventClick` string when navigation is NOT an overlay — the reachability the filing left open
+   "window.error: onEventClick is not a function",
+   "console.error: onEventClick is not a function",

FAIL … > `view:calendar` — the twin registration — drops the same authored `onDateClick` string
+   "window.error: onDateClick is not a function",
+   "console.error: onDateClick is not a function",

FAIL … > `view:calendar` renders through a `locale` that `Intl` rejects
          Incorrect locale information provided

Post-fix: all 19 green. Both authoring channels are pinned for every authored case (the node's own key and the props container), per #4452's lesson, and both registrations are pinned so a future change that fixes only one cannot pass.

onEventClick — provenance, stated honestly

The filing recorded that it could not reproduce a crash on onEventClick: ObjectCalendar calls the parent handler only when the local navigation is not an overlay (if (!navIsOverlay)), and the default navigation config is a drawer, so the call was skipped. The filing claimed the exposure in the code path but not its reachability.

This PR does not restate that claim — it splits the key into two cases and reports what each one measured:

1. Default (drawer) navigation — a contract-only pin: the authored string is dropped and the click is clean. Green on both sides by construction, and it deliberately claims no pre-fix crash. This is the filing's configuration, reproduced faithfully.
2. Non-overlay navigation — navigation: { mode: 'none' } is the smallest non-overlay config (navIsOverlay false, and useNavigationOverlay's own handleClick returns early for none, so no router is involved). MEASURED red pre-fix, verbatim window.error: onEventClick is not a function.

So the answer to the filing's open question is: the exposure is real and reachable, and reachability depends on the navigation mode exactly as the filing suspected. That is this card's own new measurement, not a promotion of the filing's unproven claim.

Must-not-change (green on both sides)

• a host FUNCTION onDateClick / onNavigate through SchemaRenderer's trailing props still fires, with a real Date payload;
• a FUNCTION authored on the node (a programmatic host) still fires — the hatch discriminates on the value's TYPE, not on the channel;
• ListView's onRowClick — a real function on a real node key, from ListView.tsx's baseProps — still reaches the component;
• a host FUNCTION onEventClick still fires when navigation is not an overlay;
• a well-formed locale (de-DE) still reaches the component (asserted on German month names in the header);
• both registrations still render a normal calendar with no authored extras;
• the declared data / loading pre-fetch path still reaches the component — registration.test.tsx already pinned the renderer-level passthrough, which is why data and loading are forwarded at their declared types rather than dropped;
• the node className still lands on the calendar container;
• the fix(plugin-calendar): calendar-view consumes or declares every forwarded prop — authored onEventClick can no longer crash a click (#4453) #4494, plugin-calendar: authoring events on a calendar-view node crashes the component — the SDUI action object overwrites the computed CalendarEvent array #4433 and plugin-calendar: authoring currentDate as the ISO string its own registry input documents crashes calendar-view #4452 sibling pin files all stay green.

Verification

pnpm --workspace-concurrency=2 --filter '@object-ui/plugin-calendar^...' build   # dependency closure first
tsc --noEmit && tsc -p tsconfig.test.json                       # plugin-calendar, both: 0 errors
vitest run packages/plugin-calendar packages/app-shell/src/__tests__/widget-dom-leak-sweep.test.tsx
    -> Test Files 9 passed (9) | Tests 104 passed (104)
vitest run packages/app-shell/src/__tests__/widget-dom-leak-sweep.test.tsx --reporter=verbose
    -> 39 passed; plugin-calendar:object-calendar / view:calendar / :calendar-view all green
eslint packages/plugin-calendar        -> 0 errors (109 pre-existing warnings, none in the changed files)
node scripts/check-control-bytes.mjs   -> OK (4206 tracked text files)

The DOM-leak sweep is #4432's surface and #4434 owns its judge internals — it was not edited, only run read-only to confirm the calendar targets stay green. Rebased onto current main (3fc2971b5) and re-verified there.

Emitted .d.ts measured both ways (build on this branch vs. with the renderer reverted to origin/main): packages/plugin-calendar/dist/index.d.ts is byte-identical. ObjectCalendarRenderer is an exported symbol, so its props type is published surface — it keeps its exact annotation, because what the renderer accepts is genuinely unchanged (an open record); only what it forwards narrows. The published surface does not grow, so this is a patch, not a minor.

Out of scope, census-confirmed only

• plugin-calendar: calendar-view's colorMapping input is declared but inert — nothing reads it, so an authored colour map does nothing #4493 (colorMapping inert) and plugin-calendar: calendar-view's allowCreate input is declared but inert — the handler it would drive is built and never passed #4454 (allowCreate inert) are calendar-view registry inputs. Neither is a declared input of object-calendar / view:calendar, and neither appears in ObjectCalendar.tsx, CalendarView.tsx or this renderer at all — on this surface they are part of the open tail and were already inert. Confirmed by this census, deliberately not fixed here; they stay their own pooled pair.

---

Generated by Claude Code

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment

Project	Deployment	Actions	Updated (UTC)
objectui	Ignored		Aug 12, 2026 9:53pm

[github-actions]

✅ Console Performance Budget

Metric	Value	Budget
Main entry (gzip)	24.7 KB	350 KB
Entry file	index-sRluX94z.js	—
Status	PASS	—

---

📦 Bundle Size Report

Package	Size	Gzipped
app-shell (index.js)	9.56KB	3.59KB
app-shell (runtime-config.js)	7.42KB	2.32KB
app-shell (types.js)	0.01KB	0.04KB
app-shell (urlParams.js)	8.92KB	3.41KB
auth (AuthContext.js)	0.31KB	0.24KB
auth (AuthGuard.js)	1.17KB	0.53KB
auth (AuthProvider.js)	22.10KB	4.37KB
auth (AuthShell.js)	3.49KB	1.40KB
auth (ForgotPasswordForm.js)	12.21KB	3.45KB
auth (LoginForm.js)	18.13KB	5.39KB
auth (PreviewBanner.js)	0.90KB	0.50KB
auth (RegisterForm.js)	6.64KB	2.21KB
auth (SocialSignInButtons.js)	9.60KB	3.89KB
auth (UserMenu.js)	3.40KB	1.22KB
auth (auth-gate-events.js)	1.29KB	0.66KB
auth (authStyles.js)	5.04KB	1.72KB
auth (createAuthClient.js)	36.76KB	9.60KB
auth (createAuthenticatedFetch.js)	4.37KB	1.69KB
auth (index.js)	2.35KB	1.07KB
auth (org-roles.js)	6.66KB	2.78KB
auth (phone-identifier.js)	1.11KB	0.66KB
auth (types.js)	0.59KB	0.35KB
auth (useAuth.js)	4.91KB	0.87KB
auth (useIsWorkspaceAdmin.js)	1.61KB	0.85KB
collaboration (CommentThread.js)	26.07KB	7.56KB
collaboration (LiveCursors.js)	3.17KB	1.27KB
collaboration (PresenceAvatars.js)	6.49KB	2.64KB
collaboration (PresenceProvider.js)	2.79KB	1.13KB
collaboration (index.js)	1.65KB	0.73KB
collaboration (useCollaborationTranslation.js)	6.05KB	2.52KB
collaboration (useCommentSearch.js)	1.98KB	0.88KB
collaboration (useConflictResolution.js)	7.75KB	1.86KB
collaboration (useMentionNotifications.js)	1.81KB	0.68KB
collaboration (usePresence.js)	6.33KB	1.84KB
collaboration (useRealtimeSubscription.js)	7.91KB	2.01KB
components (index.js)	489.32KB	108.45KB
core (index.js)	3.37KB	1.34KB
create-plugin (index.js)	10.08KB	3.26KB
data-objectstack (index.js)	153.79KB	41.35KB
fields (index.js)	230.07KB	57.07KB
i18n (LocalizationContext.js)	1.76KB	0.96KB
i18n (currency.js)	1.22KB	0.64KB
i18n (i18n.js)	4.32KB	1.77KB
i18n (index.js)	3.35KB	1.38KB
i18n (pickLocalized.js)	3.69KB	1.73KB
i18n (provider.js)	23.12KB	7.62KB
i18n (useDisplayLocale.js)	2.33KB	1.20KB
i18n (useObjectLabel.js)	27.59KB	6.63KB
i18n (useSafeTranslation.js)	7.77KB	3.13KB
layout (index.js)	38.98KB	10.85KB
mobile (MobileProvider.js)	0.92KB	0.49KB
mobile (ResponsiveContainer.js)	0.94KB	0.38KB
mobile (breakpoints.js)	1.51KB	0.70KB
mobile (createOfflineDataSource.js)	5.61KB	1.74KB
mobile (index.js)	1.50KB	0.62KB
mobile (offlineQueue.js)	3.91KB	1.35KB
mobile (pwa.js)	0.97KB	0.49KB
mobile (serviceWorker.js)	1.48KB	0.62KB
mobile (serviceWorkerSource.js)	3.41KB	1.48KB
mobile (useBreakpoint.js)	1.54KB	0.65KB
mobile (useGesture.js)	6.96KB	1.98KB
mobile (useOfflineSync.js)	1.99KB	0.72KB
mobile (usePullToRefresh.js)	2.53KB	0.85KB
mobile (useResponsive.js)	0.71KB	0.42KB
mobile (useResponsiveConfig.js)	1.36KB	0.63KB
mobile (useSpecGesture.js)	4.32KB	1.64KB
mobile (useTouchTarget.js)	1.01KB	0.54KB
permissions (MePermissionsProvider.js)	8.75KB	3.06KB
permissions (PermissionContext.js)	0.31KB	0.25KB
permissions (PermissionGuard.js)	0.89KB	0.45KB
permissions (PermissionProvider.js)	3.67KB	1.12KB
permissions (evaluator.js)	4.41KB	1.44KB
permissions (index.js)	0.91KB	0.41KB
permissions (store.js)	0.91KB	0.42KB
permissions (useFieldPermissions.js)	1.28KB	0.52KB
permissions (usePermissions.js)	1.55KB	0.71KB
plugin-ai (index.js)	15.75KB	3.80KB
plugin-calendar (index.js)	46.86KB	12.91KB
plugin-charts (index.js)	62.07KB	17.65KB
plugin-chatbot (index.js)	181.21KB	43.14KB
plugin-dashboard (index.js)	120.85KB	31.41KB
plugin-designer (index.js)	212.58KB	42.83KB
plugin-detail (index.js)	239.03KB	59.77KB
plugin-editor (index.js)	2.46KB	1.10KB
plugin-form (index.js)	114.58KB	27.68KB
plugin-gantt (index.js)	164.14KB	39.98KB
plugin-grid (index.js)	188.13KB	50.00KB
plugin-kanban (index.js)	48.62KB	13.42KB
plugin-list (index.js)	111.07KB	27.08KB
plugin-map (index.js)	18.16KB	5.81KB
plugin-markdown (index.js)	13.72KB	4.69KB
plugin-report (index.js)	41.16KB	10.96KB
plugin-timeline (index.js)	26.21KB	7.52KB
plugin-tree (index.js)	8.50KB	2.88KB
plugin-view (index.js)	84.08KB	20.55KB
providers (DataSourceProvider.js)	0.75KB	0.39KB
providers (MetadataProvider.js)	1.37KB	0.59KB
providers (ThemeProvider.js)	1.90KB	0.85KB
providers (UploadProvider.js)	11.71KB	3.53KB
providers (index.js)	0.44KB	0.22KB
providers (types.js)	0.01KB	0.04KB
react-runtime (index.js)	5.67KB	2.37KB
react (LazyPluginLoader.js)	3.77KB	1.33KB
react (SchemaRenderer.js)	23.73KB	7.96KB
react (data-invalidation.js)	5.05KB	2.08KB
react (index.js)	1.23KB	0.66KB
react (spec-input.js)	0.20KB	0.18KB
sdui-parser (codegen.js)	4.09KB	1.74KB
sdui-parser (index.js)	4.47KB	2.03KB
sdui-parser (parse.js)	10.04KB	2.82KB
sdui-parser (types.js)	0.29KB	0.24KB
sdui-parser (validate.js)	4.69KB	1.48KB
types (ai.js)	0.20KB	0.17KB
types (api-types.js)	0.20KB	0.18KB
types (app.js)	2.87KB	0.99KB
types (base.js)	0.20KB	0.18KB
types (blocks.js)	0.20KB	0.18KB
types (complex.js)	0.20KB	0.18KB
types (crud.js)	0.20KB	0.18KB
types (dashboard-filter-alias.js)	6.23KB	2.74KB
types (data-display.js)	0.20KB	0.18KB
types (data-protocol.js)	0.20KB	0.19KB
types (data.js)	0.20KB	0.18KB
types (designer.js)	1.87KB	0.85KB
types (disclosure.js)	0.20KB	0.18KB
types (error-code.js)	1.54KB	0.88KB
types (feedback.js)	0.20KB	0.18KB
types (field-types.js)	0.20KB	0.18KB
types (form.js)	0.20KB	0.18KB
types (http-retry.js)	4.32KB	2.02KB
types (index.js)	3.05KB	1.52KB
types (layout.js)	0.20KB	0.18KB
types (managed-by.js)	0.19KB	0.18KB
types (mobile.js)	2.59KB	1.31KB
types (navigation.js)	0.20KB	0.18KB
types (objectql.js)	0.20KB	0.18KB
types (overlay.js)	0.20KB	0.18KB
types (permissions.js)	0.20KB	0.18KB
types (plugin-scope.js)	0.20KB	0.18KB
types (record-components.js)	0.20KB	0.19KB
types (record-semantics.js)	1.28KB	0.67KB
types (registry.js)	0.20KB	0.18KB
types (reports.js)	0.20KB	0.18KB
types (spec-report.js)	5.05KB	1.93KB
types (system-fields.js)	3.33KB	1.54KB
types (theme.js)	0.20KB	0.18KB
types (ui-action.js)	3.40KB	1.71KB
types (views.js)	0.20KB	0.18KB
types (widget.js)	0.20KB	0.18KB

Size Limits

• ✅ Core packages should be < 50KB gzipped
• ✅ Component packages should be < 100KB gzipped
• ⚠️ Plugin packages should be < 150KB gzipped

[yinlianghui]

ACCEPT — step-7 复核 by PM session session_017Qqyix2QcnpUC9XeYVDzx3 (focused review).

• The census deviation is the ruling correctly outranking its own paraphrase: data/loading/dataSource are declared props with live read sites, and dropping them would have broken the existing no-double-fetch pin — forwarding them TYPE-CHECKED applies fix(plugin-calendar): calendar-view consumes or declares every forwarded prop — authored onEventClick can no longer crash a click (#4453) #4494's actual principle (the forward set is exactly the declared interface, each key at its declared type). The dataSource treatment additionally closes the props-container-shadowing shape while measuring that no live path moves.
• The onEventClick provenance handling is exemplary: the filing's drawer config kept as a contract-only pin with no crash overclaim, and a NEW measurement (navigation: { mode: 'none' }) proving the exposure IS reachable — the open question answered with evidence, not promoted by assertion.
• Red-first: 9 red verbatim, union-of-channels capture, both registrations, both channels; 10 must-not-change green both sides including ListView's real function-on-node-key path. .d.ts byte-identical → patch stands (and the honest note that the renderer's accepted type stays an open record while only the FORWARD narrows is the right reading).
• The origin/main ref-drift incident is recorded as seat knowledge: worktrees share one .git, so another agent's fetch moves your origin/main ref mid-task — merge-base is the truth, and the pre-push rebase was the right recovery. plugin-calendar: calendar-view's colorMapping input is declared but inert — nothing reads it, so an authored colour map does nothing #4493/plugin-calendar: calendar-view's allowCreate input is declared but inert — the handler it would drive is built and never passed #4454 census-confirmed as open-tail on this surface (never declared here), staying their own pooled pair; the declared-but-inert onEdit/onDelete observation is recorded.
• CI 20/20 green, no flake, foreground waits only. Surface exactly 3 files.

Flipping ready + arming auto-merge. The calendar package's whitelist migration is now COMPLETE across all four registrations (#4433 → #4452 → #4453 → #4492).

---

Generated by Claude Code

---

Generated by Claude Code