syncfusion-pure-react-scheduler

React Scheduler (Syncfusion)

Guide the user's React Scheduler work end-to-end: choosing views, binding event data, recurring events, resources and grouping, CRUD and editor customization, plus timezone, localization, and accessibility. All knowledge below applies to the Syncfusion® React Scheduler component shipped as the @syncfusion/react-scheduler npm package.

When to use this skill

Read this skill before doing any of the following in a React project:

• Setting up — Installing package, adding CSS/theme, rendering a first scheduler
• Choosing views — Day, Week, Work Week, Month, Agenda, or Timeline views
• Binding data — Connecting to local state, remote services (REST/OData), or load-on-demand
• Adding events — CRUD operations (create, read, update, delete) with editors or custom forms
• Recurrence — Configuring daily/weekly/monthly/yearly repeat rules from the iCalendar spec
• Resources — Grouping by rooms, staff, doctors, equipment, or other entities
• Customization — Editor dialogs, quick popups, templates, header toolbars
• Interactions — Drag-and-drop, resizing, context menus, tooltips
• Timezones, localization, RTL — Date/time formats, multiple languages, right-to-left layout
• Accessibility — ARIA, keyboard navigation, WCAG compliance
• Mobile — Touch interactions, responsive layouts
• Theming — Applying or changing Material, Tailwind or Bootstrap themes

If the user is on Angular, Vue, Blazor, or another non-React platform, this skill does not apply — the APIs below are React-specific.

Scope containment: The knowledge source for Scheduler work is restricted to this skill's own files. This rule is defined as Guardrail 1 — Scope containment below; read it before sourcing any API.

How this skill is organized

This skill is designed for quick access — read only what you need now. Use the table below to find the right reference:

By Task/Use Case

Your Task	Read This
I'm starting from scratch	getting-started.md — Installation, CSS, first scheduler
I need project setup steps and prerequisites	setup.md — Installing the package, theme CSS options, controlled vs uncontrolled modes
I need to understand how Scheduler works	architecture-overview.md — Component structure, data flow, mental models
I want to choose and configure views	views.md — Day, Week, Work Week, Month, Agenda (or timeline-views.md for timeline)
I need to bind event data	events-data.md — Local state, remote services, load-on-demand, DataManager
I need to understand event structure	event-fields.md — Event fields, custom mapping, TypeScript interfaces
I need all event types (all-day, recurring, etc.)	event-types.md — Event categories, overlapping events, conflict handling
I need to set up CRUD (add/edit/delete)	crud-external-forms.md — Built-in editor, quick popup, programmatic methods
I need to build a custom form for events	external-forms.md — Custom form patterns using addEvent(), saveEvent(), deleteEvent()
I need recurring events	recurrence.md — iCalendar rules, editing occurrences vs series, RecurrenceEditor
I need to modify or exclude specific recurrences	recurrence-exceptions.md — Exception dates, modifying occurrences, replacing events
I need to block times or set read-only events	blockout-readonly.md — Blockout dates/hours, read-only events, scheduler-wide read-only
I need to load events dynamically	load-on-demand.md — onDataRequest, date-range loading, DataManager integration
I need to handle data changes and persistence	data-changes.md — onDataChangeStart/onDataChangeComplete, error handling, rollback
I need to customize the editor or quick popup	editor-and-popups.md — Editor fields, validation, quick-popup rendering, tooltips
I need to add a right-click context menu	context-menu.md — Context menu integration for cells and events
I need to customize header/toolbar	header.md — Header toolbar, reordering items, custom controls
I need to group by resources (rooms, staff)	resources-grouping.md — Resources, grouping patterns (hierarchical, date-first, sequential)
I need custom event/cell/header rendering	templates-ui.md — Event templates, cell templates, header customization
I need to handle callbacks and events	events-api.md — Callbacks, event lifecycle, data/error events, editor hooks
I need multiple languages, RTL, or custom date formats	globalization-accessibility.md — L10n, date formats, RTL, timezones, ARIA, keyboard nav
I need to integrate Dialog, ContextMenu, DatePicker, etc.	related-components.md — Dependency component APIs, Scheduler integration and common feature
I need to apply, change, or update a theme ( Material, Tailwind, or Bootstrap)	setup.md — Theme integration, installation, CSS import paths, and setup instructions for all themes
I want a complete end-to-end example	solutions.md — Real-world use case combining multiple features
I need to register a license key	registering-license-keys.md — License key registration methods for removing runtime notices

Mental Model

A scheduler renders on three pillars:

