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