Can you believe that at this point we were only like half way through the first day?! I’m amazed at how much was covered so quickly.

The next talk was about animations and transitions. I have to admit, after the last couple of talks where I hadn’t yet had much hands-on experience with those tools, I was really excited for this one. The project I’ve been working on has had some animation and transition difficulties so I was interested in hearing why these transitions were potentially so complex and get some good ideas for moving forward.

The talk was give by Edward Faulkner. The talk “slides” are basically an awesome demo that you can continue to use as you experiment with different transition and animation types.

Ember animations fall into 2 categories of simple and complex. Simple animations are those that occur in the same route.

Sample: {{animate-changes of=how }}: this separates how I’m animating versus what I’m animating and then the actual animation happens in the css.

There are also components that have a toggle animated class which can have current and next specified.

<div>
  <div class="next">{{next value}}</div>
  <div class="current">{{current value}}</div>
</div>


In an ember component, you can also have a bound property. You can use bound properties to show what is happening (in the case of the demo- the font size is a bound property). You can track the state and bind it.

You can also have an animated if helper. Here, you can have a computed property in the controller that is related to the animated helper and in the template, you can dictate how to represent these situations.

The more complex animations are those that go between routes. These are much more difficult and there is no drop-in library that solves this. You need to figure out how to coordinate the transition and animation between the views, templates, controllers and routes. Referring to the slid e showing the parent to child transition, we're looking at a nested route. The parent route stays rendered and the parent controller has a computed property looking for the details controller, which can flip the class and trigger the css transition. This is a mouthful but it makes sense. Going back is a much more complicated story. One way to solve this is to enact willTransition. The example for this is in the presentation slides. I highly recommend checking it out because I don’t have notes from this part which means I was too fascinated by what was going on to write down the steps.

The last part of the talk discussed modals. A modal has a state and URL that is not tied to the route. But modals can be used with query params to bypass the router and go directly to the controller meaning that rendering the modal has its own css rules. BUT be careful because you need to animate the modal away as well which is more difficult. Just clicking on “back” or “ok” doesn’t animate it away, it just takes it away. At the end, a few mobile specific concerns were mentioned as well.