This has been driving me crazy for weeks now. I came up with a work around but didnt consider how my work around (or any) would actually work with what i'm doing.
Either way, i'm pretty sure this is an actual bug with Kendo UI as i've only just figured out it's also present in your example documentation: https://docs.telerik.com/kendo-ui/controls/scheduling/scheduler/how-to/binding/sync-with-batch
You can recreate the bug by doing the following actions:
1. Open an event
2. Cancel event
3. Reopen event
4. Select date with date picker
5. TypeError: i.wrap is not a function at line 27
8 Answers, 1 is accepted
Thank you for the reported issue, which I was able to reproduce on the how-to article sample.
The error in this case is caused by the two DataSource instances using the same observable items. Both the RemoteDataSource and the Scheduler DataSource in this case use the same events objects. This results in improper persistence of the state in case of edit cancel.
Based on you report I have logged the following GitHub issue. Depending on our priority queue, the development team will review the case in detail.
As a small token of gratitude for bringing this issue to our attention, I have updated your Telerik points.
Thank you very much for the response and the points :)
I was wondering, do you know of any work around that will allow me to use syncing with batch? It's neccessary functionality for my project.
Refreshing the dataSource in the "Cancel" event fixes the issue but i need the local state to persist until the user actually saves the whole batch (this is using AJAX/CRUD). This workaround obviously refreshes all the changes the user has made prior to clicking cancel, which is not good UX. Do you think it's viable to keep a local record of the changes made and then if the user "clicks cancel" update the local state with the stored changes.
I would much prefer to wait for a fix and it work the right way but i dont know how long this is likely to take?
Thanks again for the response & the points
I am afraid, that at this stage I won't be able to offer you a viable workaround of the discussed, that would allow you to use the two DataSources approach demonstrated on the How-to article.
What I could suggest you instead is to read all the data from the remote with a simple AJAX call, pass the data to the Scheduler DataSource as an array and manually send the entire data from the Scheduler to the server, when the Save button is clicked. Keep in mind, that such approach would have some disadvantages compared to the option to communicate with the server using a Kendo DataSource. For example, the entire data should be transferred between the client and the server on each save. Also, you won't be able to use dedicated Create, Update and Delete endpoints for the different data actions.
As per the possible fix, I won't be able to offer you an estimate of when it will be available. This highly depends on the other tasks we have in our backlog. Therefore, I would recommend you to keep tracking the GitHub issue for any updates.
I came up with a work around that is simplier than reading the datasource as an array (at least i think it's easier).
Each time an event is moved/changed i save the changed data to an array. Then if the cancel button is clicked, it refreshes the data source and then in the dataBound event i update the data Items (only the ones that are present in the array) with the changed data. I then use the refresh method to read from the local data items and move the events to the places they should be.
It appears to be working ok, but do you think this might cause any unforseen issues?
I must agree, that your suggestion is a simpler solution for the discussed case. Also, I cannot think of any issue, that might arise from such approach.
I have just raised the priority of the issue in our backlog system. I would recommend you to keep tracking the item there. The GitHub issue will be updated as soon as the enhancement is ready to ship.