Automations & Scripts tables: show descriptions

[ildar170975]

Breaking change

Proposed change

Initial discussion:
#28561 (comment)

Results:

Note that descriptions containing a markdown are "simplified" - the initial markdown like

is converted to

Tested with 100 automations stored in 10 yaml files, 100 scripts stored in 10 yaml files, seems to work rather fast.

WARNING: if a description is changed in a background (for example, if it was changed either in another browser tab or was edited in yaml file), this change will not be visible on a page until a re-render of the page.

This is my 1st experience with adding a new dependency into HA, so please tell me if I am wrong.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New feature (thank you!)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Example configuration

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue or discussion:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• There is no commented out code in this PR.
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

[karwosts]

I'll note that descriptions can be markdown, so rendering that inside of a plain text label might look pretty wrong without using a markdown renderer in some cases.

[ildar170975]

Will think about it, thanks for the remark.

[MindFreeze]

This is an extremely weird pattern. It should be an async function that returns data instead of modifying descriptions directly. The descriptions.push also won't trigger a render.

[ildar170975]

The idea was to prepare a list of descriptions and then use it. I believed that acquiring a description takes some time - so wanted to get all descriptions right after a view is created - to have them ready by a moment of 1st render() call.
In reality, these descriptions are not ready yet by the 1st render() call - but they are ready by the 2nd call (do not recall exactly a difference between these two calls). So, I accepted the fact that anyway descriptions are acquired.
But I understand that I have not provided 100% guarantee that all descriptions will be ready by that 2nd render() call moment.
Also, these descriptions are acquired only once. To update them, you need to update a page (F5). Also, descriptions are updated for a NEW added entry (automation or script). Compare to memoize(): if anything is changed in states object or in registry, the memoized property is updated - and causes a new render() call. But descriptions are not a part of a states object or registry. So, I could not to monitor these descriptions asynchronously and then render() when needed. Finally, I decided that this is a rare case and it is not critical to track descriptions.

Sorry for probably being dumb, have a very little experience with async stuff in JS.

[MindFreeze]

This would fire a websocket request for each automation. Don't know if core supports it but we should batch this or just add the data in the original fetch.

[ildar170975]

Is there a list of possible requests somewhere?

[MindFreeze]

any shouldn't be needed here

[marcinbauer85]

@ildar170975 I get the idea, but a description most likely will be a long string or even markdown text, which is just not possible to display in a good way in a table. Tables are good at displaying small bits of data, for more I'd stay with showing it in the detailed view of an automation or anything other for that matter. This gets even more impossible to display on mobile.

[ildar170975]

@marcinbauer85
I see your point. In my examples above we can see a brief beginning of a description which in many cases might be enough to get a purpose of an automation/script. Even in case of a Markdown, we will be able to see at least a title.
A bit later I will post a screenshot for a mobile.

Update:
Check some more examples w/o a Markdown:

Desktop PC (1920x1200):

iPhone 15 (393x852) - descriptions are nicely displayed:

Some iPad (1024x768):

Next, an example with Markdown:

# Run Speedtest and check speeds

## Description

Run Speedtest. Then compare values of speeds with expected values.
If a value is less than an expected one - send a notification

## Required helpers

* input_number.download_minimal
* input_number.upload_minimal

I agree that additional words like "Description" here are useless.
But I think that:

1. Majority of users have descriptions as a plain text, not Markdown.
2. In case of Markdown, a user may "tune up" a complex description (containing a table of content etc) with a nice preamble to get a nice look in a table view.
3. Finally, we may provide a separate switch like "Show descriptions" in a separate PR.