feat: Use native localized units & order "value - delimiter - unit"

[ildar170975]

Adds more features to #1233.
So, suggest to test along with #1233 merged.

Additionally - implements #1287.

---

Features:

Support of native units for attributes; example - temperatures in climate.ecobee of Demo integration:

---

Support of native presentation of "percentage" values: some locales like “German” demand a presence of a whitespace between a value & "%", some like “English” do not place a whitespace:

---

Support of native localized units dependently on a locale.
Support of native reversed order for a state/attribute value presentation dependently on a locale.
Example - monetary values:

Language: "English (GB)"
Number format: "Use system locale"

Language: "English"
Number format: "Use language settings"

---

Support of translated units; example - Github integration:
Language: “German”

---

Allow to hide a unit for extrema & average info for a compactness (#1287):

[ildar170975]

A possible improvement which can/should be done in future:
perhaps we need to define an order "value - delimiter - unit" not on every render - but once we get a meaningful state (i.e. not unknown or unavailable), may slightly increase a performance.

[jlsjonas]

Not a thorough review yet, thanks for your continued contributions & glad to see your progress!

[jlsjonas]

Could we potentially extract this from home assistant's api instead?
If not, are you sure this list is exhaustive? Would be good to refer to the (preferably HA) source to maintain over time.

[ildar170975]

Could we potentially extract this from home assistant's api instead?

I do not think there is such a "HA api" (((. We can use methods of hass object (specially exposed for external use) - but there are no exposed methods for formatting.
Recently I added methods to hass to represent parts of a state & attribute - earlier only WHOLE strings for a state & attribute were available (i.e. "value with unit", not separately). Now I am thinking to expose formatNumber() (internal frontend function) to the outer world. But meanwhile we have to manually "copy" functions from Frontend to get a similar result.

If not, are you sure this list is exhaustive? Would be good to refer to the (preferably HA) source to maintain over time.

No guarantee that this list is full. The best scenario would be using an exposed HA function - which is not available now, see above.

[jlsjonas]

Suggested change

	const { attribute } = this.config.entities[index];
	const { entityId, attribute } = this.config.entities[index];

[ildar170975]

The problem is that entities[index] does not have the entityId option.
Perhaps we can do smth like

const { entity: entityId, attribute } = this.config.entities[index];

just a speculation, since I know a little about JS.

My approach was simple: when I get a warning about a "deconstruction", I use that "const { xxx } = yyy" syntax, otherwise - use "old classic" way.

[jlsjonas]

Note that this format was originally used for performance reasons (we also run on lower-spec devices), please check the performance impact of the change(s)

[ildar170975]

Yeah, using functions like formatEntityAttributeValueToParts needs more time.
Same as for "use states['sensor.xxx'].state" vs "use formatEntityStateToParts()".
But we need to follow HA frontend number formatting settings, individual entity precision settings, translations...
My only hope is that computeState() (same for computeUom()) is only used for presentation, i.e. not being called very often.

[ildar170975]

@jlsjonas
Hi Jonas, nice to see you again). Thanks for the review, please go on)))