Animation support in Ember 1.1

Can you elaborate a bit more on your usecase? Thanks

Offhand, I think that the back-transition should be queued and executed as soon as the running animation has completed. Just like if the user clicks a {{linkTo}} or something.

It would be very nice to know when something is animating so we can disable sensitive items that might be accidentally clicked.

Apparently, I am in the vast minority, but Iā€™ve been doing heavy animation in web apps, mobile web apps and with Ember for years. Hereā€™s an example Ember app with heavy animation: http://migration.nikefuelstream.com/stream/bridge-the-gap

Animations should be controlled by Javascript and backed by requestAnimationFrame for maximum control and performance. Iā€™ve written more of my strategy online (How Do I: Animate Ā« Thomas Reynolds).

I believe Ember.js should adapt an existing Tween engine, such as Tween.js to be promises based. Tween & timelines (sequences of tweens) should be treated similarly to ajax and be able to delay route & state transitions until they have completed.

The limitations of a system where you cannot sequence transitions is huge. We should develop a robust system, not the lowest-common-denominator of ā€œcrossfading viewsā€. If animation were baked into Ember in a robust way, it could be used to control image sequences, run illustrated animations, respond to touch/mouse events and respond to scrolling for ye olde parallax.

Thanks for reading.

11 Likes

In touch environments, I used an ApplciationGestureManager instance to manage this scenario.

2 Likes

Sure. A very simplified example:

{{#each model}}
  {{list-item transitionIn="fade"}}
{{/each}}

Just a thoughtā€¦

2 Likes

It may be useful to understand how native frameworks do this, like CoreAnimation in iOS. I personally have no experience using it but it may provide some inspiration?

1 Like

Random thought: itā€™d also be nice to have support for something like this:

{{#if content animate="fade"}}
  I gracefully fade in and out!
{{/if}}

I guess if with animation params set would make the bound if view be a normal view vs a metamorphs view and apply some default (but overridable) classes while the element is animating in and out of existence.

Not sure how much overlap there is with the animated outlet stuff though.

4 Likes

Yes, we should definitely have this. else should also work. Also this:

{{#each things animate="effect"}}
  <div>{{name}}</div>
{{/each}}

Iā€™m working on some ideas on how all this could work.

Is it still planned to Ember 1.1?

1 Like

Not 1.1, but the work is slowly still in progress.

Hey all - I just finished adding animations to an ember app Iā€™m working on and wrote up my thoughts here.

I think the router promise system works really well with animations, and it would be great to see promise hooks on views so that people can build their own animated views, and then we can work out some best practices from there.

3 Likes

Is there plans for adding this as a feature flag in the canary build anytime in the near future? I am working on a new application that needs transition animations and is probably a few months away from being feature-complete, and I am just trying to gauge whether or not I should wait on this built-in animation support, or roll my own implementation.

1 Like

Give some help back at https://Github.com/EmberJS/Ember.js Youā€™ll save time from changing your implementation in the future and increase your reputation/credibility.

I need to implement some animations. Iā€™d be happy to contribute some help to this effort if thereā€™s an open PR I can look at (or even a fork to clone). Where is this work currently happening?

I have implemented a route animation API which I would like to share to be considered, I think is simple and could be used on multiple cases:

My main requisites are:

  • Be able to animate with CSS or JS.

  • A transition should be a step in my route transition process.

    Route.extend({

      animation: function(transition) {
    
        var applicationController = this.controllerFor('application'); 
    
        return this.animationPromise(transition, function() {
    
            applicationController.set('position', -1);
        });
     
      }
    

    });

    Route.extend({

      animation: function(transition) {
        return new Ember.Promise(function(resolve, reject) {
               $('#view-element').animate(xxxx, function() {
                    resolve();
               });
        };
      }
    

    });

animation hook supports returning a promise object on the same way than ā€˜modelā€™, ā€˜beforeModelā€™ and ā€˜afterModelā€™ hooks.

I think, that having integrated animation in the chained promise of the route transition solves some of the @machty considerations.

We could test right now this approach if we rewrite HandlerInfo.resolve method (router.js) like this example.

.then(animation, null, this.promiseLabel("Animation"))

I am sharing a working gist making animation with CSS classes bound to object properties which is the way I prefer. This examples requires to disable the renderTemplate default convention to have loaded all the route templates to have immediate animations.

Feedback?

I just found out about Velocity.js, might be a good option.

Velocity outperforms jQuery at all levels of stress, and Transit beginning at medium levels of stress.

5 Likes

If thereā€™s anything I can do to make Velocity.js (VelocityJS.org) seamlessly integrate into the Ember.js workflow, please let me know by opening an issue on GitHub: https://github.com/julianshapiro/velocity.

I am a huge Ember.js fan and user.

10 Likes

Ember Liquid Fire came out recently and it uses Velocity for animations. https://github.com/ef4/liquid-fire

7 Likes

Thank you for mentioning this, it seems to completely resolve an issue.