Collapsible blueprint input sections

[karwosts]

Proposed change

Frontend for home-assistant/core#110513

Add an optional section to blueprint definition called input_sections, and allow inputs to optionally attach themselves to a particular section. This information can then be used by the UI to visually group certain sets of inputs.

Authors of large blueprints sometimes claim that the current big flat list of all inputs becomes difficult to organize and can overwhelm users visually with number of options, and would like a way to organize them better. With collapsable sections, various related inputs can be visually grouped and collapsed to improve organization.

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

blueprint:
  name: Confirmable Notification with Sections
  description: >-
    A script that sends an actionable notification with a confirmation before
    running the specified action.
  domain: script
  source_url: https://github.com/home-assistant/core/blob/master/homeassistant/components/script/blueprints/confirmable_notification.yaml

  input:
    description_section:
      name: Information
      description: |
         This is a section with no inputs. It might seem useless, but it could be used to for a collapsible general information box.
         - Foo
         - Bar
         - Foobar
         - *Markdown*
      input: {}
    device_section:
      description: This is not collapsible as it does not have a default.
      icon: mdi:cellphone-message
      input:
        notify_device:
          name: Device to notify
          description: Device needs to run the official Home Assistant app to receive notifications.
          selector:
            device:
              integration: mobile_app
    body_section:
      description: Title and Message
      input:
        title:
          name: "Title"
          description: "The title of the button shown in the notification."
          default: "Alert"
          selector:
            text:
        message:
          name: "Message"
          description: "The message body"
          default: "Something happened."
          selector:
            text:
    confirm_text:
      name: "Confirmation Text"
      description: "Text to show on the confirmation button"
      default: "Confirm"
      selector:
        text:
    confirm_action:
      name: "Confirmation Action"
      description: "Action to run when notification is confirmed"
      default: []
      selector:
        action:
    dismiss_section:
      name: "Dismiss Options"
      icon: mdi:close-circle
      collapsed: true
      input:
        dismiss_text:
          name: "Dismiss Text"
          description: "Text to show on the dismiss button"
          default: "Dismiss"
          selector:
            text:
        dismiss_action:
          name: "Dismiss Action"
          description: "Action to run when notification is dismissed"
          default: []
          selector:
            action:

    minimal_section:
      input:
        minimal_input:

mode: restart

sequence:
  - alias: "Set up variables"
    variables:
      action_confirm: "{{ 'CONFIRM_' ~ context.id }}"
      action_dismiss: "{{ 'DISMISS_' ~ context.id }}"
  - alias: "Send notification"
    domain: mobile_app
    type: notify
    device_id: !input notify_device
    title: !input title
    message: !input message
    data:
      actions:
        - action: "{{ action_confirm }}"
          title: !input confirm_text
        - action: "{{ action_dismiss }}"
          title: !input dismiss_text
  - alias: "Awaiting response"
    wait_for_trigger:
      - platform: event
        event_type: mobile_app_notification_action
        event_data:
          action: "{{ action_confirm }}"
      - platform: event
        event_type: mobile_app_notification_action
        event_data:
          action: "{{ action_dismiss }}"
  - choose:
      - conditions: "{{ wait.trigger.event.data.action == action_confirm }}"
        sequence: !input confirm_action
      - conditions: "{{ wait.trigger.event.data.action == action_dismiss }}"
        sequence: !input dismiss_action

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]

emontnemery suggested that sections which have required inputs should not be collapsible, so in order to keep the same visual styling and same slots for all sections I modified the expansion-panel to support a mode where it is not interactive, thinking that is simpler than trying to recreate the styling using a diffrent class.

Or maybe we could have all sections be collapsible, but just automatically expand them on submit failure if they had a missing input, that's another possibility.

[SirGoodenough]

Or maybe we could have all sections be collapsible, but just automatically expand them on submit failure if they had a missing input, that's another possibility.

I like this option better. Less confusing to user as the problem pops right up for them to see.

[bramkragten]

Should we use an expansion panel if it can not be collapsed anyway? Shouldn't we just use a ha-card in that case?

[karwosts]

Initially when I wrote this they were all collapsible, so the removal of collapsing was a last minute add on.

I think I was concerned that the CSS styling might not look the same if some sections were expPanels and some were ha-cards. Just looking at it it seems like the font-size for the headers might be different, and possibly other paddings and margins as well. It could maybe be fixed but I'm not convinced the styling wouldn't further diverge in the future.

Keeping the same class I think guarantees that collapsible/noncollapsible sections always have a similar look and feel.