ember-animation / ember-animated Goto Github PK
View Code? Open in Web Editor NEWCore animation primitives for Ember.
Home Page: https://ember-animation.github.io/ember-animated/
License: MIT License
Core animation primitives for Ember.
Home Page: https://ember-animation.github.io/ember-animated/
License: MIT License
When clicking through heroes which are not the first item, the '.ember-animated-top-collapse' class is sometimes added to only the first item, causing it to jump up during the animation. It seems to happen when transitioning in both directions (but not always!).
I'm not entirely familiar with the library yet, so I unfortunately haven't fully tracked it down.
First pointer:
ember-animated/addon/sprite.js
Line 432 in a68fbb1
I think I might be misunderstanding the intended use for applyStyles
let sprite = insertedSprites[0];
console.log(sprite.initialComputedStyle); // null
sprite.applyStyles({
opacity: '0.5'
});
console.log(sprite.initialComputedStyle); // null
Is there a general way to set/update the initialComputedStyle
for a Sprite? I noticed some methods like startAtSprite
affect it.
In general I'm having trouble using applyStyles
throughout my transition, but I think my mental model for it might be off. I would expect to be able to do something like
sprite.applyStyles({
opacity: '0.5'
});
adjustCSS('opacity', sprite);
and have it fade in.
I'm not sure if this is a scenario that ember-animated
should handle or not. If not, please let me know so that I can consider approaches other than making modifications to ember-animated
.
I'm using ember-animated
in ember-present
. I'm applying a scale to slides based on the available viewport in order to maximise their size of the slide while maintaining a 16:9 aspect ratio. When a scale is applied, the animated sprites seem to move to incorrect positions:
When I remove the scale, the sprites animate correctly:
This is hopefully an easy one for somebody who wants to contribute.
This PR disables jQuery, but the tests don't pass because Ember's {{input type="checkbox"}}
requires jQuery until very recent Ember versions.
Your mission is to change our demos to not use {{input type="checkbox"}}
and instead just use <input type="checkbox">
with manual binding of the checked
attribute and the necessary event.
An easy way to experiment is to check out the branch from the above-mentioned PR, run the dummy app, visit /demos/here-there, and click the checkbox. It throws an exception.
Hi! I was hoping to get some guidance/advice on how best to organize an animation I'm working on.
There's a nice animation from the Things OSX app:
What I'm looking to build is similar to this but actually slightly different.
The animation from Things is actually more straightforward to me, because double-clicking a Todo reflows the contents below it, and there's a lot of stuff in Ember Animated to help there.
What I'm looking to do is render something very similar to the "expanded" state, without "pushing" any of the lower items down. Almost like the expanded state is going to be using position: absolute
to grow & show additional data, but there will still be a placeholder "underneath" to keep the space in the list for the existing items.
I'm having trouble thinking about the best way to go about doing this.
My first thought was to make two different versions of the "card", one collapsed and one expanded. Then, when the user selects an item, really I could just add a visibility: hidden
class to the collapsed, and show the expanded, and then animate it up. I could start out the expanded sprite at the CSS values for the collapsed version, and use motions to smoothly animate the width and text size up to the expanded version.
This approach feels a little hacky to me though, as I really want to smoothly animate out a card from one state to another. It's the same card, just certain dimensions & contents about it are changing.
So, the other approach I thought was to treat the card as a keptSprite
and use something like animated-value
, to animate the card between two different states with like item.isExpanded
. That would give me one conceptual "card" that exists in two different states.
The problem here is that I'd want a placeholder left behind when isExpanded
is true, to hold space in the normal document flow for the items below it. I feel like Sprites are perfect for this since they contain info about their height and width. Is there some way I could use a keptSprite
's information, render a placeholder to the DOM, and then animate that keptSprite myself to the expanded state, setting absolute positioning on it?
I wanted to write up some thoughts here if anyone has any ideas, but I'd also love to jump on a screen share to explain more.
Thanks!
If I missed something in the docs I apologize in advance. What I'm trying to achieve is animating from the loading route to the app once my data is fetched. The structure of my app is:
+ parent/
|
| + view/
| + loading/
| + otherPage/
| template.hbs
I'm just a little lost as what to wrap as a animated-component/if/value
so I can animate between the loading component to any route, or better yet how to animate from one route to any other route.
I know there is a longer-term plan to reimplement Liquid Fire on top of Ember Animated, but for folks working today, could you provide a 2-3 sentence summary of when they should use Liquid Fire (if they at all) vs. Ember Animated?
Just wanted to capture a bit of our conversation from EmberConf before I forgot it.
I was confused why things like this
* transition({ insertedSprites }) {
insertedSprites.forEach(sprite => {
sprite.scale(0.8, 0.8);
scale(sprite);
});
})
and this
* transition({ insertedSprites }) {
insertedSprites.forEach(sprite => {
sprite.applyStyles({
opacity: 0.5
});
fadeIn(sprite);
});
})
weren't working, when things like this
* transition({ insertedSprites }) {
insertedSprites.forEach(sprite => {
sprite.startTranslatedBy(0, -10);
move(sprite);
});
}
were.
In our conversation, Ed said things like initialBounds
and initialComputedStyle
are intended to be thought of immutable, as they come from the expensive measurement operation that takes place before the transition begins animating. Thus, all the logic that happens inside the userland transition
function happens after that measurement has happened, and so the idea is that you're not modifying those initial/final properties.
The flaw with
sprite.applyStyles({
opacity: 0.5
});
fadeIn(sprite);
is that fadeIn
isn't looking at the current state of sprite
, rather it moves from 0
to 1
(or a from
/to
option that you pass it):
fadeIn(sprite, { from: 0.5 });
The general idea is that motions should operate on those measured values of the sprites.
However – I'm now a little bit confused, because of this:
insertedSprites.forEach(sprite => {
console.log(sprite.initialBounds); // null
sprite.startTranslatedBy(0, -10);
console.log(sprite.initialBounds); // {top: 0, bottom: 48, left: 36.515625, right: 66.515625, width: 30, …}
});
So it looks like some of the Sprite
class methods do update the initial
/final
properties.
Based on my experience so far, I think the most intuitive thing would be if (1) all of these sprite methods were able to mutate the initial
/final
properties, and then (2) the convention for motions would be to read from the state of the sprite, unless told otherwise.
Context: I've just watched the Emberconf video and am incredibly excited about this library! I've spent considerable time trying to achieve a similar effect using liquid-fire but have struggled to handle synchronisation between different events—exactly as the demonstration explains.
I'm really keen to reimplement using ember-animated but have one reservation.
This is the animation I'm trying to achieve (slowed down and at is most basic).
It's very similar to tutorial 13 from the living-animation presentation but with a different animation for moving between rows.
Using liquid-fire it was possible because of this.newElement
and this.oldElement
so could be animated independently. The code necessary looked something like this.
let oldOffset = this.oldElement.offset();
let newOffset = this.newElement.offset();
if (newOffset.top > oldOffset.top) {
// matches when sliding up a row
// slides the old element off the screen to the left
// slide the new element in from off the right
let oldMotion = {
translateX: -Math.abs(this.oldElement.width())
};
let newMotion = {
translateX: [0, this.newElement.width()]
};
this.newElement.css({ visibility: '' });
return Promise.all([
animate(this.oldElement, oldMotion, opts, 'sliding'),
animate(this.newElement, newMotion, opts, 'sliding')
]);
}
Now with ember-animated and the use of sprites to animate I'm not sure how to achieve a similar effect. I've looked through the codebase but been unable to find a similar example.
In the living-animation presentation I noted the slide that said 'No cloning necessary'.
I think this library is fantastic and am excited to start using it, but would really appreciate some advice on how an animation like this can be achieved.
I'd be very happy to write up an article on how to do this, or help with the documentation if you could point me in the right direction as I'm sure other people would be interested too.
As an example, this is an article I wrote on Migrating from Liquid Fire modals to Ember Elsewhere
I'm having trouble figuring out why there's a ~5px "jump" on the inline-text demo. I've been looking at the moving-word
component from the Living Animation talk as well and can't figure out what's going on.
animated-orphans
is put in a position: absolute
or position: fixed
div. I've tried different combinations of these but no luck. How does the position of animated-orphans
affect the orphans it renders?~
helper<AnimatedContainer>
, like inline-block and align-topAny ideas or pointers on what's going on?
How might we get these into the lib? Add a lower-level function under easings
?
Any way to do this in userland today?
We're working on using animated-each
with an array of lines of text that we're rendering inside of a <pre>
. It looks like this:
This almost works, but animated-each
generates some whitespace of its own which breaks our formatted code.
If we make this change to animated-each
's template, things work:
{{#each renderedChildren key="id" as |child|}}
{{#-ea-list-element child=child elementToChild=_elementToChild}}
- {{yield child.value child.index}}
+ {{~yield child.value child.index~}}
{{/-ea-list-element}}
{{/each}}
What do you think about this? Is this something that would break other uses? Is there another way to solve the problem?
Due to emberjs/ember.js#16296, which can cause some of our animations to never finish.
I'm running into an issue that might be a bug, or a misunderstanding on my part:
The console is a result of me doing the following sequence twice:
isShowing
)The first two console.table
s show this:
I would have expected (2) to be, Red is kept and Blue is removed.
The second time the sequence is run, that's exactly what I see.
Any idea what's causing this?
I'm using an animated-if
with the default fade
transition wrapped in a <AnimatedContainer>
component. It seems that there is an animation duration mismatch between the two animations though.
Looking at the implementation, it seems that the fade
transition uses half of the duration to remove sprites and the other half of the duration to add sprites. It looks like the <AnimatedContainer>
is using the full duration though. This causes the elements in the animated-if
to already have full opacity when the container is not fully expanded yet.
@ef4 Am I using this incorrectly? Is that intended behavior?
Duration seems to sometimes be shared automatically, e.g. between AnimatedContainer and an animator component that takes @durration
arg.
Is it possible to do the same for easing? If I want to use Linear easing on my animator, the Container will now be "out of sync", as it falls back on the default easing of easeInOut
.
I believe this is by design, but I want to make sure my understanding is correct.
If I have a transition
function on a component
export default Component.extend({
foo: 'bar',
transition: function*({ keptSprites }) {
console.log(this);
keptSprites.forEach(sprite => {
...
there's no way I can access any component state (such as foo
) from within transition
- correct? If so, could you explain why?
This might be silly, but I was trying to use the linear
ease but kept messing up my imports.
I had this
import { easeOut, easeIn } from 'ember-animated/easings/cosine';
and came up and added linear
:
import { easeOut, easeIn, linear } from 'ember-animated/easings/cosine';
I plugged that into my move
motion but still wasn't seeing it. (Sometimes these are hard to tell just by looking at it). But I was sure it wasn't linear...
I dug into the code and put a breakpoint in the Tween
class and saw the default of easeInOut
was still being used.
That's when I realized I was trying to import linear
from easings/cosine
. There is a guard about a Tween's easing
needing to be a function, but this was an undefined import I guess...
So I switched it
- import { easeOut, easeIn, linear } from 'ember-animated/easings/cosine';
+ import { easeOut, easeIn } from 'ember-animated/easings/cosine';
+ import { linear } from 'ember-animated/easings/linear';
...same thing.
I then finally realized linear
is the default import from easings/linear
.
- import { linear } from 'ember-animated/easings/linear';
+ import linear from 'ember-animated/easings/linear';
Maybe we could export an index from ember-animated/easings
? So you can
import { easeOut, easeIn, linear } from 'ember-animated/easings';
Also I don't know if this is possible, but if there was some way to warn if users try to pass in an undefined value that would have also been helpful.
I have this template:
The second div is bigger (has more padding) and has margin-left: auto
. I'm getting what seems to be some inconsistent results between the Sprites in the various categories. For example, if I interrupt, the same Sprite will show up in two categories.
Is there a better way to hint to EA how to match these things? Something like a key for these two divs? How in general does matching work? (So far its been mostly something I haven't had to worry about.)
Trying to perform a fade with animated-if, but getting a unwanted bonus height & width animation too!
Cause appears related to content overflow and the appearance of the scrollbars, which changes the dimensions of the animated container as the content is toggled. For some reason even though I am only requesting a fade transition, it is animating a size change and creating the unwanted effect of moving the content on screen.
Link to: Example with slow duration to better see what is going on -- You can see the animated-container width and height being animated in the inspector. The fade transition is used here.
Twiddle example (slow duration) -- Make sure to reduce your window size so that when the menu is shown, it has to scroll.
Thought maybe it was an issue with the transition type. But the animation of animated-container occurs even if I used an empty transition type, eg:
myTransition: function * ({ insertedSprites, removedSprites }) {
},
The expected behaviour of applying an opacity/fade transition should be that only opacity/fade be animated.
How to prevent the width and height animation of animated-container?
It is possible to create unexpected behaviors in the "The power of promises" example on the website. If you click two options back and forth on a steady interval, before the animation completes, the animation gets into a strange state. As you continue to do this, it seems like the velocity of the items slowly increases.
So that's one issue. A related problem is that a coworker of mine was also able to get the cards into a broken state, where cards would stop in a mid-transition state.
Clicking in this way could be written off as nonstandard user behavior, but I frequently require animations where the user can input before the transition completes, so this kind of use case is important to me. To give a concrete example, consider keyboard navigation with a 350ms input throttle paired with a 450ms animation duration.
Perhaps this is just a consequence of the specific way that this example was set up; I'm not sure! But I figured I'd open an issue anyway.
When I updated to the newest ember-cli, I had to disable several new template lint rules.
It is hopefully straightforward to pick one of those rules, re-enable it, and fix the templates to follow the rule.
Momentum seems to be a default property of most/all of the provided Motions, but I'm having trouble tracking down where it "lives".
Is it a part of the motions themselves, the code that is performing calculations on prior
tweens?
fade
seems like it does not have any sort of momentum. I'm basically trying to recreate this behavior for move
– a momentumless move, similar to what you'd have if you added a CSS transition
to an element – but I'm having trouble.
I can post some code examples but figured I'd start with this in case I'm missing an obvious place to look.
Honestly I'm not sure about how difficult it would be. But if we'd like to have something like iOS's swipe back gesture to go back (or forth), or 3D Touch interactions like peek and pop, we need the ability to control the progress of the animation based on some variable, ideally a percentage. So in the cases above-mentioned, we can calculate a percentage based on touch movement / force, to make our animation look more native and responsive.
Really appreciated if there are any feedbacks and/or discussions about it. Hopefully we could find a way to nail this.
When using ember-elsewhere you might not always want to provide a defined value (e.g. a page where nothing should be rendered in the elsewhere). Currently when passing an undefined value to an animated-value
and at the same time providing a key
attribute throws a Assertion Failed: Cannot call get with 'text' on an undefined object.
Seems to be originating from https://github.com/ember-animation/ember-animated/blob/master/addon/components/animated-each.js#L88
The default of 3000 is quite long, is it possible in userland to set a default?
Anyone opposed?
I find pods so much easier to work with...
The documentation is still severely lacking and the library can't really be used without doing lots of code spelunking. I consider this a bug and think the documentation should be prioritized as if the build were broken.
I wanted to do more on the content but have run out of resources to work on this for the time being. I wanted to capture some of my TODOs here for anyone interested in helping.
If anyone wants to take any of these on and wants some guidance, feel free to ping me here!
this.priorTween
which I imagine is where the stateful aspects of a motion come in, but it's not clear in the docs.) Often this built-in "momentum" is not what you want, i.e. if you use it on a collapsible panel it is unnatural. Need to document it and how to change/remove it.
I wanted to create an issue template with a link to a Twiddle Boilerplate I setup but the new issue template workflow is configured under a repo's Settings rather than just by making an ISSUE_TEMPLATE.md file in root.
I don't see settings and I think its because I'm neither an admin nor a member of the ember-animation
org. Could I get an invite to the org?
Hi! I learned about this addon at EmberConf, and I'm really wanting to start using it. I’m also participating in this quest issue to add TypeScript support throughout the Ember.js ecosystem. This will benefit to everyone who uses your addon, not just TypeScript users! (See here for an explanation.)
Are you interested in either converting the addon to use TypeScript itself, or in adding type definitions? I’d love to help out, if so! And if not, that’s just fine. Thanks!
I wanted to reopen the discussion about exporting EA's modules from the top-level namespace:
// current
import { fadeIn } from 'ember-animated/motions/opacity';
import move from 'ember-animated/motions/move';
// proposed
import { fadeIn, move } from 'ember-animated';
I was chatting with @twokul and @kellyselden and they said Rollup had the ability to tree-shake this style of import. I know you mentioned it is not part of the language-level module specification, but if this feature of Rollup allows us to (eventually) tree-shake packages organized like this when the time comes, what do you think about moving things over today?
Heya, so we merged some major refactors upstream to Ember's Descriptor system, we thought we'd found all users of it but missed this library. The gist now is that Descriptors are now stage 1 decorators, and Ember.defineProperty knows how to apply them as such.
You can see how we updated Ember Concurrency here, and using ember-compatibility-helpers
it should be possible to do something similar here without breaking changes. I'll try to submit a PR as soon as possible, but if anyone wants to take this on in the meantime let me know, I'm happy to help and provide guidance!
Hi!
First thanks so much for this awesome library.
I hope here is the right place to ask my question. Please let me know if I should rather do it somewhere else.
I am trying to build an image slider with ember-animated.
animated-value
like this for the transition. Would you recommend a different approach?I am trying to transition the images by scaling and changing the opacity (cross dissolve). Changing the opacity is working great, but scaling it in and out is not working as intended. Basically I am trying to recreate the transition here: http://spacialtheme.herokuapp.com/2.6/index-photography.html
here is my approach, but I get an error in the console. Guess it is not the right way to use scale
.
import { parallel } from 'ember-animated';
import scale from 'ember-animated/motions/scale';
import opacity from 'ember-animated/motions/opacity';
export default function * ({ removedSprites, insertedSprites, keptSprites, duration }) {
removedSprites.map(s => {
if (s.revealed) {
parallel(
opacity(s, {
to: 0,
duration
}),
scale(s, {
from: 1,
to: 1.2,
duration
})
);
}
});
insertedSprites.concat(keptSprites).map(s =>
parallel(
opacity(s, {
to: 1,
duration
}),
scale(s, {
from: 0.8,
to: 1,
duration
})
)
);
}
Any hint or comment is appreciated.
Testing on IE11 gives me this error in the console.
SCRIPT5009: 'Symbol' is undefined
File: vendor-8336295e6bef0390b14bd99dbe877138.js, Line: 6682, Column: 133
Which looks like it is due to ember-animated
code
6679 try{for(var s,u=a(e)[Symbol.iterator]();!(n=(s=u.next()).done);n=!0){var l=s.value
6680 if(l.isEmberAnimatedListElement)r=l.get("child.id")
6681 else if(null!=r){var c=this._ancestorObservers.get(l)
6682 c||this._ancestorObservers.set(l,c=new Map),c.set(t,r),r=null}}}catch(e){i=!0,o=e}finally{try{!n&&u.return&&u.return()}finally{if(i)throw o}}return this},unobserveAncestorAnimations:function(e,t){var r=!0,n=!1,i=void 0
'Symbol' is undefined
6683 try{for(var o,s=a(e)[Symbol.iterator]();!(r=(o=s.next()).done);r=!0){var u=o.value,l=this._ancestorObservers.get(u)
It would make sense because before adding ember-animated
the site was working.
Should IE11 be supported? If so, I think this is quite important.
Thanks.
I'm finding myself using this pattern a lot when experimenting with "staggered" behavior in my animations.
Say I have this transiiton:
removedSprites.forEach(fadeOut);
keptSprites.map(sprite => {
fadeIn(sprite);
move(sprite);
});
insertedSprites.forEach(fadeIn);
and I want to see what it looks like if I let the removed
/kept
sprites finish animating before moving onto inserted
. I'll do something like this:
removedSprites.forEach(fadeOut);
keptSprites.forEach(sprite => {
fadeIn(sprite);
move(sprite);
});
+ yield wait(duration);
insertedSprites.forEach(fadeIn);
This is easier than using Promise.all or .map
or something, and conceptually what I'm really trying to express is something more like yield settled()
. What do you think, is that something that can be done or would be good to add?
Accessing an item's index is allowed in normal ember each loops. Please allow this to happen with animated-each so that we can more easily swap out the original loops.
It's time for docs. Most likely we should use https://ember-learn.github.io/ember-cli-addon-docs/
Sources for learning how things work:
The following is a burndown list of things that need to be described:
Many of these already have comments in the code.
This you can mostly learn from looking at the nine existing examples. The public API for Motion authors is to implement:
I believe this behavior is different for AnimatedValue.
In AnimatedValue
's template, we
whereas in AnimatedIf
, we see just a
The problem is if a relevant piece of state to the {{#animated-if}}
block changes, that block will change during an animation.
If I click the button to toggle isShowing
to false
, the contents will change from isShowing is true
to isShowing is false
as the animation has begun.
I think we want to preserve the state at the time the value changes to properly animate out the block?
If I do this
even with an empty transition, my "animation in" is smooth:
That's because <TimeControl>
appears immediately, and Container takes care of sliding things in.
When I toggle it to false, though, it immediately disappears.
If I add a simple transition like
removedSprites.forEach(sprite => {
sprite.endAtPixel({ y: window.innerHeight });
move(sprite);
});
then the sprite "hangs around" for the duration of the transition.
What I'm looking for is the easiest way to make the Sprite just "stay in place" for that duration. This coupled with Container's behavior, should give it the appearance of sliding down.
I tried a few things to get this working, notably combinations of
sprite.reveal();
sprite.applyStyles({
opacity: 1
});
yield raf();
which I found by looking at how the built-in motions were implemented – but no luck.
Any ideas on how I can write this sort-of identity/no-op motion, that just says "stay put" for the duration?
Changes to the ComputedProperty API mean that ComputedProperty#constructor now takes an array instead of a function: https://github.com/emberjs/ember.js/blob/707a938e536cb921dbe80ee270c431d1b9717e38/packages/@ember/-internals/metal/lib/computed.ts#L168
Which breaks the usage in TaskProperty#constructor: https://github.com/ember-animation/ember-animated/blob/master/addon/-private/ember-scheduler.js#L26
After upgrading to Octane, I got an Cannot read property 'unlock' of null
, thrown by this line:
I put a breakpoint there and have found that this.sprite
is not set to the correct sprite because this._ownElement
returns null:
So this.sprite
remains its initial value, null.
That, in turn, is because this._ownElement
is only set if this._inserted
is set to true and that happens in the didInsertElement
hook which is called after we get to the line that calls this.sprite.unlock()
.
The code I have is as follows:
Not sure how this is related to Octane but this has worked in the non-Octane version, in 0.5.1 of ember-animated.
I have a (removed) Sprite which I animate with a custom Motion which behaves kind of like toRight
from liquid-fire. If the page is scrolled down before the transition begins scrollY is still detected as 0. I suspect the detection happens "too late".
I have tried to track down why this happens, but have not yet succeeded. Within the findOffsets
method in the Sprite class (where scroll detection happens) the scroll position is already 0. It is correctly detecting that the effective offset parent is body
.
When manually checking window.scrollY before the transition happens, the scroll size is of course detected correctly.
There are no other scroll containers.
(cc @cibernox because you said you were working on fixing related issues)
I think it's important that we continue to run the test suite with RAISE_ON_DEPRECATION, so we aren't causing deprecations in consuming apps.
But the tests suite also includes all of ember-cli-addon-docs, which itself pulls in a ton of addons. Quite often some of those trigger deprecation warnings, and it would be better to just accept the warnings until the authors can fix them.
Thus, I want to make it possible to test only our own code using RAISE_ON_DEPRECATION, and test the docs site without RAISE_ON_DEPRECATION.
We should either split things into two dummy apps, or setup a feature flag around all usage of addon docs so we can do a CI run with the docs removed.
In the documentation there's an example:
But what is initialInsertion
and finalRemoval
? What is the string argument index-route
?
Also, what is the function of hero.hbs
? I see it invokes {{animated-orphans}}
, but I can't find where the component for hero
is called.
Thanks for any help
I found the need for a "wait" motion like liquid-fire provides (i.e. for keeping certain elements on screen while another animation finishes).
Sample implementation:
//ember-animated/motions/wait.js
import Motion from 'ember-animated/motion';
import { wait as timeout } from 'ember-animated/concurrency-helpers';
export default function wait(sprite, opts) {
return new Wait(sprite, opts).run();
}
export class Wait extends Motion {
constructor(sprite, opts) {
super(sprite, opts);
}
* animate() {
yield timeout(this.duration);
}
}
and use:
// some component.js
function * someTransition({ removedSprites }){
removedSprites.forEach(sprite => {
wait(sprite);
});
}
This can of course also be done by yielding the wait/timeout directly in the transition's generator function, but then the duration would need to be provided there.
Let me know your thoughts.
Liquid Fire has a delay
attribute that can be set to delay the start of an animation. The equivalent functionality appears to be missing in ember-animated. Is that the case, or if not, is it possible to delay an animation?
With the fix for #96 in place, the next thing I bumped into is that when the list that animated-each
loops over changes, the app hangs and CPU usage of the tab hovers very close to 100% (the process needs to be shut down). It works fine the first time the list is rendered.
Looking into where it does that I've found that it's the yield afterRender
where the code hangs:
Drilling further down it seems like the schedule('afterRender', ...)
line is called a few times but then no more (and the hanging ensues). The cancel(ticket)
line is never entered though I'm not sure if that should tell us something.
ember-animated/addon/-private/concurrency-helpers.js
Lines 93 to 102 in d7ee355
@ef4 In your commented code to another issue, you wrote that afterRender
is supposed to wait for Ember to finish rendering. If you meant route-driven rendering, the app doesn't do that in response to the changed list.
Do you have a hunch of what the reason for this should be?
Here is the relevent js and template code:
export default class IndexController extends Controller {
sortBy = "standard";
@tracked model;
@tracked sortBy;
get sortedPlayers() {
return sortBy(this.model.toArray(), [this.sortField]);
}
get sortField() {
return {
standard: "rankings.standard",
rapid: "rankings.rapid",
blitz: "rankings.blitz",
age: "age"
}[this.sortBy];
}
// eslint-disable-next-line require-yield
* transition({ /* insertedSprites ,*/ keptSprites/*, removedSprites */ }) {
keptSprites.forEach(sprite => move(sprite, { duration: 500 }));
}
@action
sortPlayers(value) {
this.set('sortBy', value);
}
}
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.