Premium support for our pure JavaScript UI components


Post by sstrickland_cl »

Hey Team,

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?

Rendering Scheduler:

<BryntumScheduler
        {...schedulerConfig}
        events={events}
        resources={resources}
        timeRanges={timeRanges}
        resourceTimeRanges={resourceTimeRanges}
        onBeforeEventEdit={eventEditHandler}
        onEventResizeEnd={afterResizeHandler}
        onAfterEventDrop={afterEventDropHandler}
/>

Handler Definitions:

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);
  }
}, []);

Any help is greatly appreciated.


Post by tasnim »

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?


Post by sstrickland_cl »

  1. "onAfterEventDrop is not an async function"
    • 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.
  2. "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:
      export async function apiCallUpdateEvent(params) {
          const record = params.context;
          const update = {
              resourceId: record.resourceRecord.id,
              eventId: record.eventRecord.id,
              startDate: record.startDate,
              endDate: record.endDate,
          }
          
          await axios.put('api/path', update);
      }

Post by tasnim »

Sorry, We can not reproduce it. Could you please provide a test case so that we can debug?


Post by sstrickland_cl »

tasnim,

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.

Thanks,
Stephen


Post by sstrickland_cl »

tasnim,

I've been able to create a reproduction outside of my axios code. It seems like if the event handler takes to long, Bryntum reverts the drop change.

const afterEventDropHandler = useCallback((params: unknown) => {
  try {

    if (!params.valid) {
      return;
    }

    const func = async (): Promise<void> => {
        setTimeout(async () => {
            await fetch("https://jsonplaceholder.typicode.com/posts/1")
          }, 1000)
    };
    // this runs
    func();

  } catch (e) {
    // no errors caught here
    console.error("error on drop", e);
  }
}, []);

Post by tasnim »

Sorry, still not able to reproduce it. Could you please provide a runnable test app so that we can debug and give you the solution right away?


Post by mats »

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.


Post by sstrickland_cl »

mats and tasnim,

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.


Post Reply