-
Notifications
You must be signed in to change notification settings - Fork 90
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
Listing: load more #2150
Listing: load more #2150
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2150 +/- ##
==========================================
- Coverage 46.41% 46.30% -0.11%
==========================================
Files 431 434 +3
Lines 20557 20618 +61
Branches 2410 2431 +21
==========================================
+ Hits 9542 9548 +6
- Misses 10100 10161 +61
+ Partials 915 909 -6
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The layout doesn't fit into viewport on mobile and on iPad landscape mode
I think that "Load more" is not quite an appropriate action for the user. The user wants to see more results, sort or filter on a bigger chunk of results. Loading more — is our internal workaround. As a user, I just don't understand what's going to happen on "Load more" click, what is going to load and where. I spotted that number of results and page number incremented after results loading.
Possible enhancement 1. Tell the user what is going with helper tooltips. We can explain that we can't load everything and need to work with a slice of data. The size of this slice can be increased by user action.
Possible enhancement 2. Instead of clicking "Load more" button user can input the exact number of results he wants (we can use input + dropdown).
yep, true
seems like a good idea (and easily implementable)
this seems confusing, i dont quite get the ux you try to describe, and also it may be a little harder to implement the proper solution in the long term (as i see it) would be to do all this fetching / slicing / filtering / sorting on the backend and only send to the front-end the data it needs to render the UI -- in-stack requests are very fast and cheap, and there's not that much data to use up too much ram (say, it should handle 100k keys without any problems) |
8378ea1
to
03fef32
Compare
Description
There's two ways to load more results: "load more" button in header / footer and second "..." button (displayed after the last page in pagination)
TODO
build.py
for new docstrings