Use 'Load more...' button to load items
I know that pagination feature is in the roadmap. However when dealing with long list, I think it worth implementing a simple solution first.
Here is my pocket:
Currently the popup is totally unusable with such size. I suggest instead of building all items into DOM, we build some of them at start, and add a 'Load more...' button at the bottom of the popup, which would add more items when clicked, result in faster render speed.
Also it seems that there is already a buildBatch
function, perhaps it isn't too hard to implement.
Comments (11)
-
repo owner -
repo owner - changed status to open
-
reporter I've test the latest
master
. The initial render was faster, but it still stopped responding in the end.I logged the timestamp
performance.now()
eachbuildBatch
is called:439.915 popup.js:570 511.49 popup.js:570 551.855 popup.js:570 622.47 popup.js:570 677.825 popup.js:570 845.3000000000001 popup.js:570 870.075 popup.js:570 909.915 popup.js:570 939.6700000000001 popup.js:570 974.6700000000001 popup.js:570 1011.075 popup.js:570 1086.445 popup.js:570 1124.395 popup.js:570 1156.3700000000001 popup.js:570 1202.02 popup.js:570 1235.255 popup.js:570 1292.8500000000001 popup.js:570 1330.04 popup.js:570 1390.06 popup.js:570 1424.23 popup.js:570 1496.075 popup.js:570 1531.455 popup.js:570 1613.54 popup.js:570 1646.6200000000001 popup.js:570 1729.775 popup.js:570 1765.47 popup.js:570 1857.905 popup.js:570 1914.03 popup.js:570 2009.17 popup.js:570 2047.04 popup.js:570 2159.73 popup.js:570 2211.28 popup.js:570 2324.46 popup.js:570 2366.545 popup.js:570 2488.93 popup.js:570 2546.215 popup.js:570 2682.18 popup.js:570 2735.835 popup.js:570 2875.03 popup.js:570 2947.155 popup.js:570 3097.3650000000002 popup.js:570 3157.755 popup.js:570 3316.28 popup.js:570 3384.585 popup.js:570 3555.895 popup.js:570 3620.195 popup.js:570 3795.525 popup.js:570 3865.7200000000003 popup.js:570 4059.105 popup.js:570 4127.45 popup.js:570 4325.75 popup.js:570 4406.7 popup.js:570 4619.3 popup.js:570 4698.03 popup.js:570 4921.165 popup.js:570 5007.06 popup.js:570 5241.625 popup.js:570 5322.595 popup.js:570 5571.185 popup.js:570 5658.985 popup.js:570 5916.11 popup.js:570 6010.255 popup.js:570 6284.495 popup.js:570 6365.3 popup.js:570 6656.125 popup.js:570 6738.095 popup.js:570 7046.96 popup.js:570 7137.54 popup.js:570 7449.905 popup.js:570 7539.84 popup.js:570 7869.71 popup.js:570 7959.975 popup.js:570 8311.41 popup.js:570 8407.23 popup.js:570 8779.855 popup.js:570 8874.485 popup.js:570 9256.02 popup.js:570 9357.175000000001 popup.js:570 9753.455 popup.js:570 9861.505000000001 popup.js:570 10294.300000000001 popup.js:570 10404.92 popup.js:570 10851.195 popup.js:570 10966.52 popup.js:570 11436.48 popup.js:570 11569.975 popup.js:570 12062.875 popup.js:570 12180.305 popup.js:570 12678.575 popup.js:570 12801.125 popup.js:570 13371.630000000001 popup.js:570 13500.74 popup.js:570 14105.485 popup.js:570 14239.945 popup.js:570 14845.695 popup.js:570 14991.255000000001 popup.js:570 15651.655 popup.js:570 15836.065 popup.js:570 16532.43 popup.js:570 16663.79 popup.js:570 17415.315 popup.js:570 17571.845 popup.js:570 18431.205 popup.js:570 18598.875 popup.js:570 19495.025 popup.js:570 19652.28 popup.js:570 20590.920000000002 popup.js:570 20778.39 popup.js:570 21760.31 popup.js:570 21910.555 popup.js:570 22938.22 popup.js:570 23118.13 popup.js:570 24188.305 popup.js:570 24372.275 popup.js:570 25470.690000000002 popup.js:570 25661.455 popup.js:570 26800.66 popup.js:570 26979.165 popup.js:570 28187.405 popup.js:570 28373.235 popup.js:570 29622.135000000002 popup.js:570 29844.73 popup.js:570 31175.005 popup.js:570 31365.945 popup.js:570 32746.055 popup.js:570 32961.6 popup.js:570 34433.855 popup.js:570 34625.020000000004 popup.js:570 36152.225 popup.js:570 36335.48 popup.js:570
You can see that in the first second,
buildBatch
had been called 20 times, but in the end, each iteration took around 1 second.IMHO, even we don't want this feature, we should still limit the number of items so the DOM won't grow too large.
BTW it is confusing that I have 6179 items in total, if the script builds 50 items per iteration,
buildBatch
should only be called 124 times right? But the log contains 130 lines. -
reporter It seems that
UI.drawList
is called twice. One insetup
:
https://bitbucket.org/pabuisson/in-my-pocket/src/7d8f1c9085d09a88d2aae70ce821615a7dcc4921/src/popup/popup.js?at=master&fileviewer=file-view-default#popup.js-289One in
retrieve-items
event:
https://bitbucket.org/pabuisson/in-my-pocket/src/7d8f1c9085d09a88d2aae70ce821615a7dcc4921/src/popup/popup.js?at=master&fileviewer=file-view-default#popup.js-293
https://bitbucket.org/pabuisson/in-my-pocket/src/7d8f1c9085d09a88d2aae70ce821615a7dcc4921/src/popup/popup.js?at=master&fileviewer=file-view-default#popup.js-406 -
repo owner Thanks a lot for your feedback and your test !! It helps me so much. So to sum things up :
- The first items are rendered faster now (which is good)
- But the UI remains slow to respond when you click / add items / etc. (which is not so good 😅)
Do I get it right? I still have one other optimisation in store for click events, but I don't know if it can make a big difference or if the DOM is just too large anyway.
I'll move pagination up in my devlopment priorities.
And I agree with you for the number of times
buildBatch
has been called. Can't understand for the moment, I'll take some time this week to check if things are wrong somewhere. -
repo owner Didn't see your comment about
drawList
. Well indeed there's something here. Thanks for this! I'll fix this tonight. -
reporter I think the problem is just that the DOM is too large, each time you insert an item it has to re-render entire tree. After 37 seconds, all items are built, I can't even scroll the popup.
It is not a common case though. In the first second it builds 20 * 50 = 1000 items so it should be fine for most of the users.
-
repo owner Yep indeed, and that's why it progressively takes a bit more time for each new iteration since the DOM gets bigger and bigger. 6000 items is quite a lot indeed, but still, I need a solution for users that have this volume of items.
The batch dom creation +
requestAnimationFrame
at least avoids freezing the UI when I build the DOM, but in the end if the number of items is really high, the UI is not responsive anyway....So eventually, the only true solution is to stop building the complete list.
-
repo owner Hey @eight04 ! Just about the
drawList
: this is not a mistake. Actually, first call fromsetup
is here to construct the initial list, based on what's already in the local storage. Then a call to the pocket API is made, retrieving the diff (new items or items that have been archived / deleted), and when I get an answer from Pocket, the list is built again with those new items.What should be done : when I get the diff, I only insert and remove the specific items that have changed, instead of redrawing everything. When I wrote this code initially, I didn't think there'd be users with several thousands items (you're far from being the only one).
I'll start working on these right now. It's not the pagination yet, but it'll still be good to have a more clever behaviour here.
-
reporter -
repo owner - changed status to closed
Since this bug report, I've implemented the pagination. And today I've been working on removing the duplicate call to
drawList
as well.Thanks for your help :)
- Log in to comment
Hey! Well, I've just added the
buildBatch
method recently, it's not released yet, will be part of a big 0.6.0 release soon. The goal was to avoid freezing the UI when building the DOM (I didn't think users would have so many items in their list, I personnally keep 100 items at most).Would there be a chance that you could try to build and test the addon with
master
branch by chance? I was looking for someone who could test this with lots of items. That would help me a lot :)