This week, I focused more on integrating and seeing benefits of the intersection API along with looking at rendering functions and facets.

Using scroll events to check when the element comes into view often skips firing off the corresponding functions if you scroll fast enough. While it’s not so noticeable, it’s still better to find a way to overcome that problem. I have looked at the intersection API in terms of that. While it’s still not the best, it’s a bit better than what scroll event provides us (so it appears in example sites).

This drawback of checking for elements to come into view to execute functions gives reasoning to why some libraries prefer using the scrollTop value instead. Although scrollTop is also known for performance issues, this decision should be based on what matters more.

I have finished most of the work by replacing the scroll events with intersection API. One of the disadvantages to it is that it would consider an element visible even when the height is zero. While this is easy to fix by adding another condition for checking the height of the element we are observing, this brings up the point that overall it does not allow much freedom with what parts of the element we wish to be working with. For instance, the threshold value is something close to unpredictable as it changes with datasets and different scroll positions. We can try to give it some minimum number, but there still might be situations where the threshold value is less than that.

To explain this better, the threshold denotes what percentage of the element we are observing is visible on the screen. This value also takes the width into account. So for instance, if you have a row with a height of 20px and a width of 3000px and a screen size of 1200px, the threshold value will be calculated based on 20 x 1200 that’s visible out of 20 x 3000. This brings in the need to have a calculated minimum value of threshold which will depend on the datasets.

Another problem with it is that it does not seem to adapt to changes in heights of the first-row and last-row as fast. It continues to call functions repeatedly even when the observer is set to stop observing. Here is the link for the branch which contains intersection API. Overall Intersection does not seem to be working the way we expect it to.

The rendering functions (for adding rows and cells to the DOM) take the most time when adding rows into the table. I have been reading about the best practices to follow while using javascript and jQuery. It’s advised to use javascript whenever we can and I have been trying to replace some of the jQuery code to javascript. I have been currently looking at the renderRow which renders the row, but I haven’t been able to improvise it a lot. This highly depends on the cell rendering as well, I will be working on that in the coming week.