Scheduler - Tree Shaking

#Overview

Every component is available two ways from the same package: flat named imports that tree-shake, and a compound Scheduler namespace that reads cleanly but pins every view into the bundle. Same components either way. For a month-only calendar where bytes matter, use the flat imports (or go further with the per-view subpaths).

#Flat Imports

Import each component by its prefixed name:

import { SchedulerRoot, SchedulerContent, SchedulerMonth } from '@primeui/vue-scheduler';

<template>
    <SchedulerRoot :events="events">
        <SchedulerContent>
            <SchedulerMonth />
        </SchedulerContent>
    </SchedulerRoot>
</template>

The bundler keeps only the named imports, so a month calendar drops the timeline, year, agenda, and resource code. Every part has a flat name: SchedulerRoot, SchedulerHeader, SchedulerMonth, SchedulerTimeline, and so on.

#Compound API

import { Scheduler } from '@primeui/vue-scheduler';

<template>
    <Scheduler.Root :events="events">
        <Scheduler.Content>
            <Scheduler.Month />
        </Scheduler.Content>
    </Scheduler.Root>
</template>

This exposes <Scheduler.Root>, <Scheduler.Month>, and the rest off one object. It reads well and there is nothing to look up. The trade is that the views are read as members at runtime, so a bundler can't tell which ones go unused and keeps all of them. A month-only calendar still ships every view under this style. On a lazy-loaded page that rarely matters.

#View Subpaths

For the leanest build, pull a single view from its own entry:

import { Month, MonthGrid } from '@primeui/vue-scheduler/views/month';

One subpath per view: month, week, day, timeline, agenda, year, resource, date. Each carries that view's scope, its outlets, and its rendering code, and nothing from the others. Composables sit on their own entry too:

import { useTimeGridEngine } from '@primeui/vue-scheduler/composables';

#Bundle Impact

For a calendar that only shows a month, the compound import is by far the heaviest because it carries every view. Flat imports cut that down to the month view and the shared shell, and a per-view subpath trims it further to just the month engine and its outlets. The exact savings move with the features in use (recurrence, timezones, drag), but the shape holds: flat imports and subpaths drop the views that never render, while the compound import keeps all of them.

#Choosing an Import Style

The flat imports are the size-safe default and read almost as cleanly as the namespace. The compound API is fine when readability wins and the page is lazy-loaded. Per-view subpaths fit when the Scheduler is on a critical first paint and only one or two views are in use. The biggest single win is usually lazy-loading the page that hosts the Scheduler, regardless of import style.

#Related Docs

• API
• Performance