-
Notifications
You must be signed in to change notification settings - Fork 4.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for automatically iterating paginated resources in core-data #6180
Comments
@WordPress/gutenberg-core Could I get some direction on how you'd like to handle this? It appears I see |
Playing devil's advocate: What if there are 1000 users? 10,000 users? Is making dozens of API requests when the sidebar opens acceptable? I'd prefer that we build e.g. a generic component that replaces |
Two points:
|
We are slowly deprecating |
I don't think we want to continuously load in the background for resources which may or may not ever be needed for how the user plans to interact with the current editor session. For something like the author selector, I see it working as a component which loads an initial set of options, then more only in response to:
There are a few side considerations here:
You can see some of these ideas in action here: https://bvaughn.github.io/react-virtualized/#/components/InfiniteLoader Other prior art:
As far as generalization, I agree concepts of pagination and querying should be built-in to Other prior art: |
What accessibility concerns are there with this approach? cc @afercia
If this proves to be significantly greater level of effort than simply loading all of the user and term data into scope, would you be open to doing the simple implementation first? |
It will be a significantly greater level of effort 😄 As for iterations, only my standing hesitation of contentment with mediocrity. |
I understand. As it exists now though, the current implementation is a blocking bug. Furthermore, I'm concerned there are unknown accessibility issues with the lazy-load approach. I don't know the full history of why Select2 has been so difficult to introduce. |
I might imagine if it's considered an in-place substitute for † Also makes me wonder if we should have such behavior when starting to enter text while navigating listed block options in the inserter. |
Sure, this is precisely how mediocre happens. There's a sense of urgency when a thing is completely unusable, as exists here today. This urgency is lost when a "not good, but tolerable" solution is implemented. This is a trade-off, of course; the simplest solution is often more immediately achievable. But it leaves a good probability that it will remain this way forever. I am not saying one way or the other is "right", and is dependent on the circumstances. I think this is the time where someone chimes in with a favorite mantra of lazy development "perfect is the enemy of good". 😉 |
Just so it's stated, I'm not going to enter this debate. |
Obviously, paginating through the output of these endpoints is a less than an ideal solution. I'd love to see a lazy loader solution for this, but there have been significant challenges in the past. As @danielbachhuber Select2 was investigated, but it had significant accessibility issues. Since then, the Woo team have created SelectWoo, which has a focus on accessibility, so may be worth exploring. That said, investigating either of these will require a significant amount of work to ensure they're a good long term option, I would place this firmly as a stretch goal for 5.0, at best. In the mean time, I have no problem solving this by automatically iterating over paged endpoints. Particularly with the preloading support added in #6076, I wouldn't expect this to add any significant load to the server, beyond what the Classic Editor already does. |
Reiterating my own points from today's discussion in core-editor Slack:
|
The accessibility team already tested it a few months ago, we were pinged by the developer working on it. Although there are some improvements, it's still not sufficient from an accessibility perspective, especially when it comes to dynamically adding new sets of results.
I won't repeat the a11y issues already described on #5921 (comment) but yeah, infinite scrolling is also an usability issue. It gives the illusion to solve a problem, but are we really sure it really does it? A good UI should just give users the necessary information to operate on the UI, not lead to a sense of loss of control, and not cause frustration. I see infinite scrolling as something that developers like more than users 🙂 It's a pattern that was vastly experimented in the past but today a quick search for |
Thanks for the extra feedback, @afercia! The variations of this problem are fairly obviously quite difficult, I don't believe that an infinite scroll solution is viable (or necessary) for merge. After chatting to @danielbachhuber earlier, I believe that a combination of things will provide a reasonable fix:
|
I'll take a swing at what it would take to support |
Would an adequate search/input like an autocomplete not be a more developer friendly solution than paging over data? Doesn't React have an autocomplete frontend component? If there is a component for autocomplete, then is it not a case of defining a custom render & fetch method? (I clearly need to find more time to play with it) Iterating would take orders of magnitude more time on sites where for example I Have a customer that has quite a small e-commerce site. They still have > 2500 users (most are customers), which even with a pagination size of 100 entries is 25 scroll interactions, it's 250 at a page size of 10. I've just tested using the following bookmarklet / console scripts Add a page every second
visiting /wp-admin/edit.php?post_status=publish&post_type=page I can see it creates 500+ pages, all published visiting /wp-admin/post-new.php?post_type=page and running the following content script Count pages in side-bar of Gutenberg parent page
shows 101 (no matter how many pages I add. Fundamentally I'd expect the UI patterns and user-experience for a site with 2500 entries for a dropdown to be different to that of a smaller database with dozens, or hundreds of records to avoid lots of visual scanning over what would be from this image quite busy. Sites that are even larger, I'd imagine would hit a point, where there were too many pages or posts.
I was talking about the existing behaviour with @mikelittle at WordCamp London RE: sites with a lot of pages and the pages dropdown in admin (similar issue as getting all users with > 1000) is the page sidebar, where you can select a parent page, which at present from above tops-out at 101 in gutenberg for top-level pages. It's a problem I've encountered in other software projects. I'll admit I'm lazy up-front, so I always reach for an auto-complete, with select semantics (double-click searches and needs a special case). I'm not sure how it would work with React or WP_Query server-side (mine uses jQuery UI Autocomplete), but I've never had a complaint (scanning is moved to the DB). |
As an alternative to only infinite loading, what about skip to specific page using prev-next and a It doesn't rule-out an infinite loader as well as manual prev-next and paging controls, but the numerical selection could become a browser native number box with minimum, maximum. |
@Lewiscowles1986 whilst a possibility I think we need to avoid such complicated visual interfaces as you suggest. That's a lot of things going on in one place. This is where combining autocomplete and infinite scroll, when done well (there are numerous bad examples) can hit the right spot. It's worth noting autocomplete and suggestions have accessibility benefits, for example those with dyslexia. Where we can limiting the actions you need to do and suggesting ultimately helps everyone. |
@karmatosed wondering what you think of the above direct paging access? Infinite scroll sounds like it's got legs here, I'm trying to understand why besides being able to provide access to all records. |
Autocomplete / suggestions and infinite scroll are two very different things. While the first can be made accessible and there are already examples in WordPress and Gutenberg, infinite scroll can't be made accessible for the reasons already explained in #5921 (comment) |
@Lewiscowles1986 I think what I am seeing above is confusing as an interface. There's a lot going on there. For example hierarchy, is paging a higher priority than the content itself? How would I also know what page information would be on to add a page number?
They are but combined they can resolve issues of usability with infinite scroll for example. I am talking not about accessibility in saying that as that obviously is another strong factor to iterate here. |
Indeed my efforts were mostly as an alternative to the paging via links above.
I didn't quite understand that. It's not direct access based upon knowledge of page numbers to resources, but a way to bypass iterating over a result set. Say I click next.
Im not 100% behind it myself, but I use it |
In the graphic above the number is an input field, that's why I asked how would you know what input to add. I get there is pagination but if it's an input field that indicates that someone would/could add a number. |
The original aim of this issue is no longer valid:
The more immediate problems have been resolved with #6627 #6657 #6722 We'll bring I'm open to discussing UI/UX improvements in a new issue if someone cares to forward a proposal. |
In cases like #4622, #4022, #5820 and others, UI dependent on
withAPIData
can break when all available items aren't loaded in the UI.For example,
editor/components/post-author/check.js
will only fetch up to 100 users:If there are more than 100 users, the UI currently only displays the first 100.
Because it's a valid expectation to bring all items into the DOM (and not depend on autocomplete or similar), it would be helpful if
core-data
supported automatically iterating paginated resources to bring the entire dataset within scope.The text was updated successfully, but these errors were encountered: