[1.2 branch] Need a way to opt into the old animation behaviour for ui-view

[jonrimmer]

In 0.2, animations are applied to the child elements of the ui-view. However, in the 1.2 branch, this has been changed so the animations are applied on the ui-view element itself, which is cloned when the view changes.

Unfortunately, this approach breaks a vital styling requirement: The ability to use the :empty CSS selector to style the ui-view when it contains no child elements, e.g. when it has no view selected, and then transition to a different appearance when a view is selected.

This plunkr demonstrates how it is done in 0.2: http://plnkr.co/edit/B31D5b?p=preview

As far as I can tell, this example is impossible to replicate using the 1.2 branch. Neither ngAnimate nor a wrapping element can be used to achieve the same effect.

I suggest that ui-view defaults to the new animation behaviour, in order to match Angular 1.2, but provides a switch that replicates the old behaviour if required.

[nateabele]

Haven't looked at the plunkr yet, but just wanted to note that ngAnimate doesn't even exist in 1.2.

[jonrimmer]

Um, yes it does, it's just a module now, and the application of the animation is implicit based on the class name of the ui-view, rather than an ng-animate directive.

However, the behaviour of the ngAnimate module is actually beside the point. The important thing is how the ui-view directive deals with adding and removing view elements. Previously they were added as children of the element which had the ui-view directive applied. Now an anchoring comment element is inserted and the views are new elements inserted after it.

This means that :empty CSS transitions on the ui-view element will not work, because its is a new element. And an :empty transition on an wrapping element will not work, because the ui-view always retains an element in the DOM, even if there is no view loaded.

This plunkr demonstrates what happens for the same situation in the 1.2 branch, even if the animation module is not included: http://plnkr.co/edit/dQMKHD?p=preview

[timkindberg]

Hmmm, I'd say that, currently, styling via the :empty psuedo selector is more novel than vital. I'm sure most css developers often forget about that selector completely. That being said, I think its an awesome idea and could become vital and commonly used, but I wouldn't consider it vital enough to steer the direction of an implementation.

I am curious how this could be achieved though in some other way. At first I was thinking of using the $stateChangeSuccess handler to add a class to the view called ".show" which would cause it to pop out, but then remembered that adding classes to elements should only be done in directives.

Really your User Story is that you want to be able to animate the ui-view when its populated with content. I don't think using :empty is a requirement here.

[jonrimmer]

I think the bigger user story is that, intuitively, I expect the ui-view to be a persistent element that acts as a container for my views, not an ng-repeat style stamp that is cloned and removed when views are added and removed. Being able to reason about when it is populated and when it is empty, and apply styles appropriately, falls out of that. Some kind of other mechanism to animate transitions to and from an empty state might solve the requirement, but it will never be as performant as a simple CSS selector, and is just a hack on top of an unintuitive design.

I believe you are following Angular's lead in this new design and, frankly, I think it's a mistake on their behalf, seemingly intended mainly to remove the requirement to wrap view templates in a root element. Maybe it's not a big problem for the single ng-view approach, but in UI Router applications, when you have lots of named views representing sidebars, drop-down menus, etc., being able to style and transition them in this way is very important. I say this as as someone who has spent the past six months working on a very complex Angular app using the UI Router.

[timkindberg]

Well perhaps we should consider keeping with the old approach, but will that break all newer nganimate usages? Is it ugly to give the option for both? Seems ugly. Is the old way THE way we should do it and we should be opinionated about it? To the point of not doing it the new way at all?

[nateabele]

After reading over the explanation a few times, I think rolling back to the previous (well, current) behavior makes the most sense semantically.

@jonrimmer It's gonna be a while until I have time to mess with it, but you're welcome to submit a PR against the 1.2 branch. Just please make sure you follow the dev guidelines. Thanks.

[jonrimmer]

Thanks. I will definitely try to get a PR done.

[irony]

Tell me if you need any help with the PR, we have implemented a workaround and would love to do it the right way.

// Christian

[ecurtis]

@irony I would be curious to know about your workaround...

[irony]

We are setting the current state as class on the body which makes it easy in CSS to do conditional transitions based on which state that is active. It is not ideal but works pretty good.

[eddiemonge]

This seems like it has been resolved in the PRs or at least it can be worked around.

You can/should/please also try the new feature-1.0 branch that is in development to see if it satisfies this. Keep in mind this is still in development but it is the direction the project is heading. If you want to file a ticket against this branch, use the format 1.0: (subject) for the subject.

Thank you for supporting and contributing to the project.