It seems like if you want to animate a transition between states using the new Ember.js router and outlets, you're out of luck, since the previous content of an outlet will be destroyed before you have a chance to animate it. In cases where you can completely animate one view out before transitioning to the new state, there's no problem. It's only the case where both old and new views need to be visible that's problematic.
It looks like some of the functionality needed to animate both the previous outlet content and the new was added in this commit, but I'm not sure I understand how to use it.
There's also been some discussion about using extra transitional routes/states to explicitly model the "in-between" states that animations can represent (here and here), but I'm not sure if it's currently possible to match this approach up with outletted controllers and views.
This is similar to How *not* to destroy View when exiting a route in Ember.js, but I'm not sure overriding the outlet
helper is a good solution.
Any ideas?
I am currently overriding didInsertElement
and willDestroyElement
in some of my view classes to support animations. didInsertElement
immediately hides the element and then animates it into view. willDestroyElement
clones the element and animates it out of view.
didInsertElement: function ()
{
this.$().slideUp(0);
this.$().slideDown(250, "easeInOutQuad");
},
willDestroyElement: function ()
{
var clone = this.$().clone();
this.$().replaceWith(clone);
clone.slideUp(250, "easeInOutQuad");
}
Personally, I don't want to start wrapping my outlets in superfluous ContainerViews just to support animations.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With