You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I would like to use ember-in-viewport in only the horizontal direction.
The product use case here is a VERY large data table with 2000+ rows of 40+ columns, whose column headers have in-viewport checks on them that control if we should render a column's cells.
When the column headers are scrolled off-screen vertically, I don't want to cull the cells. I only want the intersection checking in the horizontal/X direction.
This is possible with IntersectionObservers, by specifying a rootMargin in % values.
Forces us to use pixel values. If we pass % based values, we get errors like:
I suggest we either:
Remove the string concatenation and force the developer to specify px/% when passing a viewportTolerance to more closely align with the IntersectionObserver API. ( would require major version bump )
or -
Add some code that looks for a % in the value, if so, it uses the value unmodified.
or -
Something more clever?
Happy to do the work, but I would like some consensus first.
The text was updated successfully, but these errors were encountered:
I would like to use
ember-in-viewport
in only the horizontal direction.The product use case here is a VERY large data table with 2000+ rows of 40+ columns, whose column headers have
in-viewport
checks on them that control if we should render a column's cells.When the column headers are scrolled off-screen vertically, I don't want to cull the cells. I only want the intersection checking in the horizontal/X direction.
This is possible with IntersectionObservers, by specifying a rootMargin in % values.
This line here:
ember-in-viewport/addon/services/in-viewport.js
Line 183 in 58c3f97
Forces us to use pixel values. If we pass % based values, we get errors like:
I suggest we either:
viewportTolerance
to more closely align with the IntersectionObserver API. ( would require major version bump )Happy to do the work, but I would like some consensus first.
The text was updated successfully, but these errors were encountered: