# What's new in Scheduler Pro v5.6.0

## New npm packages for combining products

This release introduces a new set of npm packages and framework components, that allows combining multiple Bryntum
products in the same application.

These packages contain the product specific code only, as opposed to the current packages that has all code for the
products each product builds upon (for example Scheduler contains all code from Grid & Core).

The new packages are called `thin` packages, and moving forward it will be the recommended way of using Bryntum
products in npm based applications (for all supported frameworks). The packages are initially available for licensed
users only, but will be made available for trial users in the near future.

The following packages are available:

| Package                    | Purpose                                     |
|----------------------------|---------------------------------------------|
| @bryntum/core-thin         | Bryntum Core data and UI components package |
| @bryntum/grid-thin         | Bryntum Grid component package              |
| @bryntum/scheduler-thin    | Bryntum Scheduler component package         |
| @bryntum/schedulerpro-thin | Bryntum Scheduler Pro component package     |
| @bryntum/gantt-thin        | Bryntum Gantt component package             |
| @bryntum/calendar-thin     | Bryntum Calendar component package          |
| @bryntum/taskboard-thin    | Bryntum TaskBoard component package         |
| @bryntum/engine-thin       | Bryntum Scheduling engine component package |

Applications should install packages for the products they use, and the products those are built upon (see links to
guides below for more information). For example an application using Scheduler Pro should also install Scheduler, Grid &
Core:

```bash
npm install @bryntum/core-thin @bryntum/grid-thin @bryntum/scheduler-thin @bryntum/schedulerpro-thin
```

There are also new corresponding wrappers for the supported frameworks, which should be used instead of the current
wrappers. For example for React:

| Package                          | Purpose                                        |
|----------------------------------|------------------------------------------------|
| @bryntum/core-react-thin         | Bryntum Core UI widgets React wrappers package |
| @bryntum/grid-react-thin         | Bryntum Grid React wrapper package             |
| @bryntum/scheduler-react-thin    | Bryntum Scheduler React wrapper package        |
| @bryntum/schedulerpro-react-thin | Bryntum Scheduler Pro React wrapper package    |
| @bryntum/gantt-react-thin        | Bryntum Gantt React wrapper package            |
| @bryntum/calendar-react-thin     | Bryntum Calendar React wrapper package         |
| @bryntum/taskboard-react-thin    | Bryntum TaskBoard React wrapper package        |

Applications should install wrappers **only** for the products they use, there is **no** need to install them for the
products those are built upon. For example an application using Scheduler Pro:

```bash
npm install @bryntum/schedulerpro-react-thin
```

More information:
* [Multiple products in Angular](#SchedulerPro/guides/integration/angular/multiple-products.md)
* [Multiple products in React](#SchedulerPro/guides/integration/react/multiple-products.md)
* [Multiple products in Vue](#SchedulerPro/guides/integration/vue/multiple-products.md)

## Nested events scheduled relative to parent

Prior to this release, nested events were positioned relative to their parent event initially, but when the parent was 
moved in a way that made it intersect non-working time the relative position was lost. 

For example if a parent event on a Monday with one nested event on Tuesday and one on Wednesday was moved to a Friday, 
the nested events was both pushed to directly after the weekend, to Monday. Thus loosing their relative position. From 
the scheduling engines point of view this was the right decision, it scheduled them as early as possible. But from the 
users point of view it was not, the relative position was expected to be kept.

With this release this behaviour has changed, nested events are now scheduled relative to their parent. This is 
implemented using a new `delayFromParent` field on the `EventModel`. The field is calculated based on the parents start 
date and the nested events start date when not supplied (making it optional to specify), subtracting non-working time. 

Behind the scenes this is enforced similarly to using a `startnoearlierthan` constraint on the nested events.

We consider the old behaviour a "bug", but if you were relying on it please let us know.

## Dependencies between nested events

This release also adds support for dependencies between nested events (nested -> nested, parent -> nested & nested ->
parent). A dependency is allowed to schedule a nested event later than its `delayFromParent`, but not earlier.


## Functions and events declarations for TypeScript have been improved

Declarations of class config/property functions and events (which are represented as **onEventName** functions) were
improved to contain all available parameters and return type.

See examples below:

**Old declarations:**

```typescript
    /**
     * User typed into the field. Please note that the value attached to this event is the raw input field value and
     * not the combos value
     */
    onInput: Function|string

    /**
     * Template function that can be used to customize the displayed value
     */
    displayValueRenderer: Function
```

**New declarations:**

```typescript
    /**
     * User typed into the field. Please note that the value attached to this event is the raw input field value and
     * not the combos value
     */
    onInput: ((event : { source: Combo, value: string, event: Event }) => void)|string

    /**
     * Template function that can be used to customize the displayed value
     */
    displayValueRenderer: (record: Model, combo: Combo) => string|null
```


## Client side print / PDF export

A new [Print feature](#Scheduler/feature/export/Print) was added to allow printing Scheduler Pro content using the
browser print dialog. It extends the [PDFExport feature](#Scheduler/feature/export/PdfExport) and uses same configs
which manage HTML markup rendering (exporters, columns, paper size, etc.). The only difference is that instead of
sending generated HTML to a backend, the feature creates an iframe element with generated content and opens the browser
print dialog from it.


<p class="last-modified">Last modified on 2023-10-26 8:19:27</p>