Documentation example problemo about ember-animated HOT 7 OPEN

This can close when #107 merges. Thanks.

from ember-animated.

Here are the screenshots of the issue after clicking back and forth a little bit:

from ember-animated.

Yes, making all interruptions work correctly is one of the founding reasons this library exist.

This is a bug in this particular demo, although I would like to change a default behavior to make this kind of bug harder to stumble into.

The collapse, shuffle, and shuffleWithStagger transitions all need to place the sentSprites into their final positions immediately as the transition begins:

for (let sprite of sentSprites) {
  sprite.moveToFinalPosition();
}

That fixes the bug.

I would like to make this behavior the default, but it will require a corresponding change to the way motions are defined, because right now they assume this behavior.

from ember-animated.

Thanks for the reply!

transitions all need to place the sentSprites into their final positions immediately as the transition begins

I don't fully understand the technical solution you described (as I'm not currently a user of the lib), but I have a follow up question: will items ever "jump" in the solution you described, or will they smoothly transition from the current animation into the new one?

from ember-animated.

In more detail: the sentSprites are present but invisible during all these transitions. That is, you always have two copies of each image: one in the sending component, and one in the receiving component. The demo always moves the receiving one and leaves the sending one invisible.

In an effort to be helpful, ember-animated pre-positions both the received and sent images at the initial position (the place where the move should start). But since the demo doesn't do anything with the sent image, the sent image lingers there in that position.

But when an interruption occurs, the sent image is still lingering in that weird position, and it can continue to influence the starting positions of the next transition.

The change I want to make is to not automatically move the sent sprites (and indeed, not automatically move any sprites), and instead require each motion to affirmatively declare when it wants a particular sprite to go to initial or final position whenever it expects one of those.

from ember-animated.

Nothing should ever jump. If you patch the code snippet I shared above into each of the three transition functions in that demo, everything is smooth no matter how many times you go back and forth clicking wildly.

Well, there is one exception in this demo, although it seems to be intentional. The z-index changes take place instantly, so that whatever images are the incoming ones jump above the outgoing ones.

Probably there is a different strategy that would avoid this, at the cost of sometimes allowing outgoing images to be above incoming ones.

from ember-animated.

Very cool. I appreciate the thorough response, @ef4 ! I wasn’t able to change the example on the site, but it’s nbd, I believe ya’ 🙂 .

Since it sounds like the resolution to this problem is known, would you like me to close this issue?

from ember-animated.