Can we make the ViewSlot animateView logic more Generic and Open?

Framework Knowledge
1

In Aurelia it is really difficult to react to dynamic changes to the markup that result from if and repeat.for binding updates. I was testing a custom attribute that extended the attached method on the view to enable this and I noticed that the logic for animateView is set up to be the perfect hook for my purposes.

After the ViewSlot is attached/detached it calls the animateView method which looks for an animatableElement and if it finds one it passes it into this bit of logic:

  switch (direction) {
    case 'enter':
      return this.animator.enter(animatableElement);
    case 'leave':
      return this.animator.leave(animatableElement);
    default:
      throw new Error('Invalid animation direction: ' + direction);
  }

Instead on looking for animatableElement (typically an element denoted with a ā€˜au-animateā€™ class) and calling the this.animator.enter or this.animator.leave functions we could instead use a binding:

The binding could be something like this:

<div if.bind="showElement" 
     animate-view="
       enter.bind: onElementEnter($element); 
       leave.bind: onElementLeave($element)">
</div>

or something like this:

<ul class="accordion">
  <li repeat.for="item of list" 
      animate-view.bind="onAnimate($element, $direction)"
      class="collapsible ${$direction=== 'enter' && item.expanded ? 'expand' : 'collapse'}">
  </li>
</ul>

The element with the binding would be the ā€œanimatableElementā€ and the binding expressions would replace the default this.animator.enter and this.animator.leave methods. I think this would make it much easier to interact with dynamic content. Would a change like this be possible without creating a performance problem or breaking other aspects of the framework?

2 Likes
2

This is an interesting idea. The custom attribute could be virtually behaviorless, just capturing the values or functions. The animation system could check the currently animating element using the au property, looking specifically for this attribute class, using its values to configure or replace the current functions. I think the perf cost would be fairly negligible, as itā€™s just a few lookups. @bigopon What do you think?

Iā€™d love to get some more feedback from the community. This is an interesting idea.

On a related note, in vNext, the new lifecycle itself is much more open and extensible, so itā€™s possible using new official APIs to actually build stuff like this without requiring any framework code changes :slight_smile: Iā€™m pretty excited about the new vNext design innovations.

4 Likes