FullCalendar React Component: the official wrapper, and where it stops

What @fullcalendar/react actually is

This package is the official React connector for FullCalendar, not a calendar written in React. The distinction matters when you are choosing a dependency. The calendar engine, the view logic and the date math live in @fullcalendar/core and in separate plugin packages; the connector's job is to mount that engine inside a React component, hand it your options as props, and keep the two in step.

That design answers a narrow question: how do I get FullCalendar's month, week, list and resource views into a React app without writing a wrapper myself? If your requirement is a calendar with a large set of built-in views and an event model you configure through options, the connector is the shortest path. If your requirement is a component that behaves like idiomatic React all the way down, this is not that, and the README does not pretend otherwise.

The package is published as @fullcalendar/react, currently at 6.1.21, under the MIT licence. The repository is not archived and the last push was on 2026-06-18, the same date as the 6.1.21 release.

How the connector maps props onto the FullCalendar engine

The README's example shows the whole model in one block. You pass plugins as an array, set initialView to a view name such as 'dayGridMonth', and pass events as an array of objects. Everything else in the documented options list is supplied the same way, as a prop on the component.

The mechanism is a two-way bridge. React owns the component lifecycle; the engine owns the DOM it renders into and the internal state of the current view. The connector translates prop changes into engine calls, and translates engine callbacks back into React. That is why eventContent in the example is written as a plain function returning JSX: the engine calls it during its own rendering pass, and React renders the returned elements. Custom render functions are the documented extension point, not a workaround.

Two consequences follow from this architecture. First, the plugin array is not decorative. A view name like 'dayGridMonth' only resolves if the matching plugin is present, so the view you ask for and the plugin you install are a single decision made in two places. Second, because the engine is shared with the non-React builds, option names and their behaviour are the same across frameworks, which is useful if your team already knows FullCalendar from another stack.

Installing @fullcalendar/react and rendering a first month view

The README gives the install line directly: the connector, the core package and a view plugin. Install all three, because the connector does not bundle a view.

npm install @fullcalendar/react @fullcalendar/core @fullcalendar/daygrid

After that, render the component with the plugin array and a view name. This is the README's example, trimmed to the parts you need to see something on screen:

import FullCalendar from '@fullcalendar/react'
import dayGridPlugin from '@fullcalendar/daygrid'

const events = [
  { title: 'Meeting', start: new Date() }
]

export function DemoApp() {
  return (
    <FullCalendar
      plugins={[dayGridPlugin]}
      initialView='dayGridMonth'
      events={events}
    />
  )
}

You should see a month grid with today's date highlighted and one event titled Meeting on the current day. The events array is the input; the connector passes it to the engine, which places each object according to its start value.

To customise how an event looks, the README adds an eventContent prop pointing at a function that receives eventInfo and returns JSX. That function is where timeText and event.title are available. The README also links an example project at fullcalendar-examples/tree/main/react, which is the better starting point than the snippet once you need more than one view.

If you are working on this repository rather than consuming the package, the README states you must install it with PNPM and that the available scripts include build, dev, test, test:dev, lint and clean, run as pnpm run <script>.

The plugin split is the limitation you will hit first

The most common failure is a blank or partial calendar caused by a missing plugin, not by a bug in your code. The connector has no default view. Install @fullcalendar/react and @fullcalendar/core without a view plugin and there is nothing for initialView to resolve to. The README's install command includes @fullcalendar/daygrid precisely because the example uses 'dayGridMonth'.

Version alignment is the second constraint. In package.json, the peer dependency on @fullcalendar/core is declared as ~6.1.21, and the devDependencies pin the same tilde range across every plugin the repository tests against. The tilde range accepts patch releases within 6.1.x but not 6.2. If you install a plugin on a different minor line from core, the peer range is telling you the combination is not the one this package was built against.

React itself is bounded too. The declared peer range is ^16.7.0 || ^17 || ^18 || ^19. That is wide, but it is a range, and a project on a React version outside it is out of scope for this connector regardless of whether it happens to work.

Finally, the README does not document rollback or downgrade steps, and it does not describe what happens when a plugin is removed from the array at runtime. Treat the plugin list as configuration set once per mount rather than something to toggle dynamically, unless you verify the behaviour yourself.

React-big-calendar and the difference in approach

The obvious alternative people search for alongside this package is React-big-calendar. The difference is architectural, not cosmetic. React-big-calendar is a React component library: the views are React components and the styling and behaviour are expressed in React terms. FullCalendar is a framework-agnostic engine with React as one of several connectors, which is why @fullcalendar/angular exists as a sibling project.

That produces a real trade-off. Choosing the connector means your calendar's capabilities are defined by FullCalendar's plugin catalogue, and you adopt a dependency graph of core plus one package per view family. Choosing a React-native library means fewer moving parts and a component tree you can inspect directly, at the cost of the view coverage and the option surface that FullCalendar's documentation describes.

Neither is universally better. If you need resource and timeline views, the plugin packages named in this repository's devDependencies (@fullcalendar/resource and @fullcalendar/resource-timeline) are the reason to stay. If you need one month grid and nothing else, a single React library is easier to reason about. Note also that FullCalendar has a premium tier for some plugins; the README here does not enumerate which plugins are free and which are not, so check that before you commit to a view.

Maintenance, upgrades and what the MIT licence covers

The release cadence visible in the repository is slow and deliberate: 6.1.19, then 6.1.20, then 6.1.21. The last push was on 2026-06-18, which is the same day as the 6.1.21 release. Nothing in the repository is archived. That pattern suggests patch-level maintenance rather than frequent feature work, and you should plan upgrades around patch releases within the 6.1.x line rather than expecting a new minor line on a schedule.

Upgrading is cheap when you stay inside the tilde range, because the peer dependency and the plugin devDependencies move together. It becomes a coordinated change the moment core and a plugin diverge, which is the scenario the peer range is designed to prevent. Budget for checking every @fullcalendar package in your lockfile at once.

The package is MIT licensed. That covers this connector. It does not automatically tell you the licence of every plugin you install, and the README does not list them. If your organisation reviews licences per dependency, resolve the licence of each @fullcalendar package you add rather than assuming the connector's MIT terms extend to the set. This is a description of what the repository states, not legal advice.

Editorial conclusion

Adopt @fullcalendar/react when you want FullCalendar's views and event model inside a React tree and you accept the plugin split: the connector, the core package and at least one view plugin must all be installed and all pinned to the same 6.1.x line. Do not adopt it if you want a React-native component with no imperative layer underneath, or if a single small dependency matters more than view coverage. Before committing, check two things in your own project: that your React version falls inside the peer range (^16.7.0 || ^17 || ^18 || ^19), and that your bundler resolves the CSS and plugin entry points the way the example project does. The README's installation line is the contract: @fullcalendar/react alone renders nothing usable without @fullcalendar/core and a plugin such as @fullcalendar/daygrid.

Frequently asked questions

Official sources

1. fullcalendar/fullcalendar-react on GitHub
2. License: MIT
3. Project website
4. README
5. Releases