# What's new in Gantt v5.0.0
## Tasks display faster
Gantt now uses a new "early render" mode by default. When data is loaded, it is rendered immediately based on the raw
data. After the initial rendering, the data normalization phase begins and the scheduling engine calculates the whole
schedule (incl. adjusting any "dirty" data). This early rendering greatly decreases the time taken until tasks are
displayed for big data sets, but might display tasks at wrong positions or with wrong size if the loaded data is not
correctly normalized. In such cases, the tasks will transition to their correct position / size as soon as the
calculations are finalized.
You can compare the old vs new modes here (and in the new `early-render` demo):
During the calculation phase, the Gantt chart is made read-only, users are not allowed to manipulate the data until
calculations are finished. The calculation progress is displayed in a small progress bar in the time axis header
(configurable using the [projectProgressReporting](#Gantt/view/Gantt#config-projectProgressReporting) config).
If you want to disable the new mode, you can do so using the [delayCalculation](#Gantt/model/ProjectModel#config-delayCalculation)
config on the project.
This new mode might have consequences for your application if you have code which manipulates tasks after the initial
load. Please see the [Upgrade guide](#Gantt/guides/upgrades/5.0.0.md).
## New resource utilization view
A new view displaying resources allocation has been added to the Gantt.
The component is similar to the [resource histogram](#SchedulerPro/view/ResourceHistogram) and shows resources in a
tree, 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 the Gantt 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](#Gantt/model/ProjectModel) throws new events for the cases that can be listened to in order to
provide a resolution programmatically:
```javascript
new Gantt({
// disable default scheduling resolution popup
displaySchedulingIssueResolutionPopup : false,
project : {
// 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](#Gantt/view/Gantt#config-displaySchedulingIssueResolutionPopup) - config to disable the popup showing.
- [cycle](#Gantt/model/ProjectModel#event-cycle) - event that indicates a _cycle_ has been detected.
- [schedulingConflict](#Gantt/model/ProjectModel#event-schedulingConflict) - event that indicates a _scheduling conflict_ has been detected.
- [emptyCalendar](#Gantt/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](#Gantt/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).
## 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().
## Tree grouping
Gantt has a new [TreeGroup](#Gantt/feature/TreeGroup) feature that can transform a task tree structure at runtime. It
accepts an array of field names or functions that output a value, which it uses to create and populate the parent tasks
in the tree. Comes with a new demo, [grouping](https://bryntum.com/products/gantt/examples/grouping/).
Try it out in the live demo here:
## Pinning dependencies during drag drop/resize
Gantt allows to drag and resize task with outgoing dependencies while keeping successors in place. If you enable
[pinSuccessors](#Gantt/feature/TaskDrag#config-pinSuccessors) config on the feature and drag/resize task while holding
CTRL key, lag on the outgoing dependencies will be recalculated so successors are not moved.
## 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 `gantt.downloadTestCase()` on the console in a demo to try it. Any feedback on how
this could be improved further is welcome on the forums!
## Auto-saving state
Gantt allows persisting state changes automatically. See new [state](https://bryntum.com/products/gantt/examples/state/)
demo. Resize columns, rearrange them, sort or filter the store and after refresh application state will be restored, no
special action is required.
## ProjectModel wrapper for Angular, React & Vue
Gantt ships with a new `ProjectModel` wrapper that can be used to share data between multiple Bryntum components in the
same app by pointing them all to the same project instance. Either you use it to load data from the backend using the
built-in `CrudManager` or you bind your locally available data to it.
Integration details can be found in guides for
[Angular](#Gantt/guides/integration/angular/data-binding.md#binding-existing-data-to-the-project),
[React](#Gantt/guides/integration/react/data-binding.md#binding-existing-data-to-the-project) and
[Vue](#Gantt/guides/integration/vue/data-binding.md#binding-existing-data-to-the-project).