bryntum / support

An issues-only repository for the Bryntum project management component suite which includes powerful Grid, Scheduler, Calendar, Kanban Task Board and Gantt chart components all built in pure JS / CSS / TypeScript
https://www.bryntum.com
54 stars 6 forks source link

Inconsistent behavior when updating startDate of events #8720

Closed taauntik closed 7 months ago

taauntik commented 8 months ago

Forum post

Hi!

We see some inconsistent behavior when updating the startDate of events while providing a specific endDate.

As you can tell by the screen recording, we have two main issues that it showcases:

When providing both startDate and endDate, and I update the startDate, I expect the duration to change according to the new startDate. When updating startDate and toggle back and forth with segments, I expect the event to not suddenly turn into a milestone and disappear

Please see recording and example app


Please read the desc from client above to understand the issue

Please check the video to reproduce the issue with the attached react app

https://github.com/bryntum/support/assets/75997756/91e1f1da-6082-44df-8a63-d339787b3349

scheduler-bugs edited.zip

jimmycallin commented 6 months ago

Hi!

I just updated to 5.6.9, and I'm still noticing the first issue:

When providing both startDate and endDate, and I update the startDate, I expect the duration to change according to the new startDate.

Please see screen recording:

https://github.com/bryntum/support/assets/2225828/c88458cb-f4d1-4b0d-a832-9ed88fdf90fb

The second issue seem to be resolved though, good job!

canonic-epicure commented 6 months ago

@jimmycallin Hi, this issue is caused by the general approach you are using, which is to sync the dataset (instead of using the API calls).

In this case you provide a JSON dataset to the store, which is then updated dynamically. When applying this dataset, a diff is performed (syncDataOnLoad option) and only the actually changed pieces of data are aplied.

In this case, only a change for startDate is applied, since the endDate value is the same. And mutating the startDate results in the task move, instead of resize.

jimmycallin commented 6 months ago

@jimmycallin Hi, this issue is caused by the general approach you are using, which is to sync the dataset (instead of using the API calls).

In this case you provide a JSON dataset to the store, which is then updated dynamically. When applying this dataset, a diff is performed (syncDataOnLoad option) and only the actually changed pieces of data are aplied.

In this case, only a change for startDate is applied, since the endDate value is the same. And mutating the startDate results in the task move, instead of resize.

I don't understand, if the change in startDate is applied, with no change in endDate, why are you assuming the duration is consistent?

canonic-epicure commented 6 months ago

This is what commonly expected (for example what MS Project does in this case). In contrast, when you update the endDate, by default it results in task resize, instead of move.

See the keepDuration flag here and here

jimmycallin commented 6 months ago

This is what commonly expected (for example what MS Project does in this case). In contrast, when you update the endDate, by default it results in task resize, instead of move.

See the keepDuration flag here and here

Ok, I see.

But do you agree that this is a bug with your implementation? If I provide both a startDate and endDate, and I update the startDate by providing updated data to your React component, I expect the scheduler to correctly display the event with the provided startDate and endDate. I understand the implementation details that cause the current behavior, but if I can't rely on the scheduler correctly displaying the provided data most of the purpose of using your provided react components disappear.

canonic-epicure commented 6 months ago

I don't think its a bug per se, since the endDate is not actually provided as a change, only the startDate. This is the drawback of the "data-sync" approach, instead of using the API calls. In theory, data-sync should have the same outcome, however, to be efficient, only the diff is applied, which looses the information about the endDate.

You can try to fix this by setting syncDataOnLoad on eventStore to false - this will perform the full update though.

isglass commented 6 months ago

@jimmycallin After discussion we have opened a follow-up ticket here: https://github.com/bryntum/support/issues/8985

jimmycallin commented 6 months ago

Great, thank you!

canonic-epicure commented 6 months ago

@jimmycallin https://github.com/bryntum/support/issues/8985 has been merged to the repo, we've applied a workaround, that startDate/endDate/duration fields are always applied from the sync data package, regardless of their diff status. You can verify the fix in the tomorrow nightly or in the 5.6.10 release.

jimmycallin commented 6 months ago

amazing, thank you!