FullCalendar libraries comparison

A full calendar/scheduler is one of the heaviest UI primitives a component library can ship, and FullCalendar is the vanilla engine the ecosystem has standardized on. Unlike most engines, FullCalendar publishes its own official framework connectors — but only for three frameworks, plus (since v7) a generic web-component build. The rest of the matrix is a stale community wrapper and a pre-1.0 experiment.

Rozie's @rozie-ui/fullcalendar ships the same <FullCalendar> to every framework in your stack: the same curated prop and event surface, the same imperative handle, the same ten custom-content portal slots, and the same :options long-tail passthrough (including consumer-engageable plugins beyond the bundled set) on React, Vue, Svelte, Angular, Solid, and Lit alike. Each framework installs a pre-compiled @rozie-ui/fullcalendar-* package with no Rozie toolchain required.

Every wrapper on this page, including Rozie's, drives the @fullcalendar/core engine. FullCalendar v7 (7.0.2, published 2026-07-24) is the current major, and the official connectors track it in lockstep; Rozie's packages and the community wrappers drive the mature v6 line (latest 6.1.21, published 2026-06-18), which FullCalendar still maintains. The engine is shared and well-maintained, so this comparison is purely about the per-framework binding layer: which frameworks have a binding at all, which framework versions it supports, and how consistent the reconcile / imperative-handle / custom-content story is across them.

Comparison matrix

Cell legend: ✓ = documented out-of-the-box · ✗ = not supported / not present · ~ = partial / consumer-glue-required / not documented. ("Not documented" is scored ~, never ✗: absence of documentation is not evidence of absence.)

Wrapper	Frameworks	Last published	Latest-framework support	Runtime option reconcile	Imperative handle	Custom event content
Rozie @rozie-ui/fullcalendar	6 — React + Vue + Svelte + Angular + Solid + Lit	pre-1.0, released together	R18+ / V3.4+ / Sv5 / Ng19+ / Solid / Lit	✓ managed $watch→setOption + :options long-tail (+ merged :options.plugins)	✓ uniform $expose	✓ 10 portal-slots, all 6
@fullcalendar/react (official)	React	7.0.2 · 2026-07	React 17 – 19 (peer ^17 || ^18 || ^19)	✓ diff → re-render	✓ ref → getApi()	✓ eventContent render-prop
@fullcalendar/vue3 (official)	Vue 3	7.0.2 · 2026-07	Vue 3.0.11+ (✓ 3.4+)	✓ watches options	✓ ref → getApi()	✓ scoped slot
@fullcalendar/angular (official)	Angular	7.0.2 · 2026-07	Angular 16 – 22 (✓ 19+)	✓ diffs [options]	✓ getApi()	✓ ng-template
svelte-fullcalendar (community)	Svelte	3.0.0 · 2023-09	Svelte 4 era (no Svelte 5; repo archived)	~ options object	~ via instance ref	~ not documented
solid-full-calendar (community)	Solid	0.1.x (pre-1.0)	Solid (minimal)	~	~	~
@fullcalendar/web-component (official, v7-only)	Web components (consumable from Lit)	7.0.2 · 2026-07	generic custom element, v7 engine	~ not documented	~ not documented	~ not documented

Weekly downloads (npm, snapshot 2026-08-03→08-09, a popularity datum rather than a quality verdict): @fullcalendar/react 1,667,226 · @fullcalendar/vue3 218,376 · @fullcalendar/angular 208,249 · svelte-fullcalendar 3,410 · solid-full-calendar: negligible · Rozie @rozie-ui/fullcalendar: new.

The matrix scores each wrapper against what it documents out of the box, without consumer-authored glue. All competitor facts were verified against the npm registry, the GitHub API, and each project's README/package.json on 2026-08-10; re-check the dates before relying on them.

Where Rozie wins today

• First-class packages for all six frameworks, including the three the ecosystem leaves stale, pre-1.0, or generic. FullCalendar's official framework connectors cover exactly three frameworks: React, Vue 3, and Angular. Svelte's only option is the community svelte-fullcalendar, last published 2023-09-14, built for the Svelte-4 era, and its repo is now archived; Solid's only option is solid-full-calendar, a pre-1.0 (0.1.x) experiment; and Lit's nearest option is the v7-only official @fullcalendar/web-component, a generic custom element rather than a framework-native component surface (no documented reconcile / handle / content-slot story). A team standardizing on FullCalendar gets three first-class connectors, one stale wrapper, one toy, and one generic element. Rozie fills the whole row with the same component everywhere the official three don't reach.

