iantrich / config-template-card

📝 Templatable Lovelace Configurations
MIT License
452 stars 59 forks source link

Smarter, efficient rendering (like Button Card does) #112

Open kulmegil opened 2 years ago

kulmegil commented 2 years ago

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 commented 2 years ago

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! https://github.com/iantrich/config-template-card/issues/87

LastElf commented 1 year ago

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 commented 1 year ago

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