Single cell buffer element still interfering with the normal table layout

[ajayvikas]

Just updated to version 0.4.3

The single cell on table buffer is still causing issues. It is still interfering with the column widths. You can see in the attached picture.

(look at the top very top border. At the top of the first cell, it looks like a thick border because of the buffer cell and rest of the border look like a double border, top is coming from the preceding div.)

I was wondering why don't you append the buffer element before and after the table. that way the table contents would remain clean and buffer won't interfere with the table layout.

[martingust]

@ppN2 That might be a better way to handle the buffer element in tables. Will look into this.

[lsesol]

Could this be mitigated by simply setting a colspan on the buffer cell?

It's not technically correct, but all browsers I've come across accept an arbitrarily large colspan to mean all cols. However since the first item is rendered in order to get height should mean the actual column count is accessible.

[ajayvikas]

@lsesol my experience is that the table layouts are already very tricky. Injecting cells even with colspan makes it even more difficult. I still believe the best strategy to introduce buffer elements outside of the table.

[ajayvikas]

Hello @martingust

Would it be possible for you to predict when you are gonna work on this issue?

[AStoker]

Might just be that some nifty CSS could fix the issue. For your problem right now, you could probably address it with CSS.

[ajayvikas]

@AStoker this is not an CSS issue. Once you have a single cell in the first row, it immediately start to interfere with the layout. The table does not respect the column widths anymore. Also with the CSS I have tried everything but nothing seems to fix this problem. Also I have just tried on Chrome. Who know what other problems are lurking with other browsers.

[martingust]

@ppN2 Sorry for the delay, other stuff have been prioritized. My plan is to start knock out issues on this repo within a week or so.

[martingust]

@ppN2 Ok, I've got this working by moving the buffer element outside of the table. Will need to do some more testing and refactoring before I'll get this in.

[ajayvikas]

Thank you very much @martingust. I really appreciate it.

[martingust]

@ppN2 Hopefully a fix is in mater, will go out in next release.

[ajayvikas]

hi @martingust. I tried the latest release and it immediately busted. I tracked the error to this line.
Basically for some reason the null value is being passed in the getElementDistanceToTopOfDocument function. To make it work I changed the code as follows

var box = element ? element.getBoundingClientRect() : {top: 0};

I am not sure what was causing null to pass into this method but if you give me some pointer i can try to track it down.

Anyway after making this change it worked like a charm. I can see that the buffer elements are before and after the table, which is fantastic. Thank you very much!!!

I also noticed couple of things.

1. getElementDistanceToTopOfDocument is being called repeatedly very quickly (every second or so). Seems like some kind of dirty checking is going on, which we would like to avoid at any cost (causes drain on the battery of the device).
2. While playing with the table, I saw the suddenly the whole table went blank. I don't remember the exact sequence but I did some browser resizing, open/close dev tools. I can't reproduce this behavior any more but if you hear from somebody else as well, it might be worth investigating.

[martingust]

@ppN2 Your change might be what's needed, I'll take a look when I get back from vacation.

1. Yes, getElementDistanceToTopOfDocument is called every 500 ms, it is calculating the the distance from top of the list to top of document, if this changes it needs to get the new distance. There might be a better way I don't know of the get notified when this distance changes without, any ideas are welcome.
2. Most likely due to resize of window, issue is tracked here Recalculate Items Shown on Resize #69

[ajayvikas]

@martingust I would assume scroll event would take care of it but I can't help but thinking that you might have already tried it.

Recently I had a look at the virtual scroll from kendo guys. The demo is available at this link. I feel there scroll feels snappy and well built. I compared with aurelia-virtualization demo. The difference in the performance was too big too ignore. In aurelia, if you scroll up or down quickly, you see a blank screen and then the items are rendered. If you add too many items lets say 500000 items, the entire ui becomes unresponsive or the list becomes blank.

I am sorry I am not being too helpful in suggesting a solution but maybe you guys can take inspiration from other implementations like kendo (or many others on the internet). I do appreciate all the good work you guys are doing. I really do.

[martingust]

@ppN2 Yes, scroll event won't help here. The use case is if for example if some element expands above the list and pushes it further from the top of the document the list needs to get the new distance. Kendo's grid seem to only support lists in a fixed height container where this is not an issue.

When adding 500000 items you are probably hitting the boundary of the max height of your browser. We can probably solve this by not adding more height to the buffer after a certain height is reached, here is an issue trcking that #30

[ajayvikas]

@martingust I am not following exactly "The use case is if for example if some element expands above the list and pushes it further from the top of the document the list needs to get the new distance". Can u please elaborate on this. May be I am missing something.

I understand 500000 items are not a practical scenario but I was comparing aurelia to kendo and kendo is generating 500000 items for the demo and their performance is very very snappy.

[ajayvikas]

hi @martingust, it will be very informative for me, if you could please answer above question.

[martingust]

@ppN2 Here is a very simple example of what I'm trying to explain https://gist.run/?id=48c0e468a113137d68f42f112a60dadc

Basically the virtual-repeat needs to know the distance to the top of the document in order to know when an element should be moved from the top to bottom when scrolling. Does that make sense? Ideally, if possible, this can be handled in a different way without using setInterval, I just don't know how.

I think the demo is a bit outdated, when running the latest virtual-repeat with 150K items I see no performance degradation compared to 50 items. This in Chrome on mac, Edge/IE might not be as good though since their DOM performance are very poor. More than 200K I'm running into max browser height issue. This is not a performance problem but just the fact we need to take the browser max height in to account and cap the heights of the buffer elements. One improvement that could boost the performance is to not move the DOM elements from top to bottom and instead animate them with CSS transform.

[ajayvikas]

thanks @martingust. Is my understanding correct that the real utility of the setInterval is in those cases where the height of the container is not fixed??

Also I will check the performance of the virtual repeat again and update you with my observations.

[martingust]

@ppN2 Yes, that is correct. Although this could possible be an issue with fixed height containers as well if there is a distance between top of list and top of container, like a top margin.

[ajayvikas]

I do agree that not have a fixed height container make is convoluted to manage. In that case can we make setinterval fire only when you detect the container width is not fixed?

[AStoker]

Mentioning this here since it was added to the comment of this: 1fe64a6

Want to confirm @martingust, I've been working with somebody who's been having problems using the table with the virtual repeat. It seems that the buffer elements are now being placed outside the table (1fe64a6#diff-2b74c1b3919c906109711c2622b514cfR74).
This is causing some strange behavior when that table isn't wrapped in a scrollable (overflow) div. Is this desired? If so, we may need to update the docs to show this.

[martingust]

@AStoker We moved the buffer elements outside of the table since those were causing problems as mentioned in the issue. So as for right now it is desired. What strange behavior are you experiencing?

[AStoker]

@martingust, if you have a table outside of some container div, then the scrolling behavior doesn't work. If you have something like this:

<body>
   <h1>scrolling test</h1>
   <table>
      <tr virtual-repeat.for="item of items">${item}</tr>
   </table>
</body>

(please excuse any missed styles or what not, this was just to demonstrate the location of elements), when you end up scrolling down, the elements aren't scrolling correctly (either not rendered, or jerky scrolling), and when you scroll back up, the elements frequently disappear completely.