gigafied / ember-animate Goto Github PK

consider a subclass, or flag. We likely shouldn't subject every view to this extra functionality and weight.

Considerations for using as a mixin rather than building it into every view? I haven't dove into the source to see how the hooks are being called but it does irk me a bit that every view that might or might not use animations has extra hooks being called. I don't notice any perceptual performance difference either way. Thoughts?

Just a note saying thank you. Your work here is very nicely done. Implementation was a breeze, and it's been very helpful to read the source. The complexity is in a sweet spot, being both a little hard to follow while not overly difficult. Definitely have learned a lot about customizing Ember with all of it's hooks.

Cheers!

I have a view (as modal) that i want to animate when being called from route to open as outlet. AnimateIn is not working (doesn't get triggered). Is this the correct behaviour?

This is a bit off topic, but i have the dismiss animation as css class. So adding and removing the class animates the view, is it possible to run the destroy after a css animation?

Hello,
Thanks for the great tool! I've really enjoyed using it so far. However, I'm having an issue strictly on pages that have to load a model from an external resource.
I initially found that with some specific pages, the animate-in wouldn't work sometimes. If an animation was triggered, the incoming view would just appear immediately, superimposing the new page on the previous page for a few milliseconds while the previous page animated out. Part of the weirdness is this only happens about half the time. It may happen, it may not happen.

I then linked this to only occurring on incoming pages with external models. I tried commenting out the models, and sure enough, the animation would work perfectly every time.

I'll note (on the off chance it's relevant) that I'm using async animations. Is this a known issue, or is there something I perhaps missed? Thanks.

EDIT: I think I may be mistaken on the trigger: I believe it may be related to transitioning using transitionToRoute() in an action vs a link-to handler, rather than being related to the model.

Hi,

I have implemented the ember-animate as you can see here:
http://emberjs.jsbin.com/bitacixi/15/edit

For the animations I use hardware accelerated css transitions by integrating following library: https://github.com/daneden/animate.css

So far so good but unfortunately I do not achieve a good mobile user experience by having native feeling page transitions. Actually, I would like to offer an user experience that is similar to: http://coenraets.org/blog/2013/03/hardware-accelerated-page-transitions-for-mobile-web-apps-phonegap-apps/

Do you have some recommendations how I could get this animation flow working with your plugin?

First off... Awesome work on this library! I was able to get it up and running with nested views. Everything is working great so far, especially considering that I have spent less than a day or two with Ember.js.

I have one little snag that I am not sure how to solve. I have a child route that accepts a parameter:

this.route('design', { path : ':app_id' });

The animation works when I first enter the child view but 'switching' to the same view with a different parameter does not trigger an animation.

Is this an issue or did I miss something? The parameter drastically changes page content and I would like to animate this transition.

Here is a JSbin that demonstrates the issue. Navigate to about/team, and then click the "Index" link to navigate back to the index. At this last transition you will see that the "Team" content residing in the about template's outlet disappears right as the App.AboutView starts to animate out.

http://emberjs.jsbin.com/gegib/1/edit?html,js,output

After successfully using your plugin (thanks for closing the issues in the past) I now realised, using jQuery for animation is a bit sluggish, especially on mobile.
The best solution I have found is using css-animations. I am getting it half-working but I think the issue is with the callback not being called properly.

So the way I am doing it now, I have css defined:

#main > .ember-view.hide {
  height: 0;
  max-height: 9999px;
  overflow: hidden;
  @include vendorise(transition, height 1s ease-in-out);
}

Then my code for the animation itself, is so far:

App.AnimatedView = Ember.Mixin.create({
  //$el: null,
  height: 0,
  willAnimateIn : function () {
    this.set('height', this.$().height());
    this.$().addClass('hide');
  },
  animateIn : function (done) {
    this.$().css('height', this.get('height') + 'px');
  },
  animateOut : function (done) {
    this.set('height', 0);
    this.$().css('height', this.get('height') + 'px');
  },
  didAnimateOut : function () {
    console.log('Test'); //does not get called
  }
});

This code is probably not perfect, but animating in and animating out works the very first time. Then it seems didAnimateOut doesn't get called and in fact any route change doesn't seem to call any of the callbacks anymore (if I add a console.log()), which I suppose is due to the missing done call. I know there are callbacks for css-animations. Any idea how this could work with css-animations or would you need to add support for that?

What kind of licensing are you planning for this?

