adopted-ember-addons / ember-light-table

Lightweight, contextual component based table for Ember
http://adopted-ember-addons.github.io/ember-light-table/
MIT License
311 stars 131 forks source link

When using fixed headers or footers, rows are rendered twice #552

Open gmurphey opened 6 years ago

gmurphey commented 6 years ago

My team noticed that table rendering was a bit sluggish and on further investigation, realized that each cell component was being rendered twice. I've added some tests that illustrate the issue.

https://github.com/metricly/ember-light-table/commit/11adf8d95fd744ce6cc211e0d1ea8d9fd45c218e

I believe this is caused by the runloop surrounding the virtual scrollbar logic:

https://github.com/offirgolan/ember-light-table/blob/6d71609da875453ff9792f636b88c5c2e7e7f385/addon/components/lt-body.js#L322

Since this waits until lt-head, lt-body, and lt-foot have all been initialized. We've worked our way around this for now by creating fixedHead and fixedFoot properties on light-table, but didn't want to create a PR with those changes since it would introduce a breaking change. If there are any ideas for a better way to address this, I'd be more than happy to put together a PR and move this forward. Thanks for all the great work!

buschtoens commented 6 years ago

Thank you very much for reporting this issue, the analysis and test cases! :heart:

I will try to look into it soon, but am currently swamped at work. :see_no_evil:

However, some ideas:

  1. Delay all rendering until the state of useVirtualScrollbar is determined
  2. Somehow refactor the code so that _setupVirtualScrollbar is called before the component is rendered or the state may be determined before the initial render.
  3. Use {{in-element}} to simply relocate the DOM nodes instead of re-rendering.

Soon-ish I would like to prep for a major release, that would completely overhaul the rendering logic.