Upgrade guides for Calendar v6.0.0+
Calendar v6.0.0
BryntumProjectModel framework wrapper is no longer available
It was previously deprecated (in v5.6.0). Use BryntumCalendarProjectModel instead.
Angular
app.component.ts:
import { BryntumCalendarProjectModel } from '@bryntum/calendar-angular';
app.component.html:
<bryntum-calendar-project-model
#project
// Project properties
/>
React
App.tsx:
import { BryntumCalendarProjectModel } from '@bryntum/calendar-react';
...
function App() {
return (
<>
<BryntumCalendarProjectModel
ref={project}
// Project properties
/>
</>
);
}
Vue
App.vue:
<template>
<bryntum-calendar-project-model
ref="project"
// Project properties
/>
</template>
<script>
import { BryntumCalendarProjectModel } from '@bryntum/calendar-vue-3';
export default {
components : {
BryntumCalendarProjectModel
}
};
</script>
New location for Core.util.helper.Point class
The Core.util.helper.Point class was moved in v5.6.0 to solve circular module dependencies. It is now a named (Point) export of the Core.util.helper.Rectangle module.
Changes are required if you are directly importing the class from sources:
Old code:
import Point from 'path-to-lib/Core/helper/util/Point.js';
New code:
import { Point } from 'path-to-lib/Core/helper/util/Rectangle.js';
Note: No changes required for importing from module or umd bundles.
ScrollOptions renamed to BryntumScrollOptions
The name changed in v5.6.0 to avoid confusion with native ScrollOption. If you use TypeScript in your application rename imported type ScrollOptions to BryntumScrollOptions.
Old code:
import { ScrollOptions } from '@bryntum/calendar'
New code:
import { BryntumScrollOptions } from '@bryntum/calendar'
LocaleManager function removals
LocaleManager.registerLocale, which was deprecated in v5.3.0, has been removed. LocaleHelper.publishLocale should be used instead.
Old code:
LocaleManager.registerLocale('Es', {
desc : 'Spanish', locale : {
localeName : 'Es',
localeDesc : 'Spanish',
locale : {
/* localization */
}
}
});
New code:
LocaleHelper.publishLocale({
localeName : 'Es',
localeDesc : 'Spanish',
localeCode : 'es',
/* localization */
});
LocaleManager.extendLocale, which was deprecated in v5.3.0, has been removed. LocaleManager.applyLocale should be used instead.
Old code:
LocaleManager.extendLocale('Es', {
desc : 'Spanish', locale : {
locale : {
/* localization */
}
}
});
New code:
LocaleManager.applyLocale({
localeName : 'Es',
localeDesc : 'Spanish',
localeCode : 'es',
/* localization */
});
Check our localization guide for the details.
Validating CrudManager responses by default
The validateResponse flag on CrudManager was changed to default to true in v5.0.3. When enabled, it validates CrudManager responses from the backend and outputs a message on console if the format isn't valid. This is helpful during the development phase, but can be turned off in production:
const calendar = new Calendar({
crudManager : {
// Turn response validation off
validateResponse : false,
...
}
});
New module bundle for Angular
Bryntum Calendar is since V5.1.0 delivered with a ES Module bundle without WebComponents. This was done to avoid conflicts with Angular which also uses WebComponents for applications.
Angular wrappers use calendar.module.js bundle in favor of removed calendar.lite.umd.js one.
Your Angular applications should be upgraded to use the new calendar.module.js bundle which is set as main for @bryntum/calendar NPM package.
Replace all application imports from Bryntum packages as shown below:
Old code:
import { Calendar } from '@bryntum/calendar/calendar.lite.umd.js';
New code:
import { Calendar } from '@bryntum/calendar';
New module bundle with WebComponents
Bryntum Calendar is since v5.1.0 delivered with a new calendar.wc.module.js ES Module bundle with WebComponents.
Your applications which use WebComponents and modules bundle should be upgraded to import from new calendar.wc.module.js instead of calendar.module.js.
Angular View Engine wrappers for Angular 11 and older
A new @bryntum/calendar-angular-view package designed to work with Angular 11 and older versions, which use the View Engine for rendering, was added in v5.3.3. If you are using one of the legacy Angular versions, please follow these steps to use the package:
Install the package using npm:
npm install @bryntum/calendar-angular-view@6.0.0
Import the component in your Angular application:
import { BryntumCalendarComponent } from '@bryntum/calendar-angular-view';
Do not forget to remove previously used @bryntum/calendar-angular package which requires Angular 12 or newer version.
Please check Angular integration guide for additional information.
DatePicker's events property removed
The events config in the Calendar sidebar's DatePicker was renamed to showEvents in v5.1.4. The events property has been removed.
Old code:
new Calendar({
datePicker : {
events : 'count'
},
...
})
New code:
new Calendar({
datePicker : {
showEvents : 'count'
},
...
})
EventList count property deprecated
The count property was deprecated and will be removed in 7.0, use the new eventCount property instead.
Old code:
descriptionRenderer() {
return `${this.count} Events`;
}
New code:
descriptionRenderer() {
return `${this.eventCount} Events`;
}
Store now defaults to use raw data for remotely loaded data
The useRawData setting on Store is now enabled by default when data is loaded remotely using an AjaxStore or a CrudManager, but with all sub-settings disabled. This will boost load performance slightly, by not cloning the incoming data objects.
If you want to restore the previous behavior, you can set useRawData : false on the store:
const calendar = new Calendar({
eventStore : {
useRawData : false
}
});
ExternalEventSource drop events renamed.
The drop events in the ExternalEventSource feature have been renamed to conform to the wider Bryntum product standard.
In Calendar 5.x, there was a dropExternal event which was preventable which fired before the drop had been effected and an afterDropExternal which fired when the operation was complete.
In 6.x, these events are named in line with all other events, in that there is now beforeDropExternal as the preventable event before the drop is effected and the dropExternal event is fired when the operation is complete.
Old code:
listeners {
dropExternal(drag) {
// Disallow dropping on Tuesdays
if (drag.target.hit.date.getDay() === 2) {
return false;
}
},
afterDropExternal(drag) {
Toast.show(`${drag.eventRecord.name} added`);
}
}
New code:
listeners {
beforeDropExternal(drag) {
// Disallow dropping on Tuesdays
if (drag.target.hit.date.getDay() === 2) {
return false;
}
},
dropExternal(drag) {
Toast.show(`${drag.eventRecord.name} added`);
}
}
Calendar v6.1.2
Deprecated the maxDots config of CalendarDatePicker
- The
maxDotsconfig ofCalendarDatePickerhas been deprecated in favour of the neweventDotsconfig which can configure more details about the layout of event dots.
Old code:
new Calendar({
datePicker : {
showEvents : 'dots',
maxDots : 3
}
});
New code:
new Calendar({
datePicker : {
showEvents : 'dots',
eventDots : {
max : 3
}
}
});
Calendar v6.2.0
AjaxHelper.fetch credentials change
The AjaxHelper.fetch() utility function is used by AjaxStore and CrudManager to fetch data from the server. Previously it by default used the credentials: 'include' option, which meant that cookies were always sent with the request. To better match the default behavior of the native fetch API, our default value has been removed (thus it instead uses 'same-origin', which is the native default). If you want to restore the old behavior, you can do so using AjaxHelper.DEFAULT_FETCH_OPTIONS:
Old code
new CrudManager({
loadUrl : 'load.php',
autoLoad : true
})
New code
AjaxHelper.DEFAULT_FETCH_OPTIONS = { credentials : 'include' };
new CrudManager({
loadUrl : 'load.php',
autoLoad : true
})
Calendar v6.3.0
Naming simplification for project data properties
The ProjectModel can consume inline data for the different sorts of entities it supports: events, resources, assignments and time ranges.
In the past, the configs and properties related to this has been named according to [entityName]Data: eventsData, resourcesData, assignmentsData and timeRangesData.
This has been simplified to only [entityName]: events, resources, assignments and timeRanges.
The old properties are still available but are marked as deprecated and will be removed in a future release. We recommend you update the names used in your code to avoid breakage later.
Old code
const calendar = new Calendar({
project : {
eventsData : [ ... ],
resourcesData : [ ... ],
assignmentsData : [ ... ]
}
})
New code
const calendar = new Calendar({
project : {
events : [ ... ],
resources : [ ... ],
assignments : [ ... ]
}
})
This change also applies to APIs that get or set the data on the ProjectModel, such as inlineData, and json. For example:
Old code
const { inlineData } = calendar.project;
// inlineData would previously have `eventsData`, `resourcesData` etc. properties
New code
const { inlineData } = calendar.project;
// inlineData now has `events`, `resources` etc. properties.
// Note that the old properties are still included too
Calendar v6.3.2
The date property of the beforeAutoCreate event has been deprecated
Now, the startDate and endDate of the putative new event record are both passed.
Old code
const calendar = new Calendar({
listeners : {
beforeAutoCreate({ date }) {
if (date.getHours() < 9) {
Toast.show('Events may not be created before 9am');
}
}
}
})
New code
const calendar = new Calendar({
listeners : {
beforeAutoCreate({ startDate, endDate }) {
if (startDate.getHours() < 9) {
Toast.show('Events may not be created before 9am');
return false;
}
if (endDate.getHours() > 17) {
Toast.show('Events may not end after 5pm');
return false;
}
}
}
})