Vaadin 8 TreeGrid + AbstractBackEndHierarchicalDataProvider: non-lazy loadi

Hi,

Vaadin 8 suggests 2 ready-made classes as lazy loading backend data providers: AbstractBackEndDataProvider for Grid, and AbstractBackEndHierarchicalDataProvider for TreeGrid. Whenever component (Grid or TreeGrid) needs data (browsing grid, for instance), it requests the needed data from the attached DataProvider. The component passes a Query object to the DataProvider which is extended by the user. The Query object contains important information like limit & offset to fetch the desired subset or page of the result set. Having a (very) large list of data one can see that Grid + AbstractBackEndDataProvider works just fine, showing typical fast enough lazy loading behavior with reasonably small limits and shifted offsets as Query properties. But when I try TreeGrid + AbstractBackEndHierarchicalDataProvider with the same large list of data (1000-3000 rows), I observe that HierarchicalQuery object has always fixed getOffset() == 0, and getLimit() == AbstractBackEndHierarchicalDataProvider.getChildCount == “full result set size”, which is big enough. That in turn doesn’t look like lazy loading, and leads to awful response. For simplicity of testing, I set AbstractBackEndHierarchicalDataProvider.hasChildren to false, so that tree list items don’t have any children, it’s just a flat list. I’ve tried it with Vaadin 8.6.3 and 8.5.2. Has anyone else examined TreeGrid + AbstractBackEndHierarchicalDataProvider for lazy loading?

Your observation is probably related to this issue https://github.com/vaadin/framework/issues/10317

And yes, lazy loading with TreeGrid is problematic. There was attempt to optimize this (see: https://github.com/vaadin/framework/pull/10378 ), but it was rejected due regressions.

Tatu Lund:
Your observation is probably related to this issue https://github.com/vaadin/framework/issues/10317

And yes, lazy loading with TreeGrid is problematic. There was attempt to optimize this (see: https://github.com/vaadin/framework/pull/10378 ), but it was rejected due regressions.

Yes, it is exactly the issue you have mentioned (https://github.com/vaadin/framework/issues/10317), thank you!
So, summing up problems around the current underdone Vaadin Framework 8 TreeGrid, and lack of hope for its further development, I will have to look for alternatives.
I didn’t follow Vaadin Flow 10-12 development state for several months, since I faced it’s limited functionality compared to the Framework by that moment.
But I would be very grateful, if you could briefly, maybe in few words, express your competent opinion about the completeness of Flow’s Grid and TreeGrid compared to their Framework 8 analogs. If you are in this subject, of course.

Merry Christmas greetings, and a Happy New Year!

Flow’s Grid and TreeGrid will not be 100% drop in replacement for Vaadin 8 equivalents. The data binding system and API is rather similar though. There are some new features in Flow’s Grid like support for variable row heights, and on the other hand there are some features that are not (yet) there. Integrated editing functionalities are just under implementation as well as style generator. You can see main backlog items here: https://github.com/orgs/vaadin/projects/1

Tatu Lund:
Flow’s Grid and TreeGrid will not be 100% drop in replacement for Vaadin 8 equivalents. The data binding system and API is rather similar though. There are some new features in Flow’s Grid like support for variable row heights, and on the other hand there are some features that are not (yet) there. Integrated editing functionalities are just under implementation as well as style generator. You can see main backlog items here: https://github.com/orgs/vaadin/projects/1

Thank you for the information! It would be nice if you could also correct Vaadin Framework Docs at https://vaadin.com/docs/v8/framework/datamodel/datamodel-hierarchical.html which definitely states that AbstractBackEndHierarchicalDataProvider could be used together with TreeGrid for lazy data loading, which is not correct, as we have seen. Perhaps TreeGrid mentioning should be removed from that article. This would save a lot of time for developers.