Inconsistent behavior when updating startDate of events

[taauntik]

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

msedge_tqB0AQCfNt.mp4

scheduler-bugs edited.zip

[jimmycallin]

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:

Skarminspelning.2024-04-08.kl.17.00.44.mov

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

[canonic-epicure]

@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]

@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]

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]

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]

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]

@jimmycallin After discussion we have opened a follow-up ticket here: #8985

[jimmycallin]

Great, thank you!

[canonic-epicure]

@jimmycallin #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]

amazing, thank you!