1. Views are child components — Render views as JSX children of <Scheduler> (e.g., <DayView /> <WeekView /> <MonthView /> <AgendaView />). Only views rendered as children appear in the view switcher; the Week view is active by default. View-specific settings go on each view component; general settings (startHour, workDays, timeScale) go on <Scheduler> itself.

2. Events come from eventSettings.dataSource — This accepts a local array, React state, or a Syncfusion DataManager for remote services. If your data's field names differ from the defaults (Id/Subject/StartTime/EndTime), map them in eventSettings.fields rather than reshaping your data.

3. Customization is function props — Editor, quick popup, header bar, tooltips, templates, and resource headers are all configured by passing render functions — never by mutating internal state.

Quick orientation snippet:

import { DayView, WeekView, WorkWeekView, MonthView, Scheduler, EventSettings } from '@syncfusion/react-scheduler';

const data = [
    { Id: 1, Subject: 'Team Meeting', StartTime: new Date(2026, 0, 12, 10, 0), EndTime: new Date(2026, 0, 12, 11, 0) }
];
const eventSettings: EventSettings = { dataSource: data };

export default function App() {
    return (
        <Scheduler height='34.375rem' eventSettings={eventSettings} defaultSelectedDate={new Date(2026, 0, 12)}>
            <DayView />
            <WeekView />
            <WorkWeekView />
            <MonthView />
            <AgendaView />
        </Scheduler>
    );
}

Workflow

1. Identify the use case: what is being scheduled, by whom, in what views? What are the core interactions (CRUD, recurrence, resources)?
2. Pick views and set them as children (see references/views.md).
3. Prepare data: local array/state, remote DataManager, or load-on-demand (see references/events-data.md and references/load-on-demand.md).
4. Map data fields in eventSettings.fields if they don't match defaults (Id/Subject/StartTime/EndTime).
5. Layer in core event behaviors:
   • Recurrence (references/recurrence.md)
   • Event type constraints: blockout times, read-only events (references/blockout-readonly.md)
   • Resources and grouping (references/resources-grouping.md)
6. Implement CRUD interactions:
   • Built-in editor/quick-popup or custom external form (references/crud-external-forms.md, references/external-forms.md)
   • Programmatic methods if needed (references/external-forms.md)
   • Context menu if desired (references/context-menu.md)
7. Apply UI customization:
   • Header/toolbar (references/header.md)
   • Templates, editor, quick popup (references/editor-and-popups.md, references/templates-ui.md)
   • Event and cell rendering (references/templates-ui.md)
8. Apply theme integration: Material, Tailwind, or Bootstrap (references/setup.md)
9. Finish with globalization/accessibility: locale, date/time formats, RTL, ARIA, keyboard support (references/globalization-accessibility.md).
10. Verify before handing off: run the API grounding check, the fast verification check, and the self-review checklist below. Do not present the work as complete until they pass.

Dependency components first: if the user's prompt or any step above needs another component (a dropdown, date/time picker, form input, dialog, context menu, tooltip, drag-and-drop utility, data manager, etc.) — whether to integrate it with the Scheduler or just to access its info — read references/related-components.md (the machine-readable documentation for related React components) before writing any code that uses it. Do not recall those components' APIs from memory.

Theme integration: whenever the task involves applying, changing, or updating a theme for the Scheduler (Bootstrap, Material, or Tailwind, including light/dark modes) — read references/setup.md (it contains the Themes documentation: Bootstrap, Material, and Tailwind) before writing any theme CSS import or configuration. Do not source theme names or CSS import paths from memory.

Key Defaults

These are the out-of-the-box behaviors when you create a Scheduler without specifying overrides:

• Active view: Week view
• Selected date: Current system date
• Date format: MM/dd/yyyy (derived from locale; use locale prop to customize)
• Time format: 12-hour for en-US, 24-hour for most other locales (derived from locale)
• Timezone: User's browser/system timezone (when none set explicitly; see references/globalization-accessibility.md)
• All-day events: Not timezone-converted; displayed in user's local timezone
• Interactions: Drag-and-drop and resizing enabled by default (eventDrag and eventResize props)
• CRUD validation: Built into the editor (field validation, date/time validation)
• Recurrence: Supports daily, weekly, monthly, yearly rules per the iCalendar spec
• Accessibility: WCAG 2.2, Section 508, and ARIA compliant; full keyboard navigation ("Alt+1" = Day, "Alt+2" = Week, etc.; see references/globalization-accessibility.md)

Guardrails

