Animation support in Ember 1.1

[seilund]

Great questions.

@machty

What happens when the user clicks on buttons during transitions? What happens when the user navigates (clicks the back/forward buttons) during a transition?

Maybe nothing special. I propose in this first iteration that only one animated transition can happen at the same time. If another transition is requested while animation is being performed, the transition is queued (like I mentioned in “Transition flow” #1. See also “Known limitations” #2. Same with back/forward buttons: The transition is simply queued.

@machty

How would you handle something like the (now out of date) github source tree drilldown transition, where you click a directory, and the current level slides left out of view, puts up a spinner while waiting for the drilldown data to come back from the server, and then the new frame comes in?

I believe (maybe I’m wrong) that the GitHub file tree only slid once: User clicks, file tree slides to the left, animation spinner is sliding in from the right, once new files are loaded the spinner is replaced with real content (no second slide effect). You could solve that using a {{#if model.files.isLoaded}} in your template. If you want to have two slide animations, like you describe it, this is a way to do it (using sub-states as we talked about in Is there a reason we can not have nested routes? - #16 by machty):

App.Router.map(function() {
  this.resource('tree', '/tree/:node_id', function() {
    this.state('loading'); //New API that we will hopefully get
  });
});

//Represents a file/directory
App.Node = DS.Model.extend({
  name: DS.attr('string'),
  children: DS.hasMany('App.Node')
});

App.TreeIndexRoute = Ember.Route.extend({
  model: function() {
    return this.modelFor('tree').get('nodes'); //Should be a thenable
  }
});

App.TreeIndexController = Ember.ObjectController.extend({
  didClickNode: function(node) {
    var self = this;
    this.transitionTo('tree.loading', node).then(function() {
      self.replaceWith('tree.index');
    });
  }
});

tree/loading.hbs would show the spinner. tree/index.hbs would show the file list and have {{action didClickNode node}} for each file. Since they are “sub-states” the URL would not change (which makes sure that a deep-link will never take a user to a loading state). It doesn’t matter how long time the files are to load, the app will transition to tree.index once both the first animation has completed and the child nodes has been loaded (since we’re returning a promise in App.TreeIndexRoute’s model method. A Transition should be resolved as soon as animation starts, which will enqueue the next animation. This is actually a perfect example of when sub-states would be awesome to work with.

@machty

Furthermore, as much as you might support a wildcard route path that facilitates a filesystem-resembling URL scheme, this Github transition example is really just an example of when you’re on FolderShowRoute and switching between models represented by the URLs (e.g.) “/foo” and “/foo/bar”. Perhaps this is more of an implementation consideration, but this is an example of when you’ll have 2 FolderShowViews on the screen at the same time, one for the outgoing “/foo” and one from the incoming “/foo/bar”. Is such a thing supported given your present thoughts?

Do you mean if it’s supported to have two instances of the same route’s view on screen at the same time? Not currently, but that will have to be changed to support animated transition from and to the same route with a different model.

@machty

I’ll have more later, just curious about these for now. In short, these basically make me think these animations ought to be more state-ful, so that you can intelligently handle events fired and now have to handle, in multiple routes, logic pertaining to if(isTransitioning/animating).

Please say more :). I like the thought that they ought to be more stateful. Imagine if the animation effect was a class instead of a plain function. That way it could have a stop hook and other “stateful operations”. Example:

Ember.SlideLeftEffect = Ember.Effect.extend({
  animate: function() {
    this.get('newView').$().transition({...}, this.done);
  },

  stop: function() {
    this.get('newView').$().stop();
    this.done();
  }
});

Effect names could also be looked up through the container in this example. E.g. container.lookup('effect:slideLeft'). I actually like the effects as classes better.