feat: add show_legend_state

[JulienDeveaux]

Iterating on #1082 as I can't push into his repo

[JulienDeveaux]

In the previous PR, it was advised to add state__value & state__uom classes to the render.
It messes the visual as they are way too big for this small label, so I removed them

[ildar170975]

so I removed them

totally agree, missed that myself.

[ildar170975]

@akloeckner
Please have a look at this PR.
Cleaned up the changes together a bit.
I am not having enough experience to approve all changes.
For me it is looking OK.

What is not covered (and MAY BE will be fixed in other PRs):

1. Custom order "state uom" / "uom state". Currently it is fixed as "state uom" for a legend entry.
   Note that for a "state" label a value & uom are kept in separate DOM elements - so an order can be changed by card-mod as it was explained here.
   But in this PR a legend is presented as

legend += ` (${this.computeState(state)} ${this.computeUom(index)})`;

without keeping parts in separate elements. May be they should be placed both in <span> instead to allow users to use card-mod here.

2. There are rules in HA frontend regarding a whitespace between a value & uom. A special function is used for it. No idea if it can be used in custom cards or it should be repeated. Personally me do not care about whitespaces))).

[akloeckner]

Thanks for sorting most things out already! And sorry for re-opening some of the topics. :-)

I agree with your general assessment:

• Let's keep the UOM order for later. I also understand from your conversation that the usual classes generated a strange look. So, it is more than just adding known classes and spans and should thus be treated with more thought in another PR.
• Same for the whitespace. If the state and UOM parts become separate tags with flexible order, it will be up to the user anyways to add or remove whitespace.

I haven't actually downloaded, compiled and tested the changes yet. I'll approve the workflow run, so maybe you can check it out, @ildar170975? You'll have to wait for the code to successfully compile...

[akloeckner]

Personally, I liked the destructuring syntax for retrieving the show_legend_state option. This syntax also seems to be usually used in the existing codebase, whenever some property of this.config is simply assigned to a shortcut. So, I suggest to either revert to this syntax or directly go:

if(this.config.entities[index].show_legend_state)

There is also a way to assign a default value, if the property is not set:

const { show_legend_state = false } = this.config.entities[index];

(Also, we do not support ?? in the babel configuration yet, see the linting error.)

[JulienDeveaux]

I've rolled back to the deconstructor + default value

[ildar170975]

We have already discussed this earlier:
the show_legend_state is an option inside config.entities.
What is a purpose of assigning a bool value to an OBJECT?
Why not assigning it to this.config.entities[index].show_legend_state instead?

[JulienDeveaux]

See @akloeckner review that I have unresolved.
Personally, both are fine for me.

[ildar170975]

Yes, I have seen it, please @akloeckner take a look at my remark (I am not as fluent in JS).