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.
In touch environments, I used an ApplciationGestureManager instance to manage this scenario.
Sure. A very simplified example:
{{#each model}}
{{list-item transitionIn="fade"}}
{{/each}}
Just a thoughtā¦
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?
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.
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?
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.
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.
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.
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.
Ember Liquid Fire came out recently and it uses Velocity for animations. https://github.com/ef4/liquid-fire
Thank you for mentioning this, it seems to completely resolve an issue.