[REACT] Updating timeRanges crashes if endDate is not provided in latest versions

[dpontes]

Hello Bryntum Team,

We recently upgraded from 5.3.5 to 6.1.7 and I noticed that when changing a specific the timeRange from the header's context menu we get an error in the console and also the TimeRange transforms from a single Day to a Range.

Attached the flow demonstrating the issue happening: bryntum-time-range-update-issue.png

I noticed that if I adjust the Apply logic so I also include "endDate", providing the same date as "startDate", the issue seems to be fixed. (Attached workaround)

Is this a bug or with latest changes "endDate" is actually a required field when updating a timeRange store record? The documentation is not very clear about this (attached image about the docs)

Is there a better way to update these timeRange records or the way we are doing through "record.set()" is indeed the correct approach?

Thanks!

[dpontes]

Maybe that console error is not 100% related to this timeRange issue. I've been noticing in this new version that we are getting this error actually intermittently in other cases.

We do have a check for "crudStoreHasChanges" before attempting to destructure from "crudManager.changes" (attached image).

bryntum-crud-changes-impl.png (40.09 KiB) Viewed 122 times

So I don't know why now we are intetmittently getting "null" from crudManager.changes even though "crudStoreHasChanges" returned true.

[tasnim]

Hey,

Could you please share a runnable test case so we can reproduce the issue and debug it? Or are you able to reproduce it here https://bryntum.com/products/scheduler/examples/recurringtimeranges/? If you can please share the steps that we can follow to reproduce the issue!

[dpontes]

Hello Tasnim, I attached a video demonstrating the issue for the example mentioned.

Follow also the entire code to get to that state.

import { Scheduler, DateHelper } from '../../build/scheduler.module.js?485313';
import shared from '../_shared/shared.module.js?485313';

const timeAxisHeaderMenu = {
	processItems({items, ...args}) {
		items.currentTimeLine = false;

			items.frozenWindow = {
				text : "Date frozen window",
				icon: "b-fa b-fa-fw b-fa-calendar-xmark",
				menu: [
					{
						type: "dateTimeField",
						label: "Date",
						value: new Date("2019-02-08"),
						onChange(dateField) {
                            const frozenRecord = scheduler.features.timeRanges.store.records.find(record => record?.get("name") === "Frozen");

                            frozenRecord.set({
                                "startDate": new Date(dateField.value),
                                // After upgrade, if I don't provide "endDate", my single data timeRecord will transform into a Range data.
                                // This feels wrong. If I was allowed to have my initial data to be a single Date, I should be able to keep changing only that date and maintain its single date behavior.
                                // "endDate": new Date(dateField.value)
                            })  
						},
					}
				]
			};
	}
};

const scheduler = new Scheduler({
    appendTo          : 'container',
    eventStyle        : 'colored',
    resourceImagePath : '../_shared/images/users/',

features : {
    timeRanges : {
        showCurrentTimeLine : true,
        showHeaderElements  : false,
        enableResizing: true
    },
    timeAxisHeaderMenu: timeAxisHeaderMenu
},

columns : [
    { type : 'resourceInfo', text : 'Staff', field : 'name', width : '10em' }
],

crudManager : {
    autoLoad  : false
},

barMargin : 5,

startDate  : new Date(2019, 1, 7, 8),
endDate    : new Date(2019, 1, 29, 18),
viewPreset : {
    tickWidth : 50,
    base      : 'dayAndWeek'
},

tbar : [
    {
        type    : 'button',
        ref     : 'addCoffeeButton',
        icon    : 'b-fa-coffee',
        text    : 'More coffee',
        tooltip : 'Click to add morning coffee to Thursdays too',
        onAction({ source : button }) {
            const coffee = scheduler.features.timeRanges.store.getById(1);

            coffee.recurrenceRule = 'FREQ=WEEKLY;BYDAY=MO,TH;';

            button.disable();
        }
    },
    '->',
    {
        type  : 'buttongroup',
        items : [
            {
                type    : 'button',
                icon    : 'b-icon-previous',
                tooltip : 'View previous day',
                cls     : 'navigate',
                onAction() {
                    scheduler.shiftPrevious();
                }
            },
            {
                type    : 'button',
                ref     : 'todayButton',
                text    : 'Today',
                tooltip : 'View today, to see the current time line',
                onAction() {
                    const today = DateHelper.clearTime(new Date());
                    today.setHours(5);
                    scheduler.setTimeSpan(today, DateHelper.add(today, 18, 'hour'));
                }
            },
            {
                type    : 'button',
                icon    : 'b-icon-next',
                tooltip : 'View next day',
                cls     : 'navigate',
                onAction() {
                    scheduler.shiftNext();
                }
            }
        ]
    },
    {
        type    : 'button',
        text    : 'Start',
        tooltip : 'Return to initial view',
        onAction() {
            scheduler.setTimeSpan(new Date(2019, 1, 7, 8), new Date(2019, 1, 29, 18));
        }
    }
]
});
scheduler.crudManager.inlineData = {
    "resourcesData" : [
      {
        "id"         : "a",
        "name"       : "Rob",
        "type"       : "Sales",
        "eventColor" : "green"
      },
      {
        "id"         : "b",
        "name"       : "Mike",
        "type"       : "Sales",
        "eventColor" : "green"
      },
      {
        "id"         : "c",
        "name"       : "Kate",
        "type"       : "Sales",
        "eventColor" : "orange"
      },
      {
        "id"         : "d",
        "name"       : "Lisa",
        "type"       : "Developer",
        "eventColor" : "orange"
      },
      {
        "id"         : "e",
        "name"       : "Dave",
        "type"       : "Developer",
        "eventColor" : "blue"
      },
      {
        "id"         : "f",
        "name"       : "Arnold",
        "type"       : "Developer",
        "eventColor" : "blue"
      },
      {
        "id"         : "g",
        "name"       : "Lee",
        "type"       : "Marketing",
        "eventColor" : "violet"
      },
      {
        "id"         : "h",
        "name"       : "Jong",
        "type"       : "Marketing",
        "eventColor" : "violet"
      }
    ],
      "eventsData" : [
      {
        "id"         : 1,
        "resourceId" : "d",
        "name"       : "Client Meeting",
        "startDate"  : "2019-02-11",
        "endDate"    : "2019-02-13",
        "location"   : "Some office",
        "eventType"  : "Meeting"
      },
      {
        "id"         : 2,
        "resourceId" : "b",
        "name"       : "Company outing",
        "startDate"  : "2019-02-18",
        "endDate"    : "2019-02-22",
        "location"   : "Home office",
        "eventType"  : "Meeting"
      }
    ],
    "timeRangesData" : [
      {
        "id"             : 1,
        "name"           : "Morning coffee",
        "recurrenceRule" : "FREQ=WEEKLY;BYDAY=MO;",
        "startDate"      : "2019-02-07 08:00"
      },
      {
        "id"             : 2,
        "name"           : "Friday, yay",
        "recurrenceRule" : "FREQ=WEEKLY;BYDAY=FR;",
        "startDate"      : "2019-02-07 00:00",
        "endDate"        : "2019-02-08 00:00"
      },
      {
        "id"             : 3,
        "name"           : "Frozen",
        "startDate"      : "2019-02-08 00:00",
      }
    ]
}

[alex.l]

Hi,

Thanks for the test case, here is a ticket for the issue https://github.com/bryntum/support/issues/11388
You can subscribe on ticket updates to be notified when it's done.

[dpontes]

Thanks Alex, will keep an eye on the progress of this ticket so in a future upgrade we can remove the "endDate" as a value for the record.set call.

I am guessing for now providing "endDate" seems like a safe workaround