DataManager / UrlAdaptor always re-requests all of the data after SaveEvent?

[Mike Griffin]

After we save an event, via the dialog or drag-drop the Scheduler always calls our get-appointments endpoint and requests all of the data again, event though we reloaded the event during Save and returned it back on the response. Everything is working fine, but there is a very noticeable lag and makes this appear unprofessional due to that.

  const calendarData = new DataManager({

    url: `${BASE_API_URL}/get-appointments`,

    crudUrl: `${BASE_API_URL}/update-appointments`,

    adaptor: new UrlAdaptor(),

    crossDomain: true,

  });

We are confounded as to why this is?

Our get looks like this:

    [HttpPost("get-appointments")]
    public async Task<ActionResult<List<vwAppointment>>> 
    GetAppointments([FromBody] AppointmentParamsDto request)
    {
      // returns appointments, saves just fine
    }

our save looks like this

    [HttpPost("update-appointments")]
    public async Task<ActionResult<vwAppointment>>
    UpdateAppointments([FromBody] AppointmentSaveRequestDto request)
    {
      // saves just fine, reloads the entity from the database, and returns it just fine
    }

Still the scheduler requests all of the data, I've commented nearly every single thing out in the Scheduler until it's bare bones and it still calls "get-appointments" after Save? What does the Scheduler want me to return in the Update in order for it not to request the entire scheduler's worth of data again?

[Swathi Ravi]

Hi Mike Griffin,

Thank you for reaching out!

The behavior you're observing is due to how the Scheduler and its UrlAdaptor handle data updates. The Scheduler always re-requests data after any CRUD operation because it is designed to refresh its view completely to ensure all data is synchronized with the server. This is a built-in behavior when using the DataManager with UrlAdaptor.

Reason for Re-Requesting All Data: To ensure the data displayed in the Scheduler remains consistent with the server's updated data.

Regards,

Swathi

[Mike Griffin]

Follow up question, how can we get rid of the noticeable lag upon save, we have to hit the server, save it, and re-request it (other fields get update upon save).

It's really noticeable only upon onDragDrop(), you see a noticeable delay and flash as the appointment repaints where it used to be and then in it's new position. It would be great if it could simply repaint based on where I "let it drop"  before the data is returned and then when the async data comes back (later) just update the data internally.

[Swathi Ravi]

Mike,

The repainting of appointments occurs when using the UrlAdaptor because it fetches updated data from the backend to ensure consistency. As mentioned earlier, this behavior is designed to handle scenarios where server-side errors or data mismatches may occur, ensuring the Scheduler reflects the most accurate state.

If you want to avoid the noticeable delay caused by a full data refresh, you can opt to use local data and implement your own custom services for CRUD operations. In this case, you can update the local data directly when a CRUD action occurs, providing a smoother user experience.

Additionally, the Scheduler's actionComplete event is triggered after each CRUD operation. You can use this event to call your service and update the backend as needed, while maintaining a seamless UI by first reflecting the changes locally.