Allow multiple: true for expandable sections

[karwosts]

Proposed change

Allow setting multiple: true for an expandable section, which would mean that that section now behaves like a group of selectors, with user allowed to submit multiple copies of the data requested by the section.

Backend PR: home-assistant/core#131393

Based on a concept idea by Frenck: home-assistant/core#121857 (comment)

Example: entering datapoint pairs, where the user can submit a list, and each list item is two numbers:

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

[piitaya]

Should we create dedicated selector for that instead of reusing the expandable one? I already attempted something like that but without success.
I would propose a UX like we have for badges in heading card.

So we can add/edit/delete/reorder. Also, we should be able to define the title of each group (by using one of the nested field value?) because for now, we have the same title (data point) for each section.

[karwosts]

Should we create dedicated selector for that instead of reusing the expandable one?

Is the issue here that you specifically want this to be a Selector instead of a form element, or is the issue just that I've overloaded this form element with too much optional code (and to call it a different form element name/.ts file)? I'm a little puzzled how to make this into a Selector, given that it's really just an empty container for other Selectors. I'm not quite sure what change that would look like on both the backend and frontend side, but this current implementation felt kind of natural to me since it felt very similar to the concept we already invented for sections.

I would propose a UX like...

What is the intention of the pencil button, we are already in a options dialog here, does that open a new popup dialog over the existing popup dialog? I kind of liked having everything viewable at once, but that's just my personal opinion.

So we can ...reorder

I guess reorder handles could be added to any UI, not sure if that is needed in this iteration though?

Also, we should be able to define the title of each group (by using one of the nested field value?)

I guess if we had a child selector with the magic name title we could inherit that is the section title. I'm not sure if there are use cases yet for this though. If we just have arrays of data I'm not sure why each array element would need a different name. The current concept use case for this was for entering pairs of unnamed decimal pairs for compensation. I would be curious about what other use cases could come up in the future.

[marcinbauer85]

@karwosts we're reviewing solutions. I'll get back to you at the start of the next week.

[marcinbauer85]

@karwosts Sharing you the design. We opted for a list-item style component that resembles the current .
The design has also examples (cases 1 & 2) where there are similar elements in the code, but they are still not a component.

https://www.figma.com/design/aJJlYSKScPmTzaLDzsM37I/HA-19?node-id=0-1&t=xvuj9WWvCQfdJTIX-1
CC: @piitaya