Pagination on Return via Browser

General
21

@SimonMartinelli this will work only, until i am on the first page.

I have changed the check, to check for the items ID

 @Override
    public void afterNavigation(AfterNavigationEvent event) {
        if (vaadinSessionData.getSelectedOrderEntity() != null) {
            OrderEntity orderEntity = vaadinSessionData.getSelectedOrderEntity();
            Stream<OrderEntity> items = entityGrid.getGenericDataView().getItems();
            AtomicInteger i = new AtomicInteger();
            int index = items.peek(v -> i.incrementAndGet()).anyMatch(itm -> itm.getId()==orderEntity.getId()) ? i.get() - 1 : -1;
            entityGrid.scrollToIndex(index);
            entityGrid.select(orderEntity);
        }
    }

That wont work, it works only on the first page of entities, but as soon as i scroll (and lazily load) the next 50 i will be positioned on page 1 when i go back to the overview, after i opened an item from page 2

22

Can you create a reproducible example?

23

Unfortunately not that easy to provide an example.

I had yesterday a working solution, but this also was kind of “dirty”. The grid has 220.000 items (lazily loaded á 50 per page)

When a user scrolls all the way down to page 50 and opens an item and goes back, than the loading indicator was visible 50 times, that was too much loading time.

Now i have implemented the solution with the additional query and the behaviour is way better. The loading indicator popsup only once and it jumps directly to the correct page. I think this is like @Leif mentioned, the better solution for heavy loads

24

The grid knows (internally at least) the “index” of the item when the row is rendered. If that could be cached somehow, the DB query wouldn’t be needed :thinking: Either internally (then could re-use the grid, e.g. UI or route scoped) or with some API.

25

How about adding something like Optional<Integer> getVisibleItemIndex(T item) in LazyDataView? The idea would be that the data view can know the exact index for items in the pages that it currently has loaded in memory (i.e. “visible” items plus a little bit of scrolling buffer), while the Optional signals that there’s always a risk that it’s not known.

26

That would probably make it easier to optimize at least. On the otherhand, now that I think about it bit more, one could already do it yourself pretty easily in the paging callback (with some weak map or an actual caching solution) :thinking:

27

I understand the problem now. In my case the users never scroll down but rather filter when they don’t find the data in the first few pages. Means there are never thousands of results.

28

I think this is more common case (or then there is other issues in the UX). This is also the reason why I think this newish API that forces one to write that custom index searching functionality is premature optimisation and should only be opt-in instead.

1 Like
29

But the problem without index query would also occur, if a user scolls down just a few pages. Hm i think it depends on the user and app which way to go.

No user scrolls a lot pages, if he can use a filter - but on the other hand - the expected behavior is to scroll to the correct index when i am on page x, enter an item and go back to the overview. If you then gets forwarded to the first page or false index, its a mess for the user, thats unexpected behavior and frustating.

So at the end: there is a solution with the addional query which works quite fast and reliable. So i dont see a reason to force the developer to implement the index functionality.

Hopefully the testing team see it the same way :nerd_face:

1 Like