# What's new in Scheduler Pro v5.0.0
## Events display faster
Scheduler Pro now uses a new "early render" mode by default. When data is loaded it renders events first and calculates
everything afterwards, instead of as currently the other way around. This greatly decreases time taken until events are
displayed for big data sets, but might display events at wrong positions or with wrong size if the loaded data is not
correctly normalized. In such cases, the events will transition to their correct position / size when calculations are
finalized.
You can compare the old vs new modes here:
During the calculation phase Scheduler Pro is made read-only, users are not allowed to manipulate the data until
calculations are finished. Calculation progress is displayed in a small progress bar in the time axis header
(configurable using the [projectProgressReporting](#SchedulerPro/view/SchedulerPro#config-projectProgressReporting)
config).
If you want to disable the new mode, you can do so using the [delayCalculation](#SchedulerPro/model/ProjectModel#config-delayCalculation)
config on the project.
This mode might have consequences for your application if you have code manipulating tasks after the initial load.
Please see the [Upgrade guide](#SchedulerPro/guides/upgrades/5.0.0.md).
## New resource utilization view
A new view displaying resources allocation has been added to the Scheduler Pro.
The component is similar to the [resource histogram](#SchedulerPro/view/ResourceHistogram) yet introduces
rows as a tree of resources on the root level having assignments nested.
That allows to see individual assignments allocation thus gives a more detailed representation.
Please check the [new demo](../examples/resourceutilization) demonstrating the view and
[the component docs](#SchedulerPro/view/ResourceUtilization).
## New scheduling issues handling popup
With this release Scheduler Pro starts displaying a special popup informing user of the following scheduling issues:
- _scheduling conflicts_ - when some constraints/dependencies contradict each other
- _cycles_ - when dependencies structure builds a cycle
- _calendar misconfigurations_ - when some calendar doesn't provide any working time intervals which makes its usage impossible
The popup allows user to pick a resolution for the case at hand.
Please check the [new demo](../examples/conflicts) demonstrating the popup.
Also the [project](#SchedulerPro/model/ProjectModel) throws new events for the cases that can be listened to
in order to provide a resolution programmatically:
```javascript
new SchedulerPro({
// disable default resolution popup
displaySchedulingIssueResolutionPopup : false,
project : {
listeners : {
// handle scheduling conflicts case
schedulingConflict({ schedulingIssue, continueWithResolutionResult }) {
// apply the very first available resolution
schedulingError.getResolutions()[0].resolve();
// and continue calculation w/ the Engine
continueWithResolutionResult(EffectResolutionResult.Resume);
}
}
}
});
```
Useful links:
- [displaySchedulingIssueResolutionPopup](#SchedulerPro/view/SchedulerPro#config-displaySchedulingIssueResolutionPopup) - config to disable the popup showing.
- [cycle](#SchedulerPro/model/ProjectModel#event-cycle) - event that indicates a _cycle_ has been detected.
- [schedulingConflict](#SchedulerPro/model/ProjectModel#event-schedulingConflict) - event that indicates a _scheduling conflict_ has been detected.
- [emptyCalendar](#SchedulerPro/model/ProjectModel#event-emptyCalendar) - event that indicates a _calendar misconfiguration_ has been detected.
- [SchedulingIssueResolutionPopup](#SchedulerPro/widget/SchedulingIssueResolutionPopup) - class implementing the popup to handle scheduling conflicts and calendar misconfigurations
- [CycleResolutionPopup](#SchedulerPro/widget/CycleResolutionPopup) - class implementing the popup to handle scheduling cycles.
## Inactive dependencies support in UI
Dependency model has [active](#SchedulerPro/model/DependencyModel#field-active) field which allows to deactivate it.
Inactive dependencies do not take part in the scheduling process (don't push linked tasks).
The field was represented on the data level before and this version adds its support to user interface as well.
These changes include Scheduler Pro view where inactive dependencies are displayed dashed now.
Also new `Active` field has been added to the [dependency editor](#SchedulerPro/feature/DependencyEdit).
## Dependency editor "Lag" field has been made visible by default
`Lag` field has been made visible in the [dependency editor](#SchedulerPro/feature/DependencyEdit) by default.
## New JavaScript bundles for combining products
Each product now has a new ES module based JavaScript bundle that only contains the product specific code, called a
`thin` bundle. They are intended to be used when combining multiple products on page, to avoid having shared code loaded
multiple times. Previously if you combined for example `Grid` and `TaskBoard` on a single page you would import from
these bundles (minified size):
* `grid.module.min.js` (~993 kB)
* `taskboard.module.min.js` (~1100 kB)
Both products are built upon Bryntum's core library and hence both of them include the core JavaScript (buttons,
toolbars, helpers etc.). With `thin` bundles you would instead import what you need from each product in the hierarchy
separately:
* `core.module.thin.min.js` (~643 kB)
* `grid.module.thin.min.js` (~268 kB)
* `taskboard.module.thin.min.js` (~88 kB)
This way the shared code (from core) is only included once. With the old approach, about 2 MB of JavaScript was loaded,
with the new about 1 MB.
The gain (loss actually) will be greater if you combine products that share even more code, like `Gantt` and
`Calendar`. `Calendar` builds upon `Scheduler > Grid > Core`, while `Gantt` builds upon `Scheduler Pro > Scheduler >
Grid > Core`. When not using `thin` bundles:
* `gantt.module.min.js` (~1978 kB)
* `calendar.module.min.js` (~1833 kB)
With `thin` bundles (many since these products build upon others):
* `core.module.thin.min.js` (~643 kB)
* `grid.module.thin.min.js` (~268 kB)
* `scheduler.module.thin.min.js` (~466 kB)
* `schedulerpro.module.thin.min.js` (~119 kB)
* `engine.module.thin.min.js` (~266 kB)
* `gantt.module.thin.min.js` (~122 kB)
* `calendar.module.thin.min.js` (~164 kB)
Total ~ 3811 kB vs 2048 kB (1763 kB less).
You import from the thin bundles in the same way as with any other ES modules bundle. The difference compared to using
the full bundles is that you have to import from the correct bundle. For example to use the `StringHelper` class from
Core and `GridRowModel` from Grid, previously you would have something similar to this:
```javascript
import { StringHelper, GridRowModel } from 'grid.module.js';
```
Now you have to import them separately (since they are from different bundles):
```javascript
import { StringHelper } from 'core.module.thin.js';
import { GridRowModel } from 'grid.module.thin.js';
```
## New CSS bundles for combining products
Each theme now has a new CSS bundle that only contains product specific styling, called a `thin` bundle. They are
intended to be used when combining multiple products on page, to avoid having shared styling loaded multiple times.
Previously if you combined for example `Grid` and `TaskBoard` on a single page, using the Stockholm theme, you would
load:
* `grid.stockholm.css` (~244 kB)
* `taskboard.stockholm.css` (~243 kB)
Both products are built upon Bryntum's core library and hence both of them include the core CSS (buttons, toolbars,
icons etc.). With `thin` bundles you would instead load each product in the hierarchy separately:
* `core.stockholm.thin.css` (~203 kB)
* `grid.stockholm.thin.css` (~40 kB)
* `taskboard.stockholm.thin.css` (~40 kB)
This way the shared CSS (from core) is only included once. With the old approach, about 487 kB of CSS was loaded, with
the new about 283 kB (204 kB less).
The gain (loss actually) will be greater if you combine products that share even more styling, like `Gantt` and
`Calendar`. `Calendar` builds upon `Scheduler > Grid > Core`, while `Gantt` builds upon `Scheduler Pro > Scheduler >
Grid > Core`. When not using `thin` bundles:
* `gantt.stockholm.css` (~659 kB)
* `calendar.stockholm.css` (~655 kB)
With `thin` bundles (many since these products build upon others):
* `core.stockholm.thin.css` (~203 kB)
* `grid.stockholm.thin.css` (~40 kB)
* `scheduler.stockholm.thin.css` (~363 kB)
* `schedulerpro.stockholm.thin.css` (~10 kB)
* `gantt.stockholm.thin.css` (~27 kB)
* `calendar.stockholm.thin.css` (~47 kB)
Total ~ 1314 kB vs 690 kB (624 kB less).
In your html file, you would for the `Gantt` + `Calendar` scenario have something similar to:
```html
```
Note the usage of the data-bryntum-theme attribute above, it is required if the app will be switching theme
at runtime using DomHelper.setTheme().
## New feature - [Event buffer](#SchedulerPro/feature/EventBuffer)
In this release we have added a new feature called EventBuffer, which is sometimes referred to as travel time. It allows
to render a visual element before and after event element, representing time required to prepare for the event and to
clean up after it. For example, before an employee can start working on the site, one has to arrive to the site first.
Please refer to the [travel time](https://bryntum.com/products/schedulerpro/examples/travel-time/) demo.
```javascript
new SchedulerPro({
features : {
eventBuffer : true
},
project : {
eventsData : [
{
id : 1,
startDate : '2010-01-01',
endDate : '2010-01-02',
preamble : '1 hour'
},
{
id : 2,
startDate : '2010-01-01',
endDate : '2010-01-02',
postamble : '15 minutes'
}
]
}
});
```
## NonWorkingTime and ResourceNonWorkingTime elements can now be styled easily
In this release, you can now set a `cls` field on the calendar data (or on the data of its intervals). This adds a CSS class
on the rendered non-working time interval which you can use for styling. You can additionally show an icon by setting `iconCls`.
Please refer to [ResourceNonWorkingTime docs](#SchedulerPro/feature/ResourceNonWorkingTime) for more information.
Sample code:
```javascript
const schedulerPro = new SchedulerPro({
appendTo: document.body,
height: 500,
startDate: new Date(2022, 7, 2),
endDate : new Date(2022, 7, 14),
columns: [
{ field: 'name', text: 'Name' },
{ field: 'calendar', text: 'Working on', editor: false },
],
features: {
nonWorkingTime : true,
resourceNonWorkingTime: {
maxTimeAxisUnit: 'week'
}
},
project: {
resourcesData: [
{ id: 1, name: 'Bernard', calendar: 'weekends' },
{ id: 2, name: 'Bianca', calendar: 'weekdays' }
],
calendarsData: [
{
id : 'weekends',
name : 'Weekends',
unspecifiedTimeIsWorking: true,
cls : 'weekendCalendar',
intervals : [
{
recurrentStartDate: 'on Mon at 0:00',
recurrentEndDate : 'on Sat at 0:00',
isWorking : false,
cls : 'nonworking'
}
]
},
{
id : 'weekdays',
name : 'Weekdays',
unspecifiedTimeIsWorking: true,
intervals : [
{
recurrentStartDate: 'on Sat at 0:00',
recurrentEndDate : 'on Mon at 0:00',
isWorking : false,
cls : 'weekend'
}
]
}
]
}
});
```
## Simplified test case creation
When reporting a hard to reproduce issue on Bryntum's support forum we often request a test case showing the issue.
Getting a good test case greatly reduces the time it takes from reporting the bug until a fix can be released. Worst
case we won't be able to find and fix the bug at all without one.
We understand that for complex apps it is not always trivial to produce a standalone test case. The app might be using
a lot of different configs and the issue might only appear with a certain dataset etc. To simplify the process of
creating a test case we have added a new function called `downloadTestCase()` to all Bryntum products. Running it
collects the current value for the configs your app is using, inlines the current dataset and compiles configs and data
into a JavaScript app that is then downloaded.
The app will most likely require manual tweaking before you can submit it to us, but we are hoping it will make creating
a test case easier for you. Run `schedulerPro.downloadTestCase()` on the console in a demo to try it. Any feedback on how
this could be improved further is welcome on the forums!