• A uniform imperative handle. Rozie's $expose handle is the same verbs on every target: getApi, view and date navigation (changeView, today, prev / next, prevYear / nextYear, gotoDate, getDate, scrollToTime), event access (addEvent, removeEvent, getEvents), selection (selectRange, clearSelection), and updateSize. The official connectors all expose the underlying Calendar via getApi() too, but each reaches it its own way (a React ref, a Vue/Angular component method), and the community wrappers vary further. Rozie gives consumers one handle shape to learn once and use on any framework. See Driving navigation from the handle.

• The full *Content slot set as portal slots, everywhere. FullCalendar's content hooks are exactly the kind of feature that fragments per framework: a render-prop in React, a slot in Vue, a template in Angular, and unsupported in the wrappers that don't reach those frameworks. Rozie surfaces ten of them — event, dayCell, dayHeader, slotLabel, weekNumber, nowIndicatorContent, moreLink, allDayContent, slotLaneContent, and noEventsContent — as portal slots, each emitting the framework's idiomatic consumer surface (React / Solid render-prop, Vue scoped-slot, Svelte snippet, Angular content-child, Lit slot bridge), documented per-target in Slots. Every slot is guarded: omit it and you get FullCalendar's default rendering on every target. (noEventsContent is pre-declared but inert until you engage the list plugin; see the merged-plugins note below.)

• A :options long-tail passthrough, applied uniformly. The curated prop surface stays primary, but FullCalendar exposes far more options and hooks than any wrapper can curate. Rozie's options prop is an arbitrary passthrough bag, spread first into the engine config so curated props/events/slots win on key collision, that forwards anything the curated surface doesn't special-case (businessHours, dayMaxEvents, *DidMount hooks, object locales, …), with per-key setOption runtime reconcile. This closes the "but my app needs option X" gap without forking the wrapper. Plugins beyond the bundled set are consumer-engageable the same way: :options.plugins is the one curated key that merges (rather than clobbers) with the baked-in defaults (dayGrid/timeGrid/interaction). Import any FullCalendar plugin (@fullcalendar/list for list views + noEventsContent, rrule, google-calendar, premium scheduler plugins, …) and pass it through. One opt-in mechanism, zero per-plugin wrapper code, zero bundle cost for plugins you don't engage.

• Managed runtime reconcile, applied uniformly. Each runtime-updatable prop — view / weekends / editable / selectable / height / nowIndicator / firstDay / slotDuration / locale / headerToolbar — reconciles live via the engine's setOption with no remount, the events array reconciles through a managed removeAllEvents + addEvent loop, and view carries a round-trip guard so two-way binding doesn't fight the engine. See Reconciling events at runtime. The same reconcile behavior is exercised by full-calendar-behavior.spec.ts; cross-target rendering parity is pinned by the six full-calendar.spec.ts VR cells.

What Rozie defers

• The official React / Vue / Angular connectors are excellent and current. Unlike the date-picker ecosystem, FullCalendar's own connectors are not stale community forks: they ship from FullCalendar's monorepo, track the current engine in lockstep (v7: 7.0.2, 2026-07-24), and are the reference standard for those three frameworks. React 19 is fully inside the official React connector's peer range (since 6.1.21 on the v6 line, and ^17 || ^18 || ^19 in v7), so React-version coverage is no longer a differentiator there. Rozie's packages pin the maintained v6 line (@fullcalendar/core ^6.1); FullCalendar v7 restructures the plugin packages into framework-specific entrypoints and is not yet a Rozie target. For a single-React, single-Vue, or single-Angular app, the official connector is the obvious choice. Rozie's value on those three is the uniform cross-framework surface: one component to learn, document, and migrate across your stack.

• Reactive props, getApi, and custom content are real on the official three. The matrix scores those columns ✓ for React, Vue 3, and Angular because the official connectors genuinely support them. Rozie's advantage on those columns is consistency, the identical API, rather than a capability the official connectors lack.

• Only the premium resource views are out of scope. @rozie-ui/fullcalendar bundles the four free plugins (core + daygrid + timegrid + interaction) by default. The free @fullcalendar/list view and the rrule recurring-event plugin are not bundled but fully engageable today: :options.plugins merges consumer plugins with the baked-in defaults, so :options="{ plugins: [listPlugin] }" (or rrulePlugin) lights them up with zero per-plugin wrapper code and zero bundle cost when unused; the noEventsContent slot hook is already pre-declared for the list view's empty state. rrule needs no special wiring (events carry an rrule field once the plugin is engaged). Only the premium resource-timeline / resource-timegrid views sit behind FullCalendar's own license; those are genuinely out of scope.

Try it

The @rozie-ui/fullcalendar showcase + API reference documents the @rozie-ui/fullcalendar-* packages — one pre-compiled, per-framework install (npm i @rozie-ui/fullcalendar-react, etc.) plus the four @fullcalendar/* plugin peers; FullCalendar v6 auto-injects its CSS, so there is no stylesheet import to wire. The FullCalendarDemo source is the same .rozie consumer that powers every target cell in the matrix above.