Amazing idea!

Q2: no

Q3: animate.out

Great Idea. Especially the Callbacks will be very useful in my opinion.

Wow 🤩, it would be great to use and implement all these powerful new CSS properties and get the full potential out of them. In my opinion, as I said earlier in the comments, the callback function will be the best feature proposed compared to what already exists (KIS 👍 ).

Q1 : Yes

Q2 : No, not really useful

Q3: No preferences as long as it's explicit

Q4: Callback function, 100% for simplicity and readability

Q5: To be able to debug / track problems with transitions or performance losses linked to animations in Angular Devtools( or to add direct compatibility with what Chrome already offers)

I think these Animations would be very useful. Other frameworks require external libs for handling the animate-out for example. It would be really nice to have such features.

Q1: It's a good idea but I also would offer to style the animation in a Stylesheet by a custom CSS selector, since Angular is known to be better scalable in large codebase and separating HTML and CSS / SCSS is always a good idea.

Q2: To keep it consistent I would prefer animate.in. As a framework user I would expect to have the opposite of animate.out. Another reason for having an animate.in is to pass some handler function to animate.in. This behavior is not covered by CSS / SCSS and can be a new feature.

Q3: It's shorter to write animate.in or animate.out instead without having a tradeoff in understanding, so I would prefer these.

Q4: In this case Option 1 is more modern and doesn't require any creation or handling of Promises by offering the same features. It's API is clearer.

Q5: Testing an element with the new Vitest Support (or different Unit-, E2E-Frameworks) against before/after styling states can detect breaks in Styles. But instead, I would first focus on a clear animation API since testable animations on the presentational layer are a bit to overcomplicated by now.

Discussion Question 1: Should these options support setting styles directly like ngStyle bindings? (see example)

I don't believe that's necessary. Given that both string/array values are supported, this should make Tailwind and other atomic CSS be able to do similar to what ngStyle does anyway.

Discussion Question 2: Is animate.in strictly necessary given the platform supports this behavior already?

I don't feel strongly here. I would prefer using @starting-style, but the argument for symmetry makes some sense. If it's tree-shakeable, I don't see any downside (except larger API surface for the Angular team).

Discussion Question 3: What is your preference on the naming? animate.in and animate.out? animate.enter and animate.leave? Something else?

While I do like the terseness of in/out, I wonder if it would be better to align with @starting-style, such as using perhaps start/end or start/exit. I don't think enter/leave is better in any way, other than that it helps keep terminology from @angular/animations. I think my preferred order would be:

1. [animate.start] + [animate.end]
2. [animate.start] + [animate.exit]
3. [animate.in] + [animate.out]
4. [animate.enter] + [animate.leave]

Discussion Question 4: Which of these 2 options for using functions is the most ideal to you, and why? Do you have an alternative suggestion?

Option 2, for a couple of reasons. A Promise fits well with the mental model of something that "completes later" (inherent with transition/animation), as well as fitting better with existing element.getAnimations() and the Animation.finished property.

animateFn = (event: AnimationEvent) => {
  const allDone = Promise.all(event.element.getAnimations().map(a => a.finished));
  event.waitUntil(allDone);
}

The example provided for this option can be simplified using Promise.withResolvers(). This adds minimal overhead to the callback-based example, and the API makes it aligns well with other web platform features like Service Workers.

animateFn = (event: AnimationEvent) => {
  const { promise, resolve } = Promise.withResolvers();
  animate(event.element, {
    x: '16rem',
    delay: 500,
    loop: 2,
    alternate: true,
    onComplete: resolve,
  });
  event.waitUntil(promise);
}

Discussion Question 5: What would you want out of testing tools for animations?

Not sure I would actually test animations personally in unit tests. As long as the everything looks right after enter/leave animations.

1. Should animate.in and animate.out support direct styles (like ngStyle)?
Yes, but only for simple cases, like an option that u can have. It would be useful to set quick animations without creating CSS classes (I know its not a good practice but still). For example:

