1

I am browsing HTML tables with pages that auto load via javascript & XMLHttpRequest calls as the user scrolls. The number of records per page are user defined. The height of the rows can vary. All the code is vanilla javascript and all solutions should be likewise.

I am tracking which row is crossing the middle of the table's viewable rows to determine what is the current page. This is used to display the current page number and to determine when to autoload the next page (think of how Acrobat displays the current page number and thumbnail as you scroll through a PDF). My process to do this:

  • Use the intersection observer to observe TR rows that scroll in and out of the device's viewport. The triggered tr will either be at the top or bottom of the viewport.
  • Starting at the triggered row, I loop through the tbody's tr elements moving toward the middle until I find the tr which intersects with it. I can calculate the current page from the tr's custom data-rownum attribute.

I discovered that the intersection observer's boundingClientRect property is only updated and current for the triggered element, not the other observed row elements. Therefore I can't use it to calculate a row's position on the screen. I have to call getBoundingClientRect() for each tr to determine its position as I loop through the tbody.

My question is how to measure the performance cost of calling getBoundingClientRect() - perhaps 20-50 times per scroll - every time the observer triggers a new row being visible. Is there a way to objectively decide the impact?

Is it worth the effort performance-wise to find another solution? The only other solution I have in mind is to start with the triggered row and use the height property of each tr to calculate it's position on the screen using the triggered tr as a starting point. But, in order to do this, I'd have to have a resizeObserver set on all the rows to update the height property on resize, since they can be expanded by the user.

Lastly, is there a different direction that would allow me to track all rows that pass through the middle of the viewable tbody that would be more efficient?

mseifert
  • 5,390
  • 9
  • 38
  • 100
  • If you don't mess with the layout between each gBCR call, only the first one will have a noticeable impact, all other ones will just be getters of already calculated values. If you do that in the IntersectionObserver callback, and nothing trashed the layout before, then even the first call won't cost anything. – Kaiido Nov 27 '22 at 00:42
  • @Kaiido - This doesn't make sense, since every row has a new `top` value with a scroll. – mseifert Nov 27 '22 at 00:50
  • Yes, what's costly is that all the layout of all the page has to be recalculated. No, scrolling will invalidate the boxes but not necessarily the layout. viewport_y = absolute_y - viewport_scrolltop. That doesn't require to update the layout. And I did only talk about consecutive calls. The layout would need to be recalced for the IntersectionObserver anyway. – Kaiido Nov 27 '22 at 00:53
  • @Kaiido - Ok, thanks - that is very helpful. I couldn't find documentation on how and when gBCR does calculations. – mseifert Nov 27 '22 at 01:00
  • A bit oversimplified, but I write some time ago: https://stackoverflow.com/questions/47342730/javascript-are-dom-redraw-methods-synchronous/47343090#47343090 However for your question I'm not clear what would be "the best solution". – Kaiido Nov 27 '22 at 01:06

0 Answers0