Smarter, efficient rendering (like Button Card does)

[kulmegil]

Is your feature request related to a problem? Please describe.
Config Template Card requires that all entities used inside card: to be listed in the config under entities: key.
This is because it doesn't update hass object in the rendered card.

On the other hand Config Template Card will always re-render entire DOM content every time state changes.
Even if the resulting card config is identical then previous one.

You may say content never updates, only constantly re-renderes.

Describe the solution you'd like
Render smarter - like Button Card does.

Button Card does not require implicit entity_ids in order for rendered cards/rows to update.
It does require ids in order to evaluate JavaScript templates but the content can update independently.

When Button Card evaluates templates it compares result to previous one.
It only renders content when evaluated config actually changes.
Aside from performance improvement benefits this reduces issues of elements resetting state while being interacted:
e.g. dropdowns or Fold Entity Rows collapsing back because being re-rendered.

Describe alternatives you've considered
Using Button Card is a good (and only?) alternative because it can do client side JS templates (and config templates) very efficiently.

But at the same time it's bloated with features already, has complex syntax and comes with some built in css styling that are annoying to reset back when used as a general templating card. It was built to be a button card on steroids... and there are too much steroids already.

Additional context
none

[ildar170975]

Vote for this.

The problem is that config-template-card not only does a "full redraw" of a card but does not actually updates graphs!
Compare these cards with graphs:

type: custom:config-template-card
variables:
  HOURS_TO_SHOW: states['input_number.test_number']
entities:
  - '${HOURS_TO_SHOW.entity_id}'
  - sensor.processor_use
card:
  type: history-graph
  entities:
    - sensor.processor_use
  hours_to_show: '${HOURS_TO_SHOW.state}'
  refresh_interval: 0

  type: history-graph
  entities:
    - sensor.processor_use
  hours_to_show: 6
  refresh_interval: 0

While the 2nd graph only updates a line when the sensor.processor_use changes, the 1st card does a total redraw which may take some time - and does NOT update the graph itself!
#87

Update 19.03.25: currently the 1st card definitely updates the inner graph (as well as mentioned "total redraw").

[LastElf]

Sorry for the notification guys, but throwing in a "me too." On top of FER collapsing it also breaks rendering in bar-card (Honestly the only reason I'm using it to set max to a sensor, I'm considering not using CTC if it's going to cause rendering issues like this but I really don't like hard-coding); animation doesn't animate and the arrow markers don't render because it doesn't consider the bar to have been state changed.

I'm using it in an entities card, which is stacked with a few entities and bar-cards each, I have to wrap CTC around the whole entities card and have it monitor all the entities in that card instead of specifying just to the bar-card that it should be wrapping because the rendering broke in the 2022.11 update and now it considers CTC to need its own card styling instead of being an invisible div.

[twister36]

Ok, So is this why the card "blinks" when you change the state of an entity, that the whole card is redrawn?

[PaulSD]

On the other hand Config Template Card will always re-render entire DOM content every time state changes.
Even if the resulting card config is identical then previous one.
You may say content never updates, only constantly re-renderes.

You seem to be suggesting that this is caused by a design flaw in CTC (that can be fixed by redesigning CTC to be more like the Button Card), but I suspect it is more likely either a bug, or a quirk specific to your use case.

CTC (and most of the rest of the HA frontend) use the "Lit" framework to render content. Any time a potentially relevant change occurs, Lit components are supposed to "re-render" everything (in a virtual DOM), then the Lit framework compares the virtual DOM to the real DOM and updates the real DOM as needed. (The idea is that updating the real DOM is expensive and hard to do efficiently, but updating a virtual DOM is cheap, so you can rebuild the virtual DOM from scratch after every change to simplify things for developers, then let the framework figure out how to detect DOM changes and replicate the virtual DOM to the real DOM efficiently.)

CTC appears to be doing what it is supposed to be doing here - It is re-rendering the virtual DOM on every relevant update and letting Lit decide whether the real DOM should be re-rendered. If the virtual DOM hasn't changed after a render, then Lit shouldn't be re-rendering the real DOM. I don't believe there should be any need for CTC to explicitly compare current and previous template rendering output to eliminate duplicative rendering - that is Lit's job.

If the real DOM is being re-rendered unnecessarily, this likely suggests either a bug in Lit, or a bug or quirk in CTC causing it to do something that makes Lit think the virtual DOM isn't matching the real DOM after each change (like maybe rendering nothing into the virtual DOM on one update, then rendering the correct output into the virtual DOM immediately after that; or including a timestamp or random number in some HTML attribute that it is rendering; or something like that, although I don't see anything like that in the code).

Regardless ... We've made lots of library and code updates in 1.3.7 - Please try that and see if this issue still exists.

[PaulSD]

Possibly related: #144 (comment)

I wonder if there might be a bug in helpers.createCardElement() (in HA itself) causing it to return a slightly different UI element on each call which then causes Lit to re-render too much? I haven't tried to trace that out yet, but that would probably explain the issue in the above comment, and might explain some of the other user complaints about excessive re-rendering that we've seen.

[Mariusthvdb]

