Closed taauntik closed 7 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!
@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 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 theendDate
value is the same. And mutating thestartDate
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?
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.
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.
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.
@jimmycallin After discussion we have opened a follow-up ticket here: https://github.com/bryntum/support/issues/8985
Great, thank you!
@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.
amazing, thank you!
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