Feat: combo box badge (alt)

[jfmcquade]

PR Checklist

• PR title descriptive (can be used in release notes)
• Builds on Chore/combo box dropdown refactor #3411 (merge that PR first)

Description

Adds support for "badges" on options of a combo-box. This is achieved through new params on the combo-box:

• options_meta_badge_text
  • The name of a property key on each answer option (e.g. a column of the corresponding data list). If a given option has a value for this key, a badge will display for that option using the value as text to display
• options_meta_badge_color
  • The name of a property key on each answer option (e.g. a column of the corresponding data list), to change the colour of the badge for that option. Default is "primary". Currently limited to the colour options exposed by ionic, but should be expanded in a follow-up to support our theme colours generally.

This params suggest an extendible syntax for future use. For example, if we wanted to support an icon instead of (or as well as) a badge, we could add a new options_meta_icon param.

Git Issues

Closes #3400
Closes #3406
Closes #3404

Screenshots/Videos

comp_combo_box

modal (default) variant	dropdown variant	dropdown variant with search

[jfmcquade]

/gemini review

[gemini-code-assist]

Code Review

This pull request refactors the ComboBoxComponent by extracting dropdown logic into a dedicated ComboBoxDropdownComponent and introduces a meta-badge feature to display status or category chips alongside option labels across all variants. The review feedback highlights opportunities to improve code maintainability by replacing magic numbers with constants, simplifying computed logic, and ensuring consistent adoption of signal-based inputs as required by the repository style guide. Additionally, a suggestion was made to reduce boilerplate by exposing utility functions directly to the templates.

[chrismclarke]

Just putting a block on this until after #3411 merged in. Please re-request when updated for easier review

It sounds like this would most likely be a more preferable solution than previous, although it does still feel like the combo_box is possibly getting extended in a way that could lead to more bloat in the future as people want different styled badges or other start/end content, but I'll wait to see the full implementation update once related pr is merged.

The other direction we could consider going in would be passing child content to render as the item template, although then we would also need to ensure that the list items are correctly rendered from the answer_list param.

Rough authoring would be along the lines of

begin_combo_box
begin_display_group
text	here is some text - @item.text
image	@item.image
end_display_group
end_combo_box

This type of pattern could be used to create any generic item layout... but appreciate it might be more complicated to implement if we really need the badges asap

[jfmcquade]

Thanks @chrismclarke

Just putting a block on this until after #3411 merged in. Please re-request when updated for easier review

I've temporarily targeted that branch in this PR to aid code review, as we're pushed for time and I'd like this to be available to authoring tomorrow before the Easter weekend (although it wouldn't be so bad to temporarily target this branch from the relevant deployment).

It sounds like this would most likely be a more preferable solution than previous, although it does still feel like the combo_box is possibly getting extended in a way that could lead to more bloat in the future as people want different styled badges or other start/end content, but I'll wait to see the full implementation update once related pr is merged.

The other direction we could consider going in would be passing child content to render as the item template, although then we would also need to ensure that the list items are correctly rendered from the answer_list param.

Rough authoring would be along the lines of

begin_combo_box
begin_display_group
text here is some text - @item.text
image @item.image
end_display_group
end_combo_box
This type of pattern could be used to create any generic item layout... but appreciate it might be more complicated to implement if we really need the badges asap

I think what you're suggesting does make sense, and would be a nicer long-term solution. I think there is a bit more complexity to capture, since we'd almost certainly want to loop over a data list to render the options, and we would need to determine the meta properties for each option based on data from the data list row itself. Additionally, we'd need a way for each iteration to pass its "ID" and "value" (aka "name"/"label" etc.) to the parent combo-box component for the purposes of the select functionality. There is currently a workaround for handling the case of the options being authored as a data-items loop inside the combo-box component, which we'd want to still support.

So I think it would call for a new subcomponent, combo_box_option (this would handle displaying the content in a row and passing the values from each option to the parent component). I've sketched out a draft of how that might be authored here: debug_combo_box_options:

type	name	value	parameter_list	condition
begin_combo_box
begin_data_items
begin_combo_box_option			key: @item.id; value: @item.text;
text		@item.text
badge		@item.badge_text	color: @item.badge_colour	!!@item.badge_text
end_combo_box_option
end_data_items
end_combo_box

I've also suggested the existence of a new badge component, which could be a wrapper around ion-chip. That's not easy to include in the current implementation in this PR, since custom components don't straightforwardly support the slot attribute for positioning them within their ion element parent, like ion-chip does.

I think that something like this could be a nicer long term solution that would offer a lot of flexibility for how combo-box options are authored. However, we need a solution for this particular use case ASAP, and I think trying to implement this (including supporting all variants of the component) would take more time than we have. So I would suggest we move forward with some version of the current implementation, and see this all as a follow-up. I think that for now, displaying a badge in a single colour is the only use-case, and whilst that is obviously likely to change down the line, I think this authoring pattern is likely to remain constrained to a single instance on a single deployment for the time being, so updating it if we introduce breaking changes in the near future shouldn't be too difficult.

[chrismclarke]

Thanks for the updates. I tried to take a quick look at how easy it would be to refactor to either use child rendered components or reduce code duplication by tidying up how params are passed but it's still all a bit of a mess given how some of these are and aren't template components, and confusing naming of things like optionValue which actually refers to a lookup key.

So for now I guess makes most sense to just proceed as-is, accept things are a little untidy and likely plan follow-up work on a new base component (recomment just calling select to match the ionic naming convention) which could be authored in a cleaner way. For that component I would recommend

1. Consider way of authoring the child item component directly
2. Ensure the same option child is rendered across all interfaces (modal, popup etc.)