<div [animate.out]="{ opacity: 0, transition: '0.5s' }"></div>

But for complex animations, CSS classes (and tailwind) are still better because they keep the code clean.

2. Is animate.in really needed if CSS already has @starting-styles?
To make Angular more consistent, Yes. If we have animate.out, it’s good to have animate.in too as well. Also, animate.in can automatically remove CSS classes after the animation as said, which @starting-styles doesn’t do.

3. What names are better? animate.in/out or animate.enter/leave?
animate.enter and animate.leave are clearer names imo. They are easier to understand, especially for new developers. Other frameworks like Vue use similar names (enter/leave, I don't think they changed it), so it’s a familiar pattern.

4. Which is better callback function or ExtendableEvent?
The first option for me, is simpler and more familiar, why familiar? 'cus GSAP and Anime.js they are using callbacks like (onComplete) so it feels natural. Again most Angular developers already use callbacks in other parts of their apps. Promises can be confusing for beginners as well. Also, the 4-second timeout is a good safety feature imo

5. What should testing tools for animations do?
Just test animations when needed, tools to check if animations work correctly especially with third party libraries.

Nice to see something like GSAP into this.

it reminders me of something I did back in the day building overlays:

<div class="canvas_container">
@animate(in: {
  opacity:0
  x:-300px // or any other measure that indicate out of the stage, container, or screen...
  delay: 3000 // or some sort of function or promise that observe other elements so animations can be chained or handled manually
  transform: {...}
}, out:{
  opacity:1
  x:600px // or any other measure that indicate out of the stage, container, or screen...
  delay: 100 // or some sort of function or promise that observe other elements so animations can be chained or handled manually
  transform: {...}
}, ... other parameters?: {...}) {
<component />
}
</div>

parameters could be anything like events, callbacks, etc...

notes on in/out: from the perspective of a canvas, elements go in our out. enter or leave are probably synonyms with the same purpose, however a mouse can "enter" or "leave" an element, in our out acts more on the context that elements on the DOM are in the screen as elements of a scene in a canvas.

Question 2: being able to set a specific (dynamic) css class on enter of an element would be beneficial to further fine grain an intro animation. Like the direction of which an element should animate from. Another example would be an animation via GSAP that would can use a local signal for its calculation when an element is added.

I really like this proposal. It seems much simpler and more ergonomic compared to the old @angular/animations. I can’t wait to use it in my applications. Thanks for modernizing animations in Angular!

hi,

1. Animation naming-style

both animation name in, out does make sense for naming animation, however enter and leave can every body know that about when element or component inserted or removed from DOM,

we can associate or bind a class names or arrays of class names to enter & leave

<component [enter]='class-name-expression'/></component>
<component leave='[class1, 'class2', 'class3, ... class-n']'/>

2. Animation callback

both enter & leave should be handle animation event like (start, complete, restart if user refresh while prev animation not complete yet)

type AnimationCallbackHandler {
     onStart: () => void | {},
     onComplete: () => void | {},
     onRestart: () => void | {}
}

and associate this type with enter and leave

<component (enter.onStart)='callback function when animation start'/'>
<component (enter.onComplete)='callback function when animateion complete'/'>
<component (enter.onRestart)='callback function when animation restart''/>

3. Animate Route Navigation

combine this new style of animation with modern navigation style view-transition

Discussion Question 1: Should these options support setting styles directly like ngStyle bindings? (see example)

While I'm generally for giving a bit more freedom, it would add unnecessary typing complexity to directives. Unless you want to make something like animate.out and animate.out.style.

Discussion Question 2: Is animate.in strictly necessary given the platform supports this behavior already?

What if I want to use GSAP for in and out - using animate.out directive and defining "in" animation in completely different place I would need to look for then? Not saying about tracking whether some condition changes to show the element and then waiting for next render to actually put it into DOM.

Having animate.in would not only provide opposite option but also allow to keep things consistent (one place for in and out animations; same way of defining them). As I understand argument with CSS' @starting-style, some people may see it as more consistent and clear to use both directives than defining "in" and "out" in two completely different places. I wouldn't force opinions here

Discussion Question 3: What is your preference on the naming? animate.in and animate.out? animate.enter and animate.leave? Something else?

in and out is shorter and explanatory enough

Discussion Question 4: Which of these 2 options for using functions is the most ideal to you, and why?

I see event.animationComplete() as more clear way in case of events

Discussion Question 5: What would you want out of testing tools for animations?

Possibility to disable animations in e2e testing to speed them up - not sure if you covered this in FAQ#5. In general some possibility to switch animations dynamically would be good if possible (eg. user decided to enable reduced motion)

Other than that some benchmarking / performance

Discussion Question 1: Should these options support setting styles directly like ngStyle bindings? (see example)

No, but mostly because I don't like ngStyle either and don't think animations should need it.

Discussion Question 2: Is animate.in strictly necessary given the platform supports this behavior already?

Strictly necessary ? No. Sensible? Yes, for the reason you mentioned of having a symmetrical API. If you provide animate.out, given the history of the angular animations package, I expect also to find an animate.in, even if technically it's not that necessary.

Discussion Question 3: What is your preference on the naming? animate.in and animate.out? animate.enter and animate.leave? Something else?

enter and leave, solely for consistent vocabulary with angular animations and because they're solid words for this.

Discussion Question 4: Which of these 2 options for using functions is the most ideal to you, and why? Do you have an alternative suggestion?

No preference

Discussion Question 5: What would you want out of testing tools for animations?

At my workplace we mostly want to be able to test "Is this specific animation running?". I think for that purpose it would already suffice if I could check if the CSS class associated with the animation is currently being applied or not.

The rest would just be able to use tick to skip to the end timepoint of an animation which should then trigger corresponding aniimationEnd events (whose effects would then be tested for).

I wish Angular supported global animations for @if(cond) {} blocks, with the ability to override them like @if(userData, custom_animation_name) {}. This would be especially helpful when dealing with async data fetched from the backend, so that some animation plays when the data is retrieved.

My comments will be from the perspective of library maintainer. So this is written under assumption that component code isnt directly available to the consumer.

Discussion Question 1: Should these options support setting styles directly like ngStyle bindings?

Yes! This would allow to make a simple Input to pass in animation styles. Supporting only class based animation will require to break encapsulation with ng-deep or global styles which is dangerous and risks leaks. Style object can be declared as const and reused safely.

Discussion Question 2: Is animate.in strictly necessary given the platform supports this behavior already?

Yes! This is very important for dynamically configured animations. as well for consistency. I would hate to have half of my code use new API for out and rest is some mix of different approaches. Also for some complex library animation configs its important to have extra control via callbacks.

For example: I would trigger parallel animations in some components/directives which would in turn trigger stagger animations inside to create layout with multiple columns where each column staggers its elements in parallel. The animation itself is configured via DI and can be overridden per element. Elements also remember their animation in case they were toggled via @if . I would need in out callback functionality to make something like this without @angular/animations

We should also add support for animate.in and animate.out in hostbindigs and @HostBinding() to make it possible to encapsulate reusable animation logic in directives.

Discussion Question 3: What is your preference on the naming? animate.in and animate.out? animate.enter and animate.leave? Something else?

in-out is more concise. It is clear its a new API not like enter leave of the old animations.

Discussion Question 4: Which of these 2 options for using functions is the most ideal to you, and why? Do you have an alternative suggestion?

Option 1: Callback function. If i were a junior developer I would not want to think what it this all extra syntax is for or have some funny async await ideas. I dont see any need to make it a promise because animateFn wont be awaited. it relies on callback in both cases(resolve()) just with extra syntax on second case.

Q1: Yes
Q2: No
Q3: animate.out
Q4: callback