Nested Templates

[dcapslock]

Continuing from #1086

[dcapslock]

Earlier...

New example using just Date().now for label...

Nested 1 will only show an updated value every 5s, even though it has an update_timer of 1s. That is because it's label is generated as a value from the parent.

type: custom:button-card
entity: binary_sensor.donker_buiten
show_label: true
name: containing card (5s update)
update_timer: 5s
label: |
  [[[ return Date.now() ]]]
styles:
  grid:
    - grid-template-areas: '"n" "l" "nested1" "nested2"'
custom_fields:
  nested1:
    card:
      type: custom:button-card
      update_timer: 1s
      name: Nested 1 (1s update)
      show_label: true
      label: | 
        [[[ return Date.now() ]]]
  nested2:
    card:
      type: custom:button-card
      update_timer: 1s
      name: Nested 2 (1s update)
      show_label: true
      label: | 
        [[[[ return Date.now() ]]]]

[dcapslock]

Response from @Mariusthvdb

so

      label: | 
        [[[[ return Date.now() ]]]]

means: update the local template, based on the nested cards update frequency

and

    card:
      type: custom:button-card
      update_timer: 1s
      name: Nested 1 (1s update)
      show_label: true
      label: | 
        [[[ return Date.now() ]]]

means: update the local template based on the parent cards update frequency, no matter the child cards own update settings..

imho I find that utterly confusing... (obviously...) in all javascript used in HA [[[ return xxx ]]] means Render this as a template

I am not sure I can express myself clearly, but, if we'd need a way to have the child card follow the parent card, or be standalone inside a parent card, we should somehow find a new option for that. something like update_local: true/false, and not have to fiddle with extra pairs of []

because currently the 4th pair serves 2 purposes: not only the update frequency in you example, but also the entity used in my example.

I dont want to ruin/spam this issue tracker with my problem understanding the concepts at work, so please move this to a discussion if you feel that would be better.

[Mariusthvdb]

ok now my issue is with this

it explains something that I just dont understand to be not automatic.

why wouldn't the template on the nested card be always rendered. just like on any single card. This says the template is relative to the nested cards entity.
But to me that seems obvious, it Is on the nested card, why then would it be relative to any other cards entity in the first place?

take them apart, and thats how they work. nesting them should not make that change all of a sudden?

[dcapslock]

But to me that seems obvious, it Is on the nested card, why then would it be relative to any other cards entity in the first place?

A template could be on any type of card in a custom field. There is nothing special about the custom field being a button-card that would have the parent card not render it - its oblivious to the card type. I think this will be key to your understanding that nested templates is about the nesting of the template, not the nesting of the button-card. If say I had a reason to need a js style template (say card_mod style, but unlikely with button-card styles, but say it was needed) in a single button card, it would need to be nested - no child button-card involved. This is what is Nested Templates.

Perhaps the example needs some language tweaking? If you can suggest anything please do.

[RomRider]

During JS template evaluation:

• [[[ return "Hey there"; ]]] will result in Hey there
• [[[[ return "Hey there"; ]]]] will result in [[[ return "Hey there"; ]]]

It's as simple as that.

Then, if a card understands the resulting [[[ ]]] it can do something with it, that's why this feature has been introduced. Initially for browser_mod's popup but it can have other use cases.

[Mariusthvdb]

That is very clear, I needed that! Thx
(It’s almost like the raw technique in Jinja ...)

with that in mind I still need some effort to understand why my test example with nested button-cards in the other topic made the change in selecting the templated entity

4 pairs use the entity of the child card
3 pairs use the entity of the parent card

[dcapslock]

3 pairs and the parent evaluates the template to a value 4 pairs the parent evaluates the template to a template and the child evaluates the template to a value.

[il77781]

Maybe it would be necessary to include in the documentation a list of situations (with examples) in which the use of the number of square brackets corresponding to the level of nesting of the button-card is absolutely required?

[Mariusthvdb]

I keep getting back to this, which is Not explained by the Hey there example.

the child card using the entity in the template.
(there is no discussion for the parent card, its only about the use of more than 3 pairs on the child card)

4 pairs, and it uses the child card entity

3 pairs and it uses the parent card entity

[RomRider]

There is nothing specific about nested cards or not nested cards it's just how it's evaluated.

