[tabs] Maintain fluent animations on navigation

[Peppe]

Menus sometimes have animations attached to view changes. However, changing a view usually does big changes to the DOM as well. That means a lot of work for the browser, which means that FPS will drop, and the animations tied to the nav feels very laggy. The perceived performance take a huge hit if the animations are laggy, even if the app would be fast.

As a workaround in Bakery for Flow, we have implemented a debouncer to paper-tabs that wait until the navigation is played to the end before the software reacts on the click. This makes the app slower measured in milliseconds, but it feels tremendously faster as it is not hacky.

There are two downsides to this approach:

1) It doesn't do any work at all until the animation is finished, which makes the measured rendering time higher. For this, you could maybe send the events to the server and accept the answer from the server, but only update DOM after the animation has finished

2) If you quickly browse through views, then the menu gets hacky again. With two subsequent view changes, the rendering of the first view change will affect the animation of the second view change.

[jouni]

Thanks for the use case!

We should try to distill the relevant portions from it that only affect the tab bar component, and not the things that happen in the view porition that it controls (i.e. the content area), as I got the understanding from @Peppe’s description that we should somehow control the rendering of the view content as well.

The vaadin-nav element’s responsibility is only to provide information what item is selected, and the content view should react to that information.

[Peppe]

Where should you handle this?

[jouni]

Not sure yet. I just wanted to point out that this element does not control the content in any way, it just exposes a “selected item” property to which you can react to in any way you want to.

So I think the only way for vaadin-nav to affect this is to delay the update of that “selected item” property after any possible transitions/animations. And I think that should be an opt-on optimization options, not the default.

[manolo]

We might have some property/attr in the tabs component to temporary disable it. Something like

<vaadin-tabs selected="2" disabled="[[animating]]">
   ...
</vaadin-tabs>

The UI doing animations u operations is responsible to set/unset the animating flag here.

I see another use case here, where the user might prevent changing the page when something is in edition, or the device is offline, etc