-
Notifications
You must be signed in to change notification settings - Fork 28
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
es6 conversion #34
base: master
Are you sure you want to change the base?
es6 conversion #34
Conversation
Awesome. I just took a peek and it seems like I'm not familiar with how it's set up. Are we supposed to use ember-cli to build it now? What are the instructions to create a new |
Correct, this makes it a drop-in addon on for ember-cli, to use it all you have to do is be using ember-cli, it exposes the same helpers in the same manner as before. The classes themselves are in They are imported into The Also a note: Ember-cli conventions have changed slightly since I began this conversion, I think there's a few tweaks that need to be made to dependencies / addon-main to be made, but it works without them. |
enable scrolling within an element, add cloaked/uncloaked and cloak-view...
…king instances, even across route transitions
how far are we off being able to merge this in? @runspired do you still need more work here? |
It's able to be merged but doesn't provide a mechanism for producing a globals build. I'd also like to add tests but that can happen in a later sprint. This branch has been used in production for 5-6 months now. |
The previous expression (offset + wrapperTop) was only correct when the wrapped container was positioned at the top of the document. If the container was further down from the top of the document than the height of the last row, the last row would always be cloaked. The further down the container started, the more of the bottommost rows would always be cloaked. This was because "viewTop" was computed using document-relative coordinates, but was compared to a value (viewportBottom) that was clamped to the height of the container's content. This change uses a coordinate for viewTop which is relative to the scrolling container.
Incorporating wrapperTop into the calculated viewBottom shifts the computed bounds for all the views such that the first row is always found to be the topmost visible. Top put it another way, it prevents any of the views that scroll above the top from ever being cloaked when you're using a wrapper element.
…alculations-es6 Correct visible view calculations when using a wrapper element
No description provided.