These gates exist because the failure modes of Scheduler work are specific and quiet: an invented prop or import path doesn't error where you'd notice it, and a data source whose fields don't match the defaults renders an empty calendar with no exception. The domain knowledge above tells you what to build; the gates below stop you from shipping something that looks right but doesn't run. Treat them as blocking, not advisory.

1. Scope containment (allowed sources)

Everything needed to build Scheduler features must come from this skill's own files — nothing else. This is the containment gate: it keeps answers grounded in the package's real, documented surface instead of drifting to another platform or stale training data.

Scheduler APIs — allowed sources:

• This SKILL.md
• The files inside the references/ folder

Do not read, copy, or rely on anything else for a Scheduler task — no other folders in or around this skill's directory (agents, scripts, eval-viewer, source docs, other skills, sibling packages), and no external documentation outside these files. If required information is not found in these two locations, stop and tell the user exactly what is missing so the skill itself can be updated — never source the answer from elsewhere.

Dependency-component APIs — allowed source: The companion packages listed under "Related component packages" (DropDownList, DatePicker, DataManager, Dialog, ContextMenu, etc.) are dependencies of the Scheduler, not part of it — the references above do not document their APIs. Whenever any of them is needed — because the user asks for it, or because a Scheduler feature requires it (custom editor fields, quick-popup inputs, header toolbar items, context menu, dialogs, external forms, remote data, drag-and-drop helpers) — its info must come from references/related-components.md (the machine-readable documentation for related React components). Do not rely on memory or training data. If that file does not yet contain the needed component, stop and ask the user to add its machine-readable documentation entry rather than guessing the API.

Theme integration — allowed source: Whenever the Scheduler needs theme integration — applying, changing, or updating a theme (Bootstrap, Material, or Tailwind, including light/dark modes) — the theme info (theme names, CSS import paths, theme setup steps) must come from references/setup.md (which contains the complete Themes documentation: Bootstrap, Material, and Tailwind).

CRITICAL: Always consult references/setup.md for theme implementation details. It contains essential information about:

• Which themes require dedicated packages (Bootstrap and Tailwind ONLY available in dedicated packages)
• Correct CSS import paths for each theme
• Installation commands for theme packages
• Common theme implementation mistakes to avoid

Do not rely on memory or training data for theme names or CSS import paths. If the needed theme info is not in that file, stop and ask the user to add it rather than guessing.

Rule: an out-of-scope source is a BLOCK, not a shortcut.

2. API grounding (anti-hallucination)

