Skip to content
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

Open
wants to merge 11 commits into
base: master
Choose a base branch
from
Open

es6 conversion #34

wants to merge 11 commits into from

Conversation

runspired
Copy link

No description provided.

@eviltrout
Copy link
Owner

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 ember-cloaking for global usage?

@runspired
Copy link
Author

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 /addon

They are imported into /app and exported again to make it easy for them to be imported and extended by the main app if needed without losing access to the originals. (This is per ember addon conventions).

The Brocfile.js of an addon exists only for the addon's own use (so using it to create a globals version is a pretty good use for it) and is not run by the app which installs it. I'm sure we could configure it to write out a globals version without too much trouble but I don't have experience with that.

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.

@SamSaffron
Copy link
Collaborator

how far are we off being able to merge this in? @runspired do you still need more work here?

@runspired
Copy link
Author

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.

rsutphin and others added 3 commits March 23, 2015 17:01
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants