Hi Telerik,
Just a brief heads-up, there is a listView with an endless scroll enabled. The listView is binded with a dataSource which has a custom transport.read function.
Firstly, what is a preferred approach if one would like to clear all data from the list? Calling dataSource.data([]) will remove all items, but will simultaneously completely break the endless scroll. Is there any API call which I possibly missed? (I do not know if dataSource.remove(oneModelItem) is supported in such scenarion, but anyway going through the whole dataset would be at least inefficient)
Secondly, due to the problem above I tried to delete the listview (by calling listview.destroy() and removing it's html content together with a parent nodes/wrappers) and then instantiate it again. I double checked that there is no markup left from the old listview before creating a new one. Because the first datasource had some data in it I created a new one with the same transport.read etc.
It all seemed to work, but I noticed that there are too many requests to the backend. For testing purposes I have subscribed to a requestStart event on datasources as well as added a creation timestamp to them, just to ease their identification. In such a configuration logs show that there are several dataSources requesting data from the backend even though only one (the last one) is binded with a listView.
It seems that even though a listView is destroyed binding between view's scroller and the dataSource survives. This causes problems mentioned above if a new pair of a listView-dataSource is created and binded within the same scroller instance.
It might be that I stumbled upon a bug, but it can be that I missed something as well. Any suggestions will be more than welcome.
Regards,
Przemek
@EDIT: I just realized that simple call to dataSource.read() could do the trick as it refreshes data and requests the first page even if more pages have been loaded, but it does not reset listview/scroller position. Instead, it stays at the same position and jumps after first interaction with a scroller. Sometimes, while doing this it breaks completely the listview component.
Just a brief heads-up, there is a listView with an endless scroll enabled. The listView is binded with a dataSource which has a custom transport.read function.
Firstly, what is a preferred approach if one would like to clear all data from the list? Calling dataSource.data([]) will remove all items, but will simultaneously completely break the endless scroll. Is there any API call which I possibly missed? (I do not know if dataSource.remove(oneModelItem) is supported in such scenarion, but anyway going through the whole dataset would be at least inefficient)
Secondly, due to the problem above I tried to delete the listview (by calling listview.destroy() and removing it's html content together with a parent nodes/wrappers) and then instantiate it again. I double checked that there is no markup left from the old listview before creating a new one. Because the first datasource had some data in it I created a new one with the same transport.read etc.
It all seemed to work, but I noticed that there are too many requests to the backend. For testing purposes I have subscribed to a requestStart event on datasources as well as added a creation timestamp to them, just to ease their identification. In such a configuration logs show that there are several dataSources requesting data from the backend even though only one (the last one) is binded with a listView.
It seems that even though a listView is destroyed binding between view's scroller and the dataSource survives. This causes problems mentioned above if a new pair of a listView-dataSource is created and binded within the same scroller instance.
It might be that I stumbled upon a bug, but it can be that I missed something as well. Any suggestions will be more than welcome.
Regards,
Przemek
@EDIT: I just realized that simple call to dataSource.read() could do the trick as it refreshes data and requests the first page even if more pages have been loaded, but it does not reset listview/scroller position. Instead, it stays at the same position and jumps after first interaction with a scroller. Sometimes, while doing this it breaks completely the listview component.