Open gmurphey opened 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:
useVirtualScrollbar
is determined_setupVirtualScrollbar
is called before the component is rendered or the state may be determined before the initial render.{{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.
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
, andlt-foot
have all been initialized. We've worked our way around this for now by creatingfixedHead
andfixedFoot
properties onlight-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!