I am working on a mobile-focused app, and am trying to replicate the slide-in right/slide-out left view transition effect that's commonly seen in many native apps. To achieve this, the existing view must be animated out (sliding out of the viewport to the left), while the new view is animated in (sliding into the view port from the right) simultaneously, so that you actually see the content of both views briefly as they are animating.

Here is my initial stab at this using ember-animate:
http://emberjs.jsbin.com/fijof/5/edit

As you will notice, it currently has two issues; The animateIn animation doesn't start until the animateOut animation has finished, even though I am calling done() in animateOut w/o waiting for its animation to complete. Additionally, right as the animateOut animation begins, you will notice a quick flash of content that is to be displayed in the new view that is animating in.

Am I going about this the wrong way? In my initial experimentation I found that I had to clone() the element of the view that was to be animated out, in order to retain its content while it was animating, as ember re-uses the view's element when transitioning to a new view. However this feels like a kind of hackish, and potentially expensive way to workaround that fact, and would love to get some input on it and maybe find a cleaner and more elegant way to solve it.

Hi,

I just found this and started playing around with it. I have used the code from the readme, but still face some issues. When refreshing the browser window on my views the effects are working. But as soon as I link-to a new page, the whole outlet stays empty.
When removing ember-animate my links are working again.
Any idea what could cause this?

While calling this.destroy() on an Ember.Component it looks like the isDestroyed property remains false even after the willAnimateOut, animateOut, & didAnimateOut sequence has fired.

First off, thanks for the great plugin! Super easy to get up and running with :)

I've got a collection of items, and I'd like to animate views as they enter and leave the collection. I've put together a simple JS Bin illustrating the scenario -- it appears the elements are being removed from the DOM before the animation has time to execute.

It's more than possible I'm just mis-configuring this, so if that's the case I'd be grateful for a pointer in the right direction. Otherwise, I don't have a complete enough understanding of Ember's ContainerView to know whether this case should be (or even can be) accounted for, or if it's simply a limitation of the view stack as it stands today.

Hello. At ember 1.7.0. In order to avoid hundreds of warning messages, it is asked to rename "transitionTo" .. to ... "_transitionTo". I understand this breaks backwards compatibility (ex: 1.6.1), so, it's possible to use a simple if Ember.VERSION == "1.7.0" (or so) in the meantime.
Thanks

What is your thought on animating the parent when entering a nested route?
For example: /parent/child; I want to animate parent, when I enter a child.

Not sure why, but view elements are not getting removed from the DOM. Probably has something to do with defering _super()

I'm having a problem using ember-animate to animate transitions between two different views in the same outlet.

The animateIn event on the second view runs at the same time as the animateOut on the first view. I have played around with how the callback is handled, and found that the result is the same even if I don't call the callback. I am testing with the sample code provided in the readme.

I am transitioning views via route actions, like this:

   flipToAdding: function() {
      this.render('files-added', {
        into: 'application',
        outlet: 'main'});
    }

The Views are barebones, copied directly from the readme, then changed for troubleshooting:

    AddFileView: Ember.View.extend({
      willAnimateIn : function () {
          this.$().css("opacity", 0);
      },

      animateIn : function (done) {
          this.$().fadeTo(500, 1, done);
          console.log("animatein1");
      },

      animateOut : function (done) {
          this.$().fadeTo(5000, 0, function() {
            console.log("animateout1");
            done()
          });
          // used to be 
          //  this.$().fadeTo(5000, 0, done);
      }
    })

    FileAddedView: Ember.View.extend({
      willAnimateIn : function () {
          this.$().css("opacity", 0);
      },

      animateIn : function (done) {
        console.log("animatein2");
          this.$().fadeTo(500, 1, done);
      },

      animateOut : function (done) {
          this.$().fadeTo(500, 0, done);
      }
    })

Upon transition, you see the first view animate out and the second view animate in immediately. The console shows animatein2, followed by animateout1 after 5000ms.

This behavior is the same even if I remove the call to done() in the first view's animateOut.

I'm using Ember 1.7.0

Even though you use the 'version' tag in the bower.json when ember-animate is specified ~0.2.1 doesn't work. Only *.
I don't have that much bower experience myself, but could this be because you don't tag releases?
Would be helpful to have, to ensure people run on the same version.

Currently if you try to change a view while it is animating, you get weird, unexpected behavior.

I get the following error when trying to install via Ember addon:

$ ember install:addon ember-animate
version: 0.2.4

A new version of ember-cli is available (0.2.7). To install it, type ember update.
The specified command install:addon is invalid. For available options, see `ember help`.

