Changing resource collection causes events refresh (additional API call)

[Eugene]

Hello dear support team.

I use Scheduler component with resources - employees.

Every time when selected date is changed I need to add/remove employees that are working/not working this day.

I use removeResource/addResource methods which do the job.

However changes to resource collection causes events reloading - call to API.

As a result when selected date is changed I have 2 identical calls to API. First is caused by changing date, second - by changes in resource collection.

Switching days in schedule component becomes very slow.

Please suggest the way of manipulating resource collection without additional calls to API.

For events I use WebApiData adaptor

For resource collection I use local json array as data source.

I tried to look at query option in ResourceDirective but it does not seem to be possible to capture new date every time it changes.

Thanks for help in advance.

[Balasubramanian Sattanathan]

Hi Eugene,  

Greetings from Syncfusion Support  

We have validated your reported scenario and checked the possibility of preventing the API call on adding the resources dynamically at our end. We regret to let you know that “manipulating resource collection without additional calls to API.” is not feasible with our Scheduler’s current architecture. Because while adding/removing dynamic resources it will re-renders the entire scheduler. So it will call the API again which is the default behavior of the Scheduler.

And kindly share the below details to check the reported “Switching days in schedule component becomes very slow.” scenario at our end. 

• Share the scheduler package version
• Share scheduler related code snippet
• Which view you have faced this problem?
• How many resources and events are rendered in the corresponding view?

Please let us know if you need further assistance. We will happy to assist you.  

Regards, 

Balasubramanian S 

[Eugene]

Hello

Thank you for reply,

In my case scheduler UI becomes slow because API call is time consuming itself (latency and other reasons that are not related to Scheduler component). 

Since API call that happens on resource collection change is the same as for date change I thought that it's kind of redundant and could just render the component with same data source.

Another related problem that makes UX poor when API calls are slow is following:

* I drag an event and drop it

* Event disappears (get hidden) from the scheduler until update API call and Refresh API call are completed

When update and refresh calls take some time use is a bit confused because event is neither on new position nor on old position.

I understand the need for 2 calls here but to improve UX what can be done is that you do not hide event, instead you leave it on newly dragged position.

What do you think? Does it make sense and easy to implement?

[Balasubramanian Sattanathan]

Hi Eugene, 

Thanks for the reply. 

We have checked your reported scenario at our end and let you know that scheduler is connected with a remote API call, when we perform drag and drop action, the dropped element has been moved to its original state until the post API got the success, it will be refreshed in the Scheduler otherwise, it will not refresh when the API call got failed. 

If we misunderstood the requirement, kindly share the below details to validate the defect you are facing at your end and proceed further, 

• Share scheduler related code snippet
• In which view you have faced this problem?
• How many resources and events are rendered in the corresponding view?
• Share an issue reproduced sample(if possible) which would help us to validate the issue and provide a prompt solution at the earliest.

We are waiting for your response to serve you better. 

Regards, 

Balasubramanian S 

[Eugene]

Hello

Yes, if API call will fail then state will not be correct. And I believe there are at least 2 options:

1. Just accept the fact that if update API call fails then refresh is needed and it is up to error handling logic. This is incomparably small compromise when it comes to UX for happy flow. I believe most of developers will choose better UX with some more logic in error handling code

2. More complicated but still feasible way: remember old state of the event and revert to it when API call for update fails.

I would vote for #1

I would like to once again emphasize the importance of this problem. When components in used in SaaS applications, deployed in cloud, the problem of latency is actual.

There were other threads on this forum that complained about exactly same problem.

Thank you in advance

[Balasubramanian Sattanathan]

Hi Eugene, 

Thanks for the details. 

We have checked your required scenario at our end and let you know that if the CRUD action getting failed, the events will go back to their old state by default. And if you would like to handle the CRUD action errors, you can use actionFailure event at your end. Because it will be triggered when the CRUD actions got failed. We have prepared a sample for your reference which can be available from the below link. 

https://stackblitz.com/edit/react-remove-resources-webapi-action-failure?file=index.js 

Here is the video demo that works as expected. 

https://www.syncfusion.com/downloads/support/forum/162678/ze/video_demo664469753.zip 

Please try the above sample if you still face the problem “appointments not go back to original place if the action fails”, share the issue replicating sample or code snippet or replicate the issue in above sample. 

Regards, 

Balasubramanian S