Bug: Drafts that don't load on scroll

[+thebruce0]

I'd seen this long ago but didn't put much effort into figuring out what was happening or why. Tonight it happened and I had a thought about why - then I tested, and recreated it!  After disabling all scripts as well.

 

 

If you have a lot of drafts, with the page set up for lazy loading more rows - if you load the Drafts page and begin composing logs (using the link in new tab browser feature, which has been discussed in prior threads) - say you open 3 drafts in tabs and compose them. You scroll the Drafts list and lazy-load more rows.  Having 'cleared' 3 rows (without reloading the page), the lazy load SKIPS 3 rows.

 

Eg: Draft rows - (for argument's sake, this example loads 5 rows before lazy loading more when the browser scrolls)

1. Cache 1

2. Cache 2

3. Cache 3

4. Cache 4

5. Cache 5

...

 

Compose #1 and #2 (2 fewer drafts now)

Return and scroll down. One would expect Cache 6 and Cache 7 would load next. BUT, because I'm guessing it's coded that the next lazy load should start on the "6th" draft, but 2 have been composed, the lazy load will actually result in the page showing

1. Cache 1

2. Cache 2

3. Cache 3

4. Cache 4

5. Cache 5

6. Cache 8

7. Cache 9

...

Because the script is saying "Show me the next batch from the 6th current available row", but 2 have been composed and shifted the rest down, skipping Cache 6 and 7 which are now in the first 5 drafts.

 

This I have tested with a set of drafts. I composed one, returned to the tab with list, then scrolled, and one draft was 'missing' from the list where the lazy load continued. I've been bitten by this while composing drafts in chronological order, to find on refreshing the page that some logs were missed (loaded as uncomposed drafts), because they didn't lazy load on scrolling, and thus having to log caches out of order now, unless I deleted prior finds and re-log them in the right order.

For now the workaround is to either load all drafts before composing (can be very annoying if there's a lot), or compose a handful at a time and refresh the page before hitting the lazy-load row. Both of those make lazy-loading the drafts list effectively pointless.

 

 

The coding fix for this would be to inform the lazy load of perhaps the ID of the latest inserted row on the front end, and continue to load the next chronological batch of drafts from that point. So if you compose all visible initial draft rows and then scroll, you won't miss out on that next amount of drafts.

Per the above example, the ID or timestamp of "Cache 5" would be the reference point for the next lazy load batch, that way even if all 5 first drafts were composed, the next drafts to be displayed would still begin at "Cache 6", the one that actually follows Cache 5.

 

Does that make sense?

 

Edited March 4, 2023 by thebruce0

[+thebruce0]

Has this been taken a look at?