Upgrading to Ember CLI 0.2.7 didn't help. The same issue happens.

Can you please add an example of mobile-phone sliding animations similar to the current opacity animations examples. idk why for the death of me i can get my head around it.

Thanks!

DFO

Getting this error in the console on page load:

Uncaught Error: Assertion Failed: You cannot access this.$() on a component with `tagName: ''` specified.

It's coming from the _afterRender method at the beginning of the ember-animate code. This was working just fine back when I was on ember-cli v0.2.0, but has stopped since I updated to v0.2.3. Ideas?

I started using ember-animate in an ember-rails project and I've noticed the frustrating:

Assertion failed: You have turned on testing mode, which disabled the run-loop's autorun. 
You will need    to wrap any code with asynchronous side-effects in an Ember.run

error. I started getting it after trying to add rails-qunit. But I can only remove it by not loading ember-animate.js. Its possible this is unique to me (some strange set up quirk) but thought I'd report it as it seems localized to your lib.

http://jsfiddle.net/L7zBb/3/

You can see that the views never mark themselves as "destroyed" so they don't get cleaned up, leaving a growing number of Ember._chainNodes. This growth is visible by taking heap snapshots in the Chrome profiler. There are only a couple bindings on these views so the accumulation is minimal, but it can be a significantly bigger problem on a real app with lots of computed properties and observers.

When ember-animate is removed the problem goes away. I'm assuming it has something to do with the custom destroy method.

I am looking in to a fix but thought I would post this here as it took me many hours to figure out why my application was leaking (lots) of memory.

Hi,

Besides using this awesome component for my outlets I wanted to use it as well for my mobile menu. Currently the mobile menu is always rendered into the DOM but not always shown. I am showing it with help of the isVisible variable of the View.

My view looks like this:

GambifyApp.MobileSubMenuView = Ember.View.extend({
    templateName: 'partial/mobile_sub_menu',
    willAnimateIn : function () {
       this.$().addClass('animated-menu slideInRight');
    },

    animateIn : function (done) {
         this.$().addClass('animated-menu slideInRight');
         Ember.run.later(this, done, 500);
    },

    animateOut : function (done) {
         this.$().addClass('animated-menu slideOutLeft');
         Ember.run.later(this, done, 500);
    },

    menuVisibleTriggered: function(){
        this.toggleProperty('isVisible');
    }.observes('controller.menuVisible')
});

Unfortunately it seems that animations are only triggered if the View is actually removed from the DOM. Unfortunately I am really new to Ember and don't really know how to get around this.
It seems to me that animations on isVisible changes are not foreseen. Maybe it would make sense.
Maybe they are even triggered but the view is already hidden.

Alternative: Are there maybe any other functions that I could call to triggere the animation flow?

First of all, I gotta say thanks for that plugin, this seems to be the first one that can easily achieve the kind of transitions I want.

But for one of my routes/views the slideUp or hide call in the animateOut hook throws an error as seen below.

The one main difference that I see at a first glance is, that I am rendering a different template/view into the route using renderTemplate, like this:

