Rendering performance of QScrollArea #16813
Labels
area/components
bug/1-repro-available
A reproduction is available and needs to be confirmed.
flavour/quasar-cli-vite
kind/bug 🐞
Qv2 🔝
Quasar v2 issues
What happened?
Changes to computed values (e.g., mouseenter leading to thumb display, scroll position change after pressing arrow keys with scrollable element in focus, thumb hide after timeout) used in QScrollArea component trigger re-render of the entire component stack housed within. While DOM manipulations don't occur after diffing, as no content changes are detected, all the render methods are nevertheless called.
What did you expect to happen?
I came around to investigating this after noticing an abnormal activity of
vue-i18n
using global fallback translation when rendering item lists. Scrolling in the list would trigger a lookup of localen-US
translation, then localen
translation, then move to looking up globalen-US
translation for every templated string (and in my case list items contain multiple such strings) resulting in hundreds and thousands of i18n invocations (andvue-i18n
warning messages due to fallbacks happening) for a relatively short list.Reproduction URL
https://jsfiddle.net/ycabj26f/
How to reproduce?
Additional context
Quick inspection of QScrollArea and the compiled render function reveals this behavior as "expected".
Since all the computed value updates relate to thumb display, the straight forward solution would be to pull out the thumb rendering logic into pure JS world. I also suspect there is a way to rewrite the render function (rather than relying on the compiler) using vnode creation calls to mark the child nodes (ones inserted via the slot) as isolated from thumb-related nodes.
Known workaround
For those that are seeking a workaround, you can use
v-memo
orv-once
on your components rendered within QScrollArea. But make sure you understand how they behave, before using them in production.The text was updated successfully, but these errors were encountered: