Skip to main content

RestDataProvider

Provider class that wires Calendar mutations (add-event, update-event, move-event, delete-event) to a REST events collection. Fetches data via getData() - all events, or one range - with Date fields parsed. When a loader is supplied, it also forwards request-data to it for dynamic loading.

Usage​

class RestDataProvider {
	constructor(url?: string, config?: CalendarRestDataProviderConfig);
	getData(range?: { startDate: Date; endDate: Date }): Promise<CalendarEvent[]>;
	send(path: string, method: string, body?: any): Promise<any>;
}

Constructor​

ParameterTypeDescription
urlstringOptional base URL of the REST endpoint serving events.
configCalendarRestDataProviderConfigOptional provider settings.
type CalendarRestDataProviderConfig = Partial<RestDataProviderConfig> & {
	loader?: { request(data: RequestDataAction): Promise<void> };
	parseDate?: (value: any) => Date;
	serializeDate?: (date: Date) => any;
};
FieldTypeDescription
loader{ request(data): Promise<void> }Dynamic loader that receives request-data. Without one, request-data is a no-op.
parseDate(value: any) => DateConverts incoming date strings to Date. Default: value => new Date(value).
serializeDate(date: Date) => anySerializes Date values in range query URLs. Default: date => date.toISOString().

Endpoints​

The provider issues these requests against url:

ActionMethodPathBody
getData()GET/events-
getData({ startDate, endDate })GET/events?startDate=...&endDate=...-
add-eventPOST/eventsevent payload (without id)
update-eventPUT/events/{id}event payload (debounced 500ms)
move-eventPUT/events/{id}move patch (immediate)
delete-eventDELETE/events/{id}-

request-data isn't a REST call - the provider forwards it to loader.request(data) when a loader was supplied, otherwise it does nothing.

On any getData call, start, end, and each exdates entry are converted to Date instances via parseDate.

Date-serialization caveat: serializeDate reliably controls the startDate/endDate values in range query URLs. It does not control dates inside CRUD request bodies - native Date#toJSON() runs before the provider's JSON replacer, so nested body dates serialize as native ISO strings even with a custom serializeDate.

Loading initial data​

<script>
  import { Calendar, RestDataProvider } from "@svar-ui/svelte-calendar";

  const provider = new RestDataProvider("https://example.com/api");
  let data = $state([]);
  let date = $state(new Date());

  provider.getData().then(events => {
    data = events;
    if (events[0]) date = events[0].start;
  });
</script>

<Calendar events={data} {date} />

Forwarding mutations​

Attach via api.setNext(provider) inside init to forward add/update/delete actions to the backend:

<script>
  import { Calendar, Editor, RestDataProvider } from "@svar-ui/svelte-calendar";

  const provider = new RestDataProvider("https://example.com/api");
  let api = $state();
  let data = $state([]);

  provider.getData().then(events => (data = events));

  function init(api) {
    api.setNext(provider);
  }
</script>

<Calendar bind:this={api} {init} events={data} date={new Date()} />
{#if api}<Editor {api} />{/if}

Dynamic loading​

Pass a loader to load events per visible range instead of all at once. The store emits request-data when the range changes; the provider forwards it to loader.request(data). The loader fetches the range (typically via provider.getData({ startDate, endDate })) and pushes results back with provide-data. The provider itself does not cache ranges or dispatch provide-data - that's the loader's job.

const provider = new RestDataProvider("https://example.com/api", {
	loader: myDynamicLoader,
});

See the dynamic loading guide for the full loader wiring and cache contract.