Every Scheduler API you emit must be traceable to a line in this SKILL.md or a references/* file. This means: view components (DayView, WeekView, TimelineViews, …), <Scheduler> props, eventSettings keys, event field names, enum/string values, callback prop names, method names, and CSS/theme import paths.

• Before writing an API you are not certain about, read the reference that owns it (see the structure table). Prefer copying a documented shape over reconstructing one from memory.
• If an API you need is not in these files, stop. Do not approximate it from another Syncfusion platform (Angular/Vue/Blazor/EJ2) or from training data — the React package's surface differs. Tell the user exactly which API is missing so the skill can be updated.
• Dependency-component APIs (DropDownList, DatePicker, DataManager, Dialog, etc.) are grounded only in references/related-components.md — never memory, per the Scope containment gate above.

Rule: an ungrounded API is a BLOCK, not a guess.

3. Fast verification check

After writing or editing code, verify it before handing off. Discover the project's own commands first (inspect package.json scripts, then fall back to the tool directly); do not impose a new toolchain.

1. Typecheck / build — run the project's typecheck or build (e.g. tsc --noEmit, npm run build, vite build). It must exit clean. TypeScript catches most invented props and wrong value types at this step, which is why it comes first.
   • How to check: Run npm run typecheck or npm run build in the terminal and verify there are no errors
2. Imports resolve — every symbol is imported from @syncfusion/react-scheduler (or the correct companion package per "Related component packages"), and the required theme CSS is imported. Wrong package or wrong path is a common silent failure.
   • How to check: Verify all import statements point to correct packages and that imported components are actually used in the code
   • Theme-specific check: Refer to references/setup.md for correct theme CSS import paths and verify the imports match the documentation exactly
3. Render smoke — confirm <Scheduler> is actually mounted in the component tree and that at least one view (e.g. <WeekView />) is a JSX child — with no view children the view switcher is empty.
   • How to check: Start the development server and visually confirm the scheduler renders in the browser without errors

If any step fails, fix it before proceeding. Do not report the task complete on unverified code.

4. Field-mapping & reachability validation

The single most common Scheduler bug is data that renders nothing because its field names don't match. Before finishing, confirm the data path end-to-end:

• Field mapping: the data uses Id/Subject/StartTime/EndTime, or eventSettings.fields maps the real field names. StartTime/EndTime resolve to Date objects (or parseable date strings), not raw numbers/undefined.
• Data wiring: eventSettings.dataSource is connected to the actual array/state/DataManager — not a leftover placeholder. For remote data, the adaptor and endpoint shape come from references/events-data.md and references/related-components.md.
• Feature reachability: if the request implied recurrence, resources/grouping, CRUD, or a custom editor, verify the corresponding config is present and wired (e.g. recurrence needs the recurrence fields per references/recurrence.md; grouping needs group + resource definitions per references/resources-grouping.md). Code that compiles but leaves the requested feature unwired is a failure even without errors.

5. Circuit breaker (stop guessing)

If the same import, prop, or type error persists after two fix attempts, stop editing:

1. Re-read the specific reference file that owns that API — the mental model that produced two wrong fixes will produce a third.
2. If the correct API is in the reference, apply it. If it is genuinely absent, treat it as an API-grounding gap: report to the user what you were trying to do, what you tried, and what the references do (and don't) cover. Do not synthesize an API to break the loop.

6. Self-review checklist (before handoff)

Before completing any Scheduler implementation, the developer (or code reviewer) should confirm each item and report which were verified and which were skipped and why. For each item, either check the box or explain why it was skipped:

• Every emitted Scheduler/dependency API came from an allowed source and is grounded in SKILL.md or references/* (gates 1–2). Verification method: Cross-reference all APIs used with the documentation in this skill's files
• Typecheck/build passes; imports and theme CSS resolve (gate 3). Verification method: Run the project's build process and confirm no errors Theme-specific verification: Confirm theme CSS imports follow exactly the patterns documented in references/setup.md
• Field mapping and data wiring verified; requested features are reachable (gate 4). Verification method: Confirm data fields match expected names or are properly mapped, and all requested features are implemented
• Views rendered as children match the views the user asked for; general vs view-specific settings are on the right component (see Mental model). Verification method: Visually confirm the scheduler renders with the correct views and settings
• No API was sourced from a non-React Syncfusion platform or from memory. Verification method: Ensure all APIs are from this skill's documentation, not from external sources
• If anything was missing from the references, the user was told precisely what and where. Verification method: Document any gaps in the skill documentation that needed to be addressed

Version & import-path protection

Do not invent a package version, a theme name, or a CSS import path. Take the installed @syncfusion/react-scheduler version and theme from the project's package.json / existing imports; if none exists yet, follow references/getting-started.md and the Themes documentation in references/setup.md (Material, Tailwind, Bootstrap), and state what you assumed rather than guessing a version string.

Recording project quirks (optional but recommended)

When you discover a project-specific convention that future Scheduler work should honor, note it where the project keeps such notes (e.g. LESSONS_LEARNED.md or the repo's docs). This keeps the next session from rediscovering it and prevents repeating mistakes.

Examples of "quirks" to record:

• Custom field names that differ from the standard Id/Subject/StartTime/EndTime
• Expected timezone handling that differs from the browser default
• Specific remote-adaptor shapes for API endpoints
• Shared editor patterns or custom styling conventions
• Performance optimizations or workarounds for specific browser issues

Where to record:

• Project's LESSONS_LEARNED.md or README.md if it exists
• Repository's documentation folder
• Comments in the relevant code files
• Team's internal documentation system

Related component packages

The Scheduler frequently integrates with these companion packages. The table below maps each package to the concrete components it exports (as used in this skill's references) and the Scheduler features that need them:

Package	Components/exports used in Scheduler work	Scheduler use case (reference)
@syncfusion/react-navigations	ContextMenu, MenuItem, MenuItemIcon, MenuItemLabel, ToolbarItem, ToolbarSeparator, ToolbarSpacer, OverflowMode	Right-click menus (references/context-menu.md), custom header/toolbar layouts (references/header.md, references/templates-ui.md, references/solutions.md)
@syncfusion/react-buttons	Button, Checkbox, Variant	Save/Cancel/custom action buttons in editors and quick popups (references/editor-and-popups.md, references/crud-external-forms.md, references/external-forms.md, references/header.md)
@syncfusion/react-inputs	Form, FormField, TextBox, TextArea, ValidationRules	Custom editor forms with validation (references/editor-and-popups.md, references/external-forms.md, references/crud-external-forms.md)
@syncfusion/react-calendars	DatePicker, TimePicker	Date/time selection in custom editors and external forms (references/editor-and-popups.md, references/external-forms.md, references/crud-external-forms.md)
@syncfusion/react-dropdowns	DropDownList	Resource pickers and filters in editor forms and toolbars (references/editor-and-popups.md, references/solutions.md)
@syncfusion/react-data	DataManager, WebApiAdaptor	Remote event data binding and load-on-demand (references/events-data.md, references/load-on-demand.md)
@syncfusion/react-popups	Dialog, Toast, Position	External edit dialogs (references/solutions.md), save/error notifications (references/data-changes.md), tooltip positioning (references/editor-and-popups.md)
@syncfusion/react-base	Variant, Color, Size, formatDate, L10n, loadCldr	Styling/formatting in editor and quick-popup templates, plus localization/CLDR setup (references/editor-and-popups.md, references/header.md, references/globalization-accessibility.md)
@syncfusion/react-icons	AddNotesIcon, DeleteNotesIcon, EditIcon, RepeatIcon, DayIcon, CircleAddIcon, SettingsIcon	Icons in context menu items and custom toolbar items (references/context-menu.md, references/header.md)
@syncfusion/react-cldr-data	CLDR JSON data	Culture data files for localization (references/globalization-accessibility.md)

Additional components documented in references/related-components.md (Autocomplete, Calendar, ComboBox, DateRangePicker, DateTimePicker, ListView, Menu, Message, MultiSelect, NumericTextbox, RadioButton, Skeleton, Spinner, Switch, Tooltip, etc.) and its Getting Started / Common Features guides may also be integrated with the Scheduler when a task calls for them.

These packages are dependencies of the Scheduler, not part of it — the Scheduler's own references do not cover their APIs. Before writing, configuring, or integrating any of them, follow Guardrail 1 — Scope containment: their info must come from references/related-components.md, never memory or training data.

For all theme implementation details, ALWAYS consult references/setup.md which contains:

• Complete installation instructions for each theme
• Correct CSS import paths for all themes
• Theme availability matrix showing which themes require dedicated packages
• Troubleshooting guidance for common theme implementation issues

Glossary

llms.txt: A machine-readable documentation format that contains API specifications, component descriptions, and usage guidelines for Syncfusion components. In this skill, this refers to the content contained in references/related-components.md which serves as a knowledge source for AI agents to understand component capabilities without relying on external documentation.

API Grounding: The practice of ensuring all code examples and API references originate from verified documentation sources rather than memory or assumptions, reducing hallucination risks.

Scope Containment: A development principle that restricts implementation guidance to only use APIs and information from approved documentation sources within the skill's own files.

Scheduler: The Syncfusion React Scheduler component (@syncfusion/react-scheduler), an event calendar UI component for displaying and managing time-based events in various views.

View: A specific calendar display mode such as Day, Week, Work Week, Month, Agenda, or Timeline that determines how events are presented temporally.

Event: An appointment or calendar entry consisting of a subject, start time, end time, and optional metadata like location or description.

Recurrence: A repeating pattern for events that follow the iCalendar specification, allowing events to repeat at intervals (daily, weekly, monthly, yearly).

Resource: Entities that can be associated with events such as people, rooms, equipment, or departments, enabling resource-based scheduling and grouping.

CRUD: Create, Read, Update, Delete operations for managing events within the scheduler.

DataSource: The collection of event data that populates the scheduler, which can be local arrays, React state, or remote services via DataManager.

DataManager: Syncfusion's data abstraction layer for connecting the scheduler to remote data services through various adaptors (Web API, OData, etc.).

Field Mapping: The process of associating event data properties with scheduler-expected field names through the eventSettings.fields configuration.

Template: Customizable rendering functions that override default UI elements like events, date headers, or cells to provide custom appearance and behavior.

Quick Popup: Lightweight contextual interface that appears when clicking cells or events, providing streamlined interactions without opening the full editor.

Editor Window: Modal dialog interface for creating and editing event details with full form controls and validation.

Theme: Predefined styling packages ( Material, Tailwind, Bootstrap) that control the visual appearance of the Scheduler component, installed separately and imported via CSS.

Timezone: Regional time settings that affect how event times are displayed and converted across geographic locations.

Localization: Adapting the scheduler interface to different languages and cultural preferences through locale-specific text and formatting.

Accessibility: Design practices ensuring the scheduler is usable by people with disabilities, following WCAG and Section 508 compliance standards.

Guardrails: Defined validation and verification checkpoints that must pass before considering scheduler implementation complete, preventing common errors and misconfigurations.