I am working on implementing a drag n' drop and resize functionality. Where a user can drag an event to a later time or drag an event to a different resource. Currently we have a REST API that stores event information like start, end, and resourceId.
I've run into a problem where if my onAfterEventDrop handler contains an API call (to sync the dropped event), the drop event fails and the event snaps back to it's prior position. If I remove the API call from the handler, the event can be dropped around as expected.
Are there some restrictions around making calls within event handlers?
const afterEventDropHandler = useCallback((params) => {
try {
if (!params.valid) {
return;
}
// this causes the event to revert to it's prior position
apiCallUpdateEvent(params);
// even if the function is async
await apiCallUpdateEvent(params);
} catch (e) {
// no errors are ever printed
console.error("error on drop", e);
}
}, []);
Hi, onAfterEventDrop is not an async function. And please check if you use the correct data on saving? if you did then, could you please provide a test case to reproduce and debug it?
Good to know, I tried both passing in sync and async handlers as well as attempting to not await my API call in hopes that a "fire and forget" async call might work.
"And please check if you use the correct data on saving?"
I'm currently accessing context. I tried eventRecords and other *Records properties but was seeing the same behavior. I did see elsewhere in the forum that we shouldn't access the private data property, so I've stayed away from using that. Here's the body of that async function:
While trying to create a minimal test case, I've discovered that there's some axios interceptor that seems to be breaking things. I'm still trying to narrow down the exact issue, but it appears to be within my code. It's still very confusing how some internal axios code could break the Bryntum event handler and abort the drop change. Maybe some weird Promise context behavior.
There's nothing in our processing of the afterEventDrop event that will revert the drop. We will need a small test case to look into the root cause of this.
Thanks for the support on this, I was able to identify an edge case race condition within my own code that was causing the behavior described above. This issue has been resolved.