App.VideosIndexRoute = Ember.Route.extend({
  renderTemplate: function() {
    this.render('videos.our-work');
}

I am also using query-params and the setupController hook to set up some custom models, but can't really imagine that this would have any effect. But might try to do some more testing around.

Here's the error:

Uncaught TypeError: Cannot call method 'hide' of undefined combined-scripts.js:1061
App.VideosOurWorkView.Ember.View.extend.animateOut combined-scripts.js:1061
superWrapper ember.canary.js:1267
Ember.View.reopen.destroy ember-animate.js:55
superWrapper ember.canary.js:1267
Ember.View.Ember.CoreView.extend.destroy ember.canary.js:24522
superWrapper ember.canary.js:1267
superFunction ember.canary.js:7781
proxy jquery.js:818
(anonymous function) ember-animate.js:59
run ember-animate.js:5
Ember.View.reopen.animateOut ember-animate.js:44
Ember.View.reopen.destroy ember-animate.js:55
superWrapper ember.canary.js:1267
Ember.View.Ember.CoreView.extend.clearRenderedChildren ember.canary.js:23665
superWrapper ember.canary.js:1267
(anonymous function) ember.canary.js:24030
Ember.View.Ember.CoreView.extend.invokeRecursively ember.canary.js:24115
superWrapper ember.canary.js:1267
Ember.View.Ember.CoreView.extend.remove ember.canary.js:24029
Ember.merge.childViewsWillChange ember.canary.js:25678
Ember.ContainerView.Ember.View.extend.childViewsWillChange ember.canary.js:25592
Ember.ContainerView.Ember.View.extend.replace ember.canary.js:25534
Ember.MutableArray.Ember.Mixin.create.removeAt ember.canary.js:17956
Ember.MutableArray.Ember.Mixin.create.removeObject ember.canary.js:18128
Ember.ContainerView.Ember.View.extend.removeChild ember.canary.js:25598
superWrapper ember.canary.js:1267
Ember.CoreView.Ember.Object.extend.destroy ember.canary.js:22618
superWrapper ember.canary.js:1267
superFunction ember.canary.js:7781
Ember.View.Ember.CoreView.extend.destroy ember.canary.js:24508
superWrapper ember.canary.js:1267
superFunction ember.canary.js:7781
proxy jquery.js:818
(anonymous function) ember-animate.js:59
run ember-animate.js:5
Ember.View.reopen.animateOut ember-animate.js:44
Ember.View.reopen.destroy ember-animate.js:55
superWrapper ember.canary.js:1267
removeOldView ember-animate.js:110
(anonymous function) ember-animate.js:116
superWrapper ember.canary.js:1267
sendEvent ember.canary.js:2572
ObserverSet.flush ember.canary.js:2716
endPropertyChanges ember.canary.js:2911
DeferredActionQueues.flush ember.canary.js:6190
Backburner.end ember.canary.js:6271
Backburner.run ember.canary.js:6310
Ember.run ember.canary.js:6720
Ember.EventDispatcher.Ember.Object.extend._bubbleEvent ember.canary.js:22366
(anonymous function) ember.canary.js:22315
jQuery.event.dispatch jquery.js:3074
elemData.handle jquery.js:2751

Hello folks ;)

I'm facing an edge case. I currently display a list of meetings based on the route's dynamic segments.

this.resource('meetings', function () {
    this.route('list', { path: '/:year/week/:week' });
    this.resource('meeting', { path: ':meeting_id' });
  });

The route list is animated, and it plays well when I enter it for the first time. BUT, I would like to be able to "replay" the same animation when I navigate the same route with other values for the segments.

Exampe
Transitioning from /meetings/2014/week/45 to /meetings/2014/week/46 would replay the animation.

Do you think there's a way to do it ?

Just a heads up, when using ember-animate with ember 1.7.0-beta1, I'm receiving the following deprecation console message:

DEPRECATION: Ember.View#transitionTo has been deprecated, it is for internal use only

Looks like its originating from line 149:

this.transitionTo('destroying', false);

I'm Getting "Uncaught Error: Assertion Failed: calling set on destroyed object" with 0.3.6 from line https://github.com/gigafied/ember-animate/blob/master/ember-animate.js#L205

Maybe we should add a check there if self is destroyed/destroying? i can create a pull request if you think that would work well.

not sure exactly whats going on.. but animate out is working perfectly... animateIn not so much.

i currently have 2 views

script handlebars... id="index"
and

script handlebars ..... id="signup"

this is my views::
App.IndexView = Ember.View.extend({
willAnimateIn : function () {
this.$().css("opacity", 0);
},

animateIn : function (done) {
    this.$().fadeTo(500, 1, done);
},

animateOut : function (done) {
    this.$().fadeTo(500, 0, done);
}

});

App.SignupView = Ember.View.extend({
willAnimateIn : function () {
this.$().css("opacity", 0);
},

animateIn : function (done) {
    this.$().fadeTo(500, 1, done);
},

animateOut : function (done) {
    this.$().fadeTo(500, 0, done);
}

});

any suggestions?

Using this code:

https://gist.github.com/larsbs/9941943

I currently have a component, let's call it some-component. I also have a template with logic similar to this:

{{#if somethingIsTrue}}
   {{some-component someStuff=...}}
{{else}}
   ...
{{/if}}

I have the following animation methods defined on the component:

willAnimateIn: function() {
        this.$().hide();
    },
    animateIn: function(done) {
        this.$().slideDown({ done: done });
    },
    animateOut: function(done) {
        this.$().slideUp({ done: done });
        Ember.run.later(this, done, 400);
    }

The animation in works fine, but the animation out does not. I tried it with and without Ember.run() but I think the problem is that the component itself is nested in some handlebars logic. What would be the proper way to perform an animateOut on this component before it was removed?