Basically the approach is like that used by the Sproutcore Big Data List demo, being:
1. construct a moving foreground window onto a giant, scrollable background element (giant, as in arbitrarily wide and high, like 200000em)
2. move rows from the 'scroll wake region' to a pool when they move offscreen because of scroll,
3. move rows from the pool to the 'scroll bowshock region' when we need new rows because of scroll,
4. don't change the position of any existing rows in the window (instead allowing them to scroll naturally), but set new rows (and remove pool rows) using absolute positioning.
Except as we need to scroll across both rows and columns do all of the above in 2 dimensions, for columns as well. And also the way I detect when we need to "add or remove" rows or columns is via Intersection Observers[mi].
Major issues overcome so far
---------------------------------
- It's possible to scroll it now infinitely (and performantly) for the duration of the very large background element.
- Major problem was I initially was listening for intersection of cells individually on each row, but if a row had already travelled off screen due to a vertical scroll, it would not be possible for its cells to 'intersect' with the viewport element (the window, in Intersection Observer API parlance, the "root"), and so no intersection for that cell would occur, and so cells in that row would not be updated. And if they were not updated, they would not be onscreen when the row was in future removed from the pool and positioned back on screen, and so its cells could no longer be updated, as there would be no cells within that scroll viewport to intersect anymore. The solution to this was to create a logical grouping of cells into columns, and handle any intersection observations for any cell in a column, at once, and apply them to all cells in a column. So the whole column would be updated. Before I fixed this, repeated scrolling (particularly in opposite diagonal directions) would erode the cells present, gradually decreasing their number, and throwing many out of their column alignments.
- Also performance was another issue that's now mostly resolved tho I think I can do better. Basically too much work was happening on handling each Intersection record and we were not ignoring records that triggered the same work to be redone (such as intersection events from each cell in a column). These redundant records are now ignored (but mostly in a haphazard manner that could cause browser dependent bugs).
Next steps
-------------
- Add all of the outstanding features (scroll snap, row / col size dragging) from the table component.
- Style it to make it look nice
- Fix the outstanding border 'off by 1' bugs.
- Sync up the 'view portal' with a 'data portal' (movable portal over a very large set of data), and print the correct data corresponding to the current scroll position in the table
- Add the row and column headers using CSS sticky.
This is the only comment I'll make in this thread, thanks for reading, and hit me up with questions at my email if you want: cris@dosycorp.com
-----------
Basically the approach is like that used by the Sproutcore Big Data List demo, being:
1. construct a moving foreground window onto a giant, scrollable background element (giant, as in arbitrarily wide and high, like 200000em)
2. move rows from the 'scroll wake region' to a pool when they move offscreen because of scroll,
3. move rows from the pool to the 'scroll bowshock region' when we need new rows because of scroll,
4. don't change the position of any existing rows in the window (instead allowing them to scroll naturally), but set new rows (and remove pool rows) using absolute positioning.
Except as we need to scroll across both rows and columns do all of the above in 2 dimensions, for columns as well. And also the way I detect when we need to "add or remove" rows or columns is via Intersection Observers[mi].
Major issues overcome so far
---------------------------------
- It's possible to scroll it now infinitely (and performantly) for the duration of the very large background element.
- Major problem was I initially was listening for intersection of cells individually on each row, but if a row had already travelled off screen due to a vertical scroll, it would not be possible for its cells to 'intersect' with the viewport element (the window, in Intersection Observer API parlance, the "root"), and so no intersection for that cell would occur, and so cells in that row would not be updated. And if they were not updated, they would not be onscreen when the row was in future removed from the pool and positioned back on screen, and so its cells could no longer be updated, as there would be no cells within that scroll viewport to intersect anymore. The solution to this was to create a logical grouping of cells into columns, and handle any intersection observations for any cell in a column, at once, and apply them to all cells in a column. So the whole column would be updated. Before I fixed this, repeated scrolling (particularly in opposite diagonal directions) would erode the cells present, gradually decreasing their number, and throwing many out of their column alignments.
- Also performance was another issue that's now mostly resolved tho I think I can do better. Basically too much work was happening on handling each Intersection record and we were not ignoring records that triggered the same work to be redone (such as intersection events from each cell in a column). These redundant records are now ignored (but mostly in a haphazard manner that could cause browser dependent bugs).
Next steps
-------------
- Add all of the outstanding features (scroll snap, row / col size dragging) from the table component.
- Style it to make it look nice
- Fix the outstanding border 'off by 1' bugs.
- Sync up the 'view portal' with a 'data portal' (movable portal over a very large set of data), and print the correct data corresponding to the current scroll position in the table
- Add the row and column headers using CSS sticky.
This is the only comment I'll make in this thread, thanks for reading, and hit me up with questions at my email if you want: cris@dosycorp.com
[bt]: https://i5ik.github.io/_____/7guis/ (scroll down to the last 7GUIs component)
[bp]: https://github.com/palantir/blueprint/issues/390
[ft]: https://fulmicoton.com/fattable/index2.html
[sc]: https://showcase.sproutcore.com/#demos/Big%20Data%20Lists
[ct]: https://canvas-datagrid.js.org/demo.html
[mi]: https://developer.mozilla.org/en-US/docs/Web/API/Intersectio...
[other]:
https://js.devexpress.com/Demos/Widgetsgallery/Demo/DataGrid...
https://codepen.io/enigmatic/pen/JGvwEv
https://www.htmlelements.com/demos/grid/overview/