Skip to content

es6 conversion - #34

Open
runspired wants to merge 11 commits into
eviltrout:masterfrom
runspired:es6-flattened
Open

es6 conversion#34
runspired wants to merge 11 commits into
eviltrout:masterfrom
runspired:es6-flattened

Conversation

@runspired

Copy link
Copy Markdown

No description provided.

@eviltrout

Copy link
Copy Markdown
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
Copy Markdown
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
Copy Markdown
Collaborator

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

@runspired

Copy link
Copy Markdown
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