Release Notes 4.0.x

Release notes for 4.0

This page gives you an overview of the major changes, that came with the release of FullCalendar for Flow, version 4.0.

If you are going to update from 3.x, please also have a look into the migration guide.

If you are new to the FullCalendar or want to see, what might have changed in code, please visit our examples.

New base type JsonItem for calendar items

With this major version we introduced a new based type for calendar items (e.g. Entry). JsonItem provides a dynamic property approach, that allows defining properties via keys. Those keys provide details and rules for the automatic conversion of items from and to json.

Currently the Entry and it's subclasses implement JsonItem. Other implementations will follow in future.

See the examples page for some details.

Date Time communication changed to UTC based

While internally entries stored time values as UTC already beforehand, the communication was always based on the calendar's timezone. This led to the issue, that on a timezone change, the entries had to be resent. While this might be no problem for some use cases, other scenarios could lead to a freezing UI, when having many entries and switching the timezone.

To improve the performance here and unify the transport of times, we decided to introduce this breaking change and let the communication always be UTC based.

This means also, that custom timezones for Entries are not supported anymore as they have been before. If you used that feature, you may need to catch that missing feature in your edit forms and displayment. We apologize for that inconvenience.

Also the behavior of all day entries regarding timezones has changed. All day entries are now no longer affected by timezones.

Please see the migration guide for more details.

Changed entry data is now sent at once

In 3.x the server instance did not check, if you already sent some data to the client. Instead, it fired a java script call for every entry CRUD call. This means, that for instance calling addEntry() 20 times, the server called the respective client side api 20 times and also the calendar hat to rerender 20 times.

Starting with 4.0.x those server side data changes are collected internally and sent at once. This means, you can call the CRUD api as often as you want in a request - there will only be one call on the client side (or to be more concrete maximal 3 one for add, update and remove respectively - this may be also change in future for a more optimal handling).

Custom properties on the client side

When you customize the entry content via setEntryContent or setEntryDidMount, you may now access custom properties via a dedicated getter instead of traversing through multiple properties.

See the example page for details.

Recurrence

There are minor changes to recurrence, that most likely will need your attention regarding compiler issues. See this chapter for details.

• renamed several methods
• recurrence has some changes regarding enable recurrence and timezones

Other

Some methods have become deprecated. Please check the compiler warnings and try to replace them soon.