1. With 3 brackets (I've removed unnecessary stuff just for the sake of simplicity)

   You set this config:

   type: custom:button-card
   entity: sensor.terras_buiten_sensor_temperature
   custom_fields:
     nested:
       card:
         type: custom:button-card
         entity: light.bureau_marijn_lampen
         name: '[[[ return entity.entity_id ]]]'

   The nested card gets this config:

   type: custom:button-card
   entity: light.bureau_marijn_lampen
   name: sensor.terras_buiten_sensor_temperature # Literal string resulting from the template being evaluated by the main card

2. With 4 brackets

   You set this config:

   type: custom:button-card
   entity: sensor.terras_buiten_sensor_temperature
   custom_fields:
     nested:
       card:
         type: custom:button-card
         entity: light.bureau_marijn_lampen
         name: '[[[[ return entity.entity_id ]]]]'

   The nested card gets this config:

   type: custom:button-card
   entity: light.bureau_marijn_lampen
   name: '[[[ return entity.entity_id ]]]' # just 1 pair of `[]` removed by the evaluation done by the main card, and then because this nested card is a button-card and it knows what to do with `[[[ ]]]`, the nested card evalutes the template to `light.bureau_marijn_lampen` when it displays itself.

[Mariusthvdb]

wait, so the main/parent card is actually in control of the templates on nested/child card... I now see that is what dcapslock also said in #1093 (reply in thread)
sorry for not grasping that before.

let me consume that for a bit...

it does make me want to ask this: since the parent/child cards are strongly connected this way, would there be a way to completely disconnect them, and have them only see their own card settings.

Card P gets a nested card C for display purposes only, but other than that they have no relation to each other. Just use triple brackets all over and dont mind relationships.

something like nest: false on the child card would prevent the complex concept of the additional brackets?

[RomRider]

It was there for a long time already : do_not_eval: true. It still works but is considered deprecated (and doesn't work for pop-ups).

[Mariusthvdb]

proves I am not used to the subject at all...

though, if I add that option to my example card, the output is completely different, and it indeed returns the string of the template

and that is not what I meant however...

I meant a detachement, and still evaluate the template on the nested button-card while using the regular 3 pairs of brackets

like this, indeed with do_not_eval: true.
which is a bit of a silly name in this case, because it does evaluate, namely the templates on that particular card in the custom field

[dcapslock]

do_not_eval: true means for the button-card containing the custom fields not to eval templates contained in the custom field. The result you are seeing is the custom field card doing whatever it does, in this case a button-card, evaluating templates in the usual fashion following nesting rules.

I understand where you are coming from, in that a button-card in a custom field seems related to the button-card containing the custom field (note that I am steering away from parent/child as it is not that relationship). However they have no relationship except that the card in the custom field is of type button-card. The button-card containing the custom field knows nothing about its type. It just displays it and renders templates using the nesting rules.

Perhaps do_not_eval: true could get a different name ?? I am not sure. Perhaps nested_templates: true which is shorthand for not including an extra [ ]. I am not a fan of this as nested templates provides for all scenarios without creating any sort of pandoras box of config variables, whether it is true or false etc.

[Mariusthvdb]

Perhaps do_not_eval: true could get a different name ?? I am not sure. Perhaps nested_templates: true which is shorthand for not including an extra [ ]. I am not a fan of this as nested templates provides for all scenarios without creating any sort of pandoras box of config variables, whether it is true or false etc.

If you'd at all consider this (thanks btw for the ongoing efforts to get it into my blocked mind...) I dont think do_not_eval: true should be changed or used for it. As I showed above that does not do what I am looking for.

I dont need unevaluated templates, I need evaluated 'local templates' to the card in the custom field

a new nested_templates: true or the likes would however be useful imho. It would take the user to a humanely readable option, versus the computer lingo of brackets...... brackets that have complex meanings and can be confusing (no need to stress that anymore...sorry)

[RomRider]

What you call nested_templates is exactly the same as do_not_eval and won't be implemented. Local evaluation for nested cards already happens if you set do_not_eval: true.

If you don't want to use nested brackets, be it, but it is useful and will stay like that as people are using it (especially with browser_mod's pop-up)

JS template evaluation does 2 things:

• removes a bracket pair if there are more than 3 and pass down the value
• evaluates the javascript if there are 3 brackets

That's it. It doesn't know "where" it evaluates what, if it's a nested card or not or if it evaluates an action or whatever else.

[il77781]

@dcapslock, hello!
Perhaps my question is a little away from what was discussed here, but still...
Here you have suggested a way to access the variables set in the "parent" card, in the "nested" card...
In this way:

type: custom:button-card
variables:
  cond01: " [[[ return (states['switch.dmaker_p44_7a6c_air_cooler'].state == 'on') ]]] "
  cond02: " [[[ return (states['switch.dmaker_p44_7a6c_horizontal_swing'].state == 'on') ]]] "
name: "\"Parent\" card"
styles:
  grid:
    - grid-template-areas: " \"n\" \"nested1\" \"nested2\" "
    - gap: 10px
custom_fields:
  nested1:
    card:
      type: custom:button-card
      variables:
        parent_all: " [[[ return variables ]]] "
      name: "\"Nested\" card-1"
      label: " [[[[ return variables.parent_all.cond01 ]]]] "
      show_label: true
  nested2:
    card:
      type: custom:button-card
      variables:
        new_cond: " [[[ return variables.cond02 ]]] "
      name: "\"Nested\" card-2"
      label: " [[[[ return variables.new_cond ]]]] "
      show_label: true

it seems that there is no access to the values of the "parent" variables now - the label does not exist at all displayed:

The same situation occurs if a button-card is used as a "nested" one, which is called using browser_mod.popup.
Is this how it should be now?

[ngocjohn]

cond01 and cond02 return boolean. If false, the label is not displayed.

[il77781]

Oops... Everything turned out to be much simpler... My mistake, I'm sorry!
Thank you so much for the clarifications!