feat: support `slot=label` syntax on v7+ `ion-select` component (like `ion-range`)

[lincolnthree]

Prerequisites

• I have read the Contributing Guidelines.
• I agree to follow the Code of Conduct.
• I have searched for existing issues that already include this feature request, without success.

Describe the Feature Request

Currently, it is not possible to provide customized labels to ion-select, rather, only the [label]="my label" attribute is supported. ion-select should be updated to support complex labels - bringing it in line with other components like ion-toggle.

Describe the Use Case

The new form syntax doesn't allow customization of ion-select labels. Making something like this impossible without using legacy <ion-label> code. We need the ability to add custom HTML / components to our labels. Plain text is not enough for our use cases:

Describe Preferred Solution

Pass through non-ion-select-option elements directly to the slot=label slot of ion-segment:

Use slot=label to provide custom label elements, like ion-range:

  <ion-select placeholder="Choose one">
    <div slot=label>View mode</div>
    <ion-note slot=label>Choose how decks are presented visually when viewing or editing.</ion-note>

    <ion-select-option value=foo>foo</ion-select-option>
  </ion-select>

Additionally, I'd propose that ALL input components be updated to support slot=label as appropriate. It's an extra tripping point for developers to have to remember which of these components use slot=label and which accept label elements directly as children.

Passing elements as children and having them show up in label slot without requiring the slot=label attribute might also create additional migration scenarios in the future, should components start to use the Shadow DOM, or be re-worked to use slots in the future.

If everything required slot=label today, I think it would be more consistent for developers and more future-proof across the board.

Describe Alternatives

No response

Related Code

No response

Additional Information

No response

[lincolnthree]

@liamdebeasi So, this saga continues.

I've made another attempt to move to the "modern" form syntax, and as far as I can tell, this is the remaining blocker for our migration, and things are even weirder than I originally thought. Am I doing something incorrect, here?

When we try to use aria-label, the connection between the select component and the ion-input is broken until the select input itself is clicked (I assume due to something in the new form syntax), and we get the following issue (see video below). We can't use aria-labelledby because this component uses the shadow dom.

Screen.Recording.2023-04-18.at.4.50.27.PM.mov

Notice how the second ion-select does not respond to clicks on the parent/containing item, like the top one does using legacy form syntax -- until the actual control itself is clicked. Also note that the ion-toggle does respond to clicks, but does not get the same visual/ripple effect:

(Happy to file issues for these if they are separate/new & should be reported.)

Code for the 'Group cards by' input that didn't respond to clicks:

            <ion-item>

              <ion-label class=ion-text-wrap>
                Group cards by
                <p class=sublabel>
                  Choose how cards in decks are grouped.
                </p>
              </ion-label>

              <ion-select
                [value]="groupByMode" placeholder="Group by" aria-label="Group by" 
                [interfaceOptions]="{ header: 'Group cards by', subHeader: 'Select how cards are grouped together.' }">
                <ion-select-option *ngFor="let mode of groupByModes" [value]="mode">
                  {{ mode }}
                </ion-select-option>
              </ion-select>

            </ion-item>

To explain the reason this matters for us specifically, and why [legacy]=true is not ideal, is because our console logs are being filled up with Ionic Warnings about deprecated syntax and it's frequently cluttering up debugging sessions.

Sometimes there are so many logs from ion-select, even if we do use the [legacy]=true flag, which still logs a warning, that it's difficult to see real log information as it happens.

Additionally, once the legacy syntax is removed, we will have no functional equivalent feature. If any of this is an issue you'd like me to file/report separately, please let me know. Thanks.

[liamdebeasi]

So for the logs, you can filter those out. In the "Console" tab of Chrome dev tools make sure "Warnings" is unchecked:

You can also keep "Warnings" enabled but only filter out the Ionic warnings by adding -Ionic to the filter text box:

---

Can you file a separate issue with a reproduction app we can clone? I'd like to keep this thread focused on the ion-select feature request.

[lincolnthree]

Agreed. Will file a new issue for the other topics. THanks.

Those suggestions work for Chrome debugging, but not things like "Sentry.io" that record the whole context around production issues. It would be nice if we could disable these in production. I'll file an issue/feature request for that, too.

[lincolnthree]

Additional issues reported.

#27231
#27232

Fundamentally I think the root issue I'm having is that the ion-item interaction with form components is feeling far too "magical". And all of these other issues are coming up as a result of not having as much control over this anymore.

This feature would resolve most of our issues, but I can easily imagine a world where someone wants to do something else that doesn't quite work because of this modern form layout interaction with ion-item.

[lincolnthree]

Note, after doing some 'creative thinking', I did find a very hacky workaround for this for the time-being:

     <ion-item *ngIf="groupByModes$ | push as groupByModes">

              <ion-label (click)="groupByMode.open()" class=ion-text-wrap>
                Group cards by
                <p class=sublabel>
                  Choose how cards in decks are grouped.
                </p>
              </ion-label>

              <ion-select #groupByMode slot="end" (ionChange)="setGroupByMode($event.detail.value)"
                [value]="groupByMode$ | push" placeholder="Group by" aria-label="Group by">

                <ion-select-option *ngFor="let mode of groupByModes" [value]="mode">
                  {{mode | uppercase}}
                </ion-select-option>
              </ion-select>
            </ion-item>

The key features of this workaround are:

1. Putting the select component in the 'end' slot of the 'ion-item'.
2. Manually calling selectComponent.open() via a (click) event on ion-item, using a component reference.

[liamdebeasi]

Fundamentally I think the root issue I'm having is that the ion-item interaction with form components is feeling far too "magical".

That problem is why we are doing this form control migration. Form controls have several "magical" behaviors when used inside of ion-item that caused a myriad of issues in the past.

We plan on adding support for a label slot to ion-select in an upcoming minor release.

[lincolnthree]

Fundamentally I think the root issue I'm having is that the ion-item interaction with form components is feeling far too "magical".

That problem is why we are doing this form control migration. Form controls have several "magical" behaviors when used inside of ion-item that caused a myriad of issues in the past.

We plan on adding support for a label slot to ion-select in an upcoming minor release.

That makes sense. I guess I've rarely used these controls inside traditional forms. So I'm less familiar with those issues. Either way, thanks for considering all of this and hearing my perspective, and I hope it's more helpful than annoying :)

[liamdebeasi]

It's very helpful and not at all annoying 😄 . As I mentioned in our other thread (#27232 (comment)), we haven't done a great job of providing guidance on how to properly use items in lists. Combine that with the fact that up until Ionic 7 form controls had to be used in an item, and now working with the impacted components gets pretty confusing.