big-calendar is a React calendar you copy a folder out of

Five views, one container component

The feature list is organised by what the calendar shows you. There are five viewing modes: an agenda view, a year view, a month view, a week view with detailed time slots, and a day view with an hourly breakdown. All of them are selected through the same `ClientContainer` component, which takes a view prop:

// Day view
<ClientContainer view="day" />

// Week view
<ClientContainer view="week" />

// Month view
<ClientContainer view="month" />

// Year view
<ClientContainer view="year" />

// Agenda view
<ClientContainer view="agenda" />

The project structure mirrors the feature list, with a directory per view under `src/calendar/components/`, alongside `dialogs/`, `dnd/`, `header/` and `contexts/`, plus `helpers/`, `interfaces/` and `types/` for the rest. The separate `dnd/` directory is the clearest sign that drag and drop is a first-class concern rather than an afterthought bolted onto the month view.

Drag and drop is the feature that needs the most code

Rescheduling by dragging is described across four capabilities: easily reschedule events by dragging and dropping, move events between days in the month view, adjust event timing in the week and day views, and visual feedback during the drag operation. The fourth point is the one that separates a usable implementation from a working one, since a drag that gives no feedback while the pointer is down is indistinguishable from a broken one. The dependency list shows how it is done, with react-dnd and react-dnd-html5-backend for the drag mechanics and lucide-react for the icons, and the day view in particular is where a time-slot grid makes dragging to a new time rather than a new day meaningful.

Events carry a colour and a user, and users are filterable

The data model is small and explicit. An event has an id, a title, a description, ISO start and end dates, a colour drawn from a fixed set of blue, green, red, yellow, purple and orange, and a user with an id and a name. A user has an id, a name and an optional avatar path. The user management features are filtering events by user, viewing all users' events simultaneously, and user avatars and profile integration, so the user field on an event is not decoration, it is the axis you filter along. The colour field is likewise the badge axis, and there are three badge display variants, dot, coloured and mixed, which is the difference between a small dot on the day cell, a filled block, and a block with a text label.

The integration path is copy three folders

The section on implementing it in your project is unusual for a React project, and it is the most important thing to understand. You copy the required folders into your project, which are `src/calendar/` for the core calendar functionality, `src/components/ui/` for the UI components the calendar uses, and `src/hooks/` for required hooks like the disclosure hook, and then install whatever dependencies your project is missing. The calendar is a private package with a version of 0.1.0 and the `private` flag set, so it was never meant to be published. The trade is explicit in the structure: you own the code and can change it, but you do not receive upstream fixes through your package manager, and updating means re-copying and reconciling.

A context provider holds the state, and a hook exposes it

The state lives in a React context, and the entry point is a provider you wrap around your application or page, taking the events and the users as props:

import { CalendarProvider } from "@/calendar/contexts/calendar-context";

const events = await getEvents();
const users = await getUsers();

export default function Layout({ children }) {
  return (
    <CalendarProvider users={users} events={events}>
      {children}
    </CalendarProvider>
  );
}

From any component below the provider you reach the state through the `useCalendar` hook, which returns the selected date and its setter, the selected user id and its setter, the events, the users, and the badge variant with its setter. Having the badge variant in the same context as the data is the detail that makes the change work, since the variant has to apply to every view at once. There is also a live time indicator, current event highlighting and dynamic event positioning, which are the small touches that make a calendar feel alive rather than static.

Working hours and appearance are configurable

The time customisation section is about making a calendar usable rather than complete. You can configure working hours with distinct styling, adjust the visible hours range, and focus on the relevant time periods, which is what stops a 24 hour grid from being mostly empty rows. The UI features are the usual list, with responsive design for all screen sizes, navigation between dates, dark mode support, and a clean interface. The reference example assembles the whole thing in one page, with the provider, the container and the badge variant input side by side in a constrained layout. The tech stack is Next.js 14, TypeScript, Tailwind v3, date-fns for dates, shadcn/ui for components and React Context for state, and the project also carries a `components.json` for the shadcn configuration and a `registry.json`, both of which point at the component registry convention that shadcn uses.

Editorial conclusion

Adopt big-calendar if you want a full calendar interface in a React project and would rather own the source than depend on a package, since the project is explicitly structured for copying folders into your tree. Do not adopt it if you need it to keep up with upstream changes, because a copied folder does not get your dependency manager's updates. Verify first that you can live with the Next.js 14 and Tailwind v3 versions it targets, that your event and user objects match the expected interfaces, and that the drag and drop behaviour works with the pointer and touch devices you support.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. lramos33/big-calendar on GitHub
4. Project website
5. README