Re-evaluate usage of TextTruncator and optimize its performance

Observed behavior

TextTruncator triggers layout reflows that on pages with many instances of TextTruncator can cause significant performance issues, as observed in #7525.

This is the first part of the profile (at some point my laptop runs out of resources and doesn’t record anymore) of Learn section of Ciencia Espacial topic containing 1151 sub-topics (which means 1151 of TextTruncator instances) of Ciencia NASA channel where the following bottlenecks can be observed:

As can be seen from the following, for a page containing hundreds of TextTruncator instances, there is an enormous number of expensive style calculations and layouts/reflows run.

Performance analysis for a single TextTruncator instance:

(1) TextTruncator -> mounted -> ResizeSensor (KResponsiveElementMixin) -> attachResizeEvent

1 style recalculation	1 layout/reflow

(2) TextTruncator -> ResizeSensor (KResponsiveElementMixin) -> resetExpandShrink

1 style recalculation	1 layout/reflow

(3) TextTruncator -> handleUpload -> shave

around 6 style recalculations	around 6 layouts/reflows

---

Currently, we useTextTruncator in the following components and can expect similar performance issues on all pages utilizing them:

• LessonContentCard
• ChannelCard
• ContentCard

---

Related KResponsiveElementMixin background by @indirectlylit

For some context, the responsive element mixin (and resize sensor) were originally an attempt to emulate element queries. The intent was to better support responsive behaviors for complex layouts where it’s the available space determined by the layout (as opposed to the overall window size) which should influence internal responsive behaviors of a child component.In practice though, I think we rarely use it for that reason. A more common use I’ve seen of the resize sensor is for smart text-eliding behaviors. For example, I think the breadcrumb component uses a responsive element to drive rendering details.

---

Let’s re-evaluate what are our requirements for text truncation in Kolibri while taking these performance issues into account:

• Is the usage of TextTruncator build around KResponsiveElementMixin and shave for so many instances of the component on one page valid?
• Do we need so granular information about layout updates all the time?
• Can we avoid using ResizeSensor in some situations?

Based on the outcome of the discussion, do we need to ask KDS team for any updates of KResponsiveElementMixin?

This issue could set a precedent for recommended usage of KResponsiveElementMixin elsewhere that will be together with performance warnings ideally documented in KDS.

Errors and logs

Source performance profile (can be loaded in Chrome)

Expected behavior

The components mentioned above are performance-wise optimized

User-facing consequences

• Slow loading and navigation or complete unresponsiveness
• Unnecessary device battery drain (? not an expert)

Steps to reproduce

• Import Ciencia NASA channel
• Navigate to Learn -> Channels -> Ciencia NASA -> Ciencia Espacial

Context

Kolibri 0.15.0.dev0+git.20210520221349 Chrome Ubuntu

[indirectlylit]

For some context on the original motivations – TextTruncator was added in https://github.com/learningequality/kolibri/pull/3508 to satisfy a few goals:

• Set a fixed maximum height on a block of arbitrary-length text, with width responsive
• Maximize use of allocated screen real estate by filling in bottom line of text completely
• Only segment between full words
• Use a real ellipsis character that will be read correctly by screen readers, and have it located correctly relative to the last visible word

[MisRob]

In any case, before we dive into particular optimizations, it would be good to discuss some high-level questions raised in the description. I don’t know what were the reasons for implementing TextTruncator in this way and if it’s okay to simplify it, or reduce its usage, or if there are good reasons to continue using it as is.