Closed taauntik closed 3 months ago
Sync request may be valid here, if it includes only calculated fields, like duration, effort, etc. Because added event is not complete. However, if sync request contains this event as added, it is a problem indeed
@bmblb I believe sync request here is valid here because there is no new added event and eventStore.changes.modified[0].modificationDataToWrite
has startDate
and endDate
as they are being updated for the event. So a sync request is triggered to sync them with the backend which is totally valid as they are being changed on the frontend.
@bmblb @ghulamghousdev In your case a sync would be valid since the duration field is being updated. But in the demo i provided https://forum.bryntum.com/viewtopic.php?p=147557#p147557, I have kept the { name: "duration", persist: false }
@ghulamghousdev In my case the data is being generated on the backend and we need to sync it to the front end. for this, we are using the applyChangeSet function (as stated in the docs Core.data.Store#function-applyChangeset) but it is calling the sync request again and causing problems for us.
@muhammad-faisal101 Even if { name: "duration", persist: false }
is set, startDate
and endDate
have persist: true
and the response you are applying have different dates then the current dates of the event in the store. So that is definitely gonna trigger a sync call
. There are couple of things that you can do here is to avoid that call. You can set persist to false on both the start and end date. This is gonna make sure no sync call is triggered as no changes are going to be tracked. Another option would be to set autoSync: false
but the changes are still gonna be tracked and will be available on projectModel.changes
. You can clear those changes but there's a risk of clearing out any changes that are made during the process of applyChangeSet
. In a nutshell, this ticket is invalid.
@ghulamghousdev that would make sense. But in my case, I am manually providing the start and end date (like scheduler.project.eventStore.applyChangeset({ updated: [{ id: 1000, startDate: "2017-01-01T10:00:00+05:00", endDate: "2017-01-01T12:00:00+05:00" }] })
). Both the start and end dates are already updated on the backend. I need to make sure that the front end is updated as well.
If you look at the documentation, the applyChangeset function is used to apply changes coming from the backend. if these changes are already present on the backend, why create an API call with the same changes again?
If you look at the documentation, the applyChangeset function is used to apply changes coming from the backend. if these changes are already present on the backend, why create an API call with the same changes again?
Well both options sync
or do not sync
makes sense here. We need a callout on this from @isglass , who is on vacations this week. So I am pausing any further development on this and will discuss this with him once he's back and update the ticket accordingly.
At this point I am not even sure how applyChangeset
should behave. I can see logical explanation for both triggering and not triggering sync. Provided applyChangeset
is used by other API and should be as simple as possible, I lean a little towards keeping current behavior: everything behaves as is, problem of applying and committing changes is solved on the project level by applyProjectChanges
API, which uses this exact method.
Resolved by updating docs, pointing to applyProjectChanges
for when it should not sync any resulting changes
Forum post
To reproduce, paste the code snippet below into the scheduler pro demo code editor.
Once the demo loads, paste the below code snippet in browser's console and press return:
You will see sync request logged to the console
Video: https://www.loom.com/share/7dd8fd2a81b84a53808ce48f629afa8f