Think about chances for optimizations when clicking a link during a visit about swup

[daun]

Sounds like a great topic to explore on a call sometime 🔮

[daun]

We‘re listening for transitionend so I think we‘re covered. There’s a timeout there too, but that‘s a fallback if there‘s more or less properties transitioning than expected.

[daun]

I guess we could always expand the current checks we're doing to identify and ignore visits that have been superseded by a new one in the meantime.

// Abort if another visit was started in the meantime
if (visit.id !== this.visit.id) {
  return false;
}

[hirasso]

That will be one part of the solution for sure – I'm unsure about these two:

1. how do we cleanly cancel/restart CSS animations? Something like
   1. remove animation classes
   2. wait one tick
   3. initialize the next visit
2. how would we go about it if the user clicks another link during the out-animation?

Does animating still make sense in this scenario at all, if we think about special animations for routes (Route Name Plugin, JS Plugin)? My initial thought was that the cleanest approach would be to cancel eventually running animations altogether.

[daun]

Regarding 1, that sounds perfectly reasonable.

On point 2, that's already solved, at least when using CSS class-based transitions. The above check visit.id !== this.visit.id will effectively just drop any visits if during the out-animation another visit was requested. Adding the css class for the out-animation again will not really do anything. For clicks during the in-animation, this will not yet work, as well as for JS animations, as these do get repeated, I think.

I agree that dropping any existing visits and short-circuiting would be best, i.e. cancel running animations. This would probably only work if CSS transitions are bound to html.is-changed, otherwise we don't have a way of safely removing the transition from the element.

[hirasso]

Part 2 is not completely solved I think. The animation promise of a new visit during the out animation will retrieve the wrong animation duration, since it will just read the transition/animation duration from the element, ignoring already elapsed animation time. We'd need to somehow detect the current process of the animation somehow and subtract that from the duration, don't we?

[hirasso]

Or are we listening for the transitionend/animationend event? I'll need to revisit the source code 😅

[hirasso]

While investigating I found that is-leaving is not part of swupClasses and thus won't be cleared on classes.clear(). Seems to me to be unintended. Found out about it by finding that is-leaving sometimes persists on the html element upon rapid navigation.

[daun]

Solved in #836 and landing soon ☺️