Since we have implemented virtual scroll the scrolling to resource won't work because it is possible that the resource does not yet exist. As I already said once I don't see much value in the virtual scroll in our use case and think pagination would still be the better way to go.
Virtual scrolling is indeed very hard, there are more ways to make it bad than to make it good ;-)
If you go back (?) to pagination, you still need to find the right page to make scrollTo work. Then it would also be very nice to have the current page in the url, so F5 works. That leads to additional complexity when scrollTo and currentPage diverge because you are uploading files in the background. It's not that hard to handle, just something to keep in mind.
edit:
When using the back button in the browser, I find scrolling down a long list not as annoying as clicking through pages to find where I was before I navigated away, so putting the state in the url is more important to me for pagination than for virtual scrolling.
it might be possible to calculate on what page an item would be and programatically scroll down
or do it like we do in the acceptance test: scroll page, then check if the item is there, if not, continue to scroll. but might be slower due to rendering each page
also bad UX when creating a new folder "zzz" in a crowded folder but it doesn't scroll down so I need to search for the folder to actually use it.
We've decided to abandon the virtual scroll in favour of pagination
Okay, legit. Despite the virtual scroll in the title - is this ticket really out of date?
Is there a ticket where the pagination work is organized?
I would like to bring the core of this ticket up there, basically what I wrote above already:
If you go back (?) to pagination, you still need to find the right page to make scrollTo work. Then it would also be very nice to have the current page in the url, so F5 works. That leads to additional complexity when scrollTo and currentPage diverge because you are uploading files in the background. It's not that hard to handle, just something to keep in mind.
edit:
When using the back button in the browser, I find scrolling down a long list not as annoying as clicking through pages to find where I was before I navigated away, so putting the state in the url is more important to me for pagination than for virtual scrolling.
There is a set of stories in which we track the plans and value for an entirely new file list component. Goal is to have something that fulfills accessibility requirements (WCAG 2.0 compliance). E.g. full keyboard navigation is one major goal. We will also do pagination there. The work is planned for the current sprint (04.01. - 22.01.2021) and actually starts today. ;-)
Create ODS files list component
Add pagination to files list
Add sorting and filtering to files list
Bring new files list component to oc-web
The last of the four tickets also reflects the requirements to have the page in the route (page reload and bookmark capabilities). I added a requirement for the scrollTo just now. Thanks for the reminder!
Most helpful comment
There is a set of stories in which we track the plans and value for an entirely new file list component. Goal is to have something that fulfills accessibility requirements (WCAG 2.0 compliance). E.g. full keyboard navigation is one major goal. We will also do pagination there. The work is planned for the current sprint (04.01. - 22.01.2021) and actually starts today. ;-)
Create ODS files list component
Add pagination to files list
Add sorting and filtering to files list
Bring new files list component to oc-web
The last of the four tickets also reflects the requirements to have the page in the route (page reload and bookmark capabilities). I added a requirement for the scrollTo just now. Thanks for the reminder!