DataProvider Improvements

[pleku]

This is an epic for looking at various planned improvements for DataProvider. The list below may change and there are no guarantees on what gets done at this point, but we are looking into these things.

• [x] #8052 Unknown size for data provider / optional size query: When binding list of data into a component, I don't want to provide a size for the data as it costs too much and I would expect the component to just keep fetching more data when user scrolls until there is no more data available.
• [x] #4510 Expose fetched data from data provider:
  • When showing a listing component to the user, I need to know the current sorting and filtering so I can export exactly same data
  • When showing list of data to a user, I want to know the data set fetched by the data provider, so that I can provide controls for the user to navigate to the next/previous item
  • When using a data provider in a component, I want to easily show the size of the data set in another component because that is the UX I want
• [x] #8189 No need to learn about data provider concept to use a component / Easier creation of data providers directly from component API
• [x] vaadin/spring#388 Support for Spring Data repositories: When binding a list of data into a component, I want to be able to fetch the data based on page number & size instead of offset and limit, as that is the API I have in my backend
• [ ] #6196 Support for keyset pagination: When binding a DB table of data into a component, I want to fetch items relative to an item instead of offset, as it is much more efficient
  • This can be probably merged to use case with NoSQL backends that provide a cursor to fetch items (?)
• [ ] #6645 (partly) Better support for data addition and removal: When modifying the dataset for a component, I'd want to just remove/add rows instead of forcing a full refresh for the component since the reset causes bad UX

[knoobie]

@pleku I wasn't sure where to put this, so it landed in the epic - I was looking at the latest pr (https://github.com/vaadin/flow/pull/8550) and was wondering why some methods return the instance of the DataView instead of a simple boolean (like java.util.List does as example) - was there chaining of operation in mind? I can see why some would chain addFilter, but I can't really wrap my head around add/remove item methods, especially because you have operation that accept a single item or a list of items. Should the developer do something with the returning instance, save / overwrite his old instance(local variable) of it - that shouldn't be needed because you call refresh() on the underlying dataProvider?

[pleku]

@knoobie I have to admit we had not though about just too much - you're probably right that there is not much chaining to be done at add/remove operations. But I have to admit I'm not sure what the boolean is useful for in this case too, but it would be of course with on line with Collection API. But also the case for returning false simple add(newItem) method would be quite weird scenario and if we return boolean one might start to think about this :) (cc: @mshabarov )

[knoobie]

For example, if we look at the pr mentioned above - you can see that all methods have some kind of "error / fall back" handling (just return this) if the item isn't in the list or if one item is already in the list. This matches 100% with the javadoc of Collection::add as example Returns true if this collection changed as a result of the call. (Returns false if this collection does not permit duplicates and already contains the specified element.) -> Vaadin's DataProvider doesn't permit duplicates. You could even align with the exceptions that Collection::add uses. (I'm not a fan of exceptions, but this would also align with the Java method)

I'm a big fan of "don't reinvent the wheel" especially when there is a "proven" Java way of doing things all your users already know and feel "home" :)

You normally don't check what Collection::add returns, but if you got a bug or it's a critical application - you start to debug those cases or you go with something like this:

if(collection.add(myItem)) 
  Notification.show("All Good");
else
  Notification.show("Could not add item"); 

cc: @mshabarov because it was his pr ;)

[pleku]

The following enhancements are now to be shipped in Vaadin 17 and later on (probably) backported to Vaadin 14 LTS.

8052 Unknown size for data provider / optional size query

4510 Expose fetched data from data provider

8189 No need to learn about data provider concept to use a component / Easier creation of data providers directly from component API

vaadin/spring#388 Support for Spring Data repositories