since you asked in the other discussion, I'll add here:

In my experience, the views that had (..) template-entity-row cards were extremely heavy in the frontend, and oftentimes caused it to become sluggish or worse.

because of that, Ive minimized the use of the card to a bare minimum, and, admitted, can't say whether the last few updates have taken away the earlier troubles the card caused.

We've been talking about that for a few years now, so can't be much of a surprise really.

The couple of cards I still use it with (apexcharts-card eg) are system hogs them selves, so yes, that might be asking for it.
otoh, it seems to be doing well now, but, the c-t-c is only used I. those configs to set the span of the graph.
Iow, not really a challenge because of a frequently updating entity.

In the cases we did make templates based on more frequently changing entities, the card started to cause trouble.

So, in stead of adding an option to have the card update on all hass updates, my suggestion would be different: add an throttle option to update once a minute/any time frame. Just like Apexcharts card has.

Using that in Apexcharts actually made the views a lot more stable, and not go berserk.

currently I use only these configs, not sure if it helps the discussion, but it illustrates why I use the card in the first place (no native option in the relevant cards, or alternative in core HA), and illustrates the limitation for the type of variables/templates I set:

Sankey is really responsive

type: custom:config-template-card
entities:
  - input_select.sankey_min_state
variables:
  min_state: states['input_select.sankey_min_state'].state
card:
  type: custom:sankey-chart
  title: Energie verbruik
  show_names: true
  height: 500
  round: 2
  wide: true
  unit_prefix: k
  min_state: ${min_state}

Manual Panel History seems ok:

title: History domain
path: history_domain
type: panel
subview: true
cards:

  - type: entities
    entities:
      - entity: input_number.history_span
      - entity: input_select.domain

      - type: custom:hui-element #extra entities to keep header while scrolling
        card_type: entities
        entities:
          - type: custom:config-template-card
            entities:
              - input_number.history_span
              - input_select.domain
            variables:
              span: states['input_number.history_span'].state
              domain: states['input_select.domain'].state
            card:
              type: custom:auto-entities
              card:
                type: history-graph
                hours_to_show: ${span}
              filter:
                include:
                  - domain: ${domain}

The mentioned span in Apexcharts:

type: custom:config-template-card
entities:
  - input_select.apex_span
variables:
  span: states['input_select.apex_span'].state
card:

  type: custom:apexcharts-card
  update_interval: 1min
  graph_span: ${span}
  series:
    - entity: sensor.zp_actuele_opbrengst
      color: var(--power-color)
      type: area
      name: Zon
      stroke_width: 3
      opacity: 0.5
    - entity: sensor.bruto_stroom_verbruik
      color: darkblue
      name: Verbruik
      group_by:
        func: avg
        duration: 2min
      stroke_width: 1
    - entity: sensor.netto_verbruik
      color: lightblue
      type: area
      name: Vermogen
      group_by:
        func: avg
        duration: 2min

Hope this helps

[PaulSD]

I have confirmed that any time the CTC render() function is called (even if the return value of helpers.createCardElement() has not changed), Lit does delete and re-create the entire real DOM tree associated with the card element returned by helpers.createCardElement(), including all child card elements in the real DOM.

I have also confirmed that the standard behavior of Lit is to compare the shadow DOM to the real DOM after each render, and only update the real DOM if the shadow DOM has changed (and only update the specific parts of the real DOM that have changed in the shadow DOM, without deleting and re-creating the entire real DOM tree).

This seems to confirm that there is a bug within or related to helpers.createCardElement(), although I haven't found the root cause yet.

I plan to investigate more as time permits.

[PaulSD]

I think I have figured this out. Basically, HA is misusing Lit.

Lit is designed/intended/documented to have render() return a Lit Template, which Lit then converts to a tree of Lit Component objects in the Shadow DOM. Some similar libraries (such as React) also support having render() create and return a tree of Component/Element objects directly (using React.createElement()), instead of returning a Template that is converted to Component/Element objects. However, while returning objects directly is technically possible in Lit (using document.createElement()), it is not documented or supported, and it breaks Lit's DOM management/cache/update behavior (because Lit uses ===/isSameNode() to compare objects nested in the tree returned by sequential render() calls, instead of using isEqualNode() like some other frameworks, since Lit doesn't expect render() to return Component/Element objects), which means that your render() implementation becomes responsible for managing/caching the Shadow DOM objects between render() calls in this case.

Unfortunately, most (but not all) of the HA Lovelace code returns a tree of Lit Component objects rather than a Lit Template. This includes helpers.createCardElement(), which is used by CTC to render Cards.

So, effectively, CTC was trying to use Lit as designed/intended/documented, but that doesn't work right because HA is abusing Lit.

Ideally, HA should be refactored to use Lit properly. (To return Lit Templates instead of Lit Component objects in all places where a Component is created/rendered.) However, that is likely to be a big project, as it will require updating lots of existing code/cards/components/etc, and will probably require maintaining backward compatibility interfaces to support existing custom Cards.

As a work-around, I think I now understand the HA and Lit behavior well enough to implement something in CTC to handle this gracefully. I will incorporate this into the refactor that I am working on in #159.