Skip to content

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

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
3 tasks done
lincolnthree opened this issue Feb 21, 2023 · 11 comments
Closed
3 tasks done
Labels
package: core @ionic/core package type: feature request a new feature, enhancement, or improvement

Comments

@lincolnthree
Copy link

Prerequisites

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:

image

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

@ionitron-bot ionitron-bot bot added the triage label Feb 21, 2023
@liamdebeasi liamdebeasi added type: feature request a new feature, enhancement, or improvement package: core @ionic/core package labels Feb 21, 2023
@ionitron-bot ionitron-bot bot removed the triage label Feb 21, 2023
@lincolnthree
Copy link
Author

lincolnthree commented Apr 18, 2023

@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
Copy link
Contributor

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

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

image


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
Copy link
Author

lincolnthree commented Apr 18, 2023

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
Copy link
Author

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
Copy link
Author

lincolnthree commented Apr 18, 2023

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
Copy link
Contributor

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
Copy link
Author

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
Copy link
Contributor

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.

liamdebeasi added a commit that referenced this issue May 25, 2023
@liamdebeasi
Copy link
Contributor

Hi there,

We added the label slot for ion-select in #27545. This feature will be available in the next minor release of Ionic Framework.

Example usage:

<ion-select>
  <div slot="label">My Label</div>
</ion-select>

@lincolnthree
Copy link
Author

You are a hero!

@ionitron-bot
Copy link

ionitron-bot bot commented Jun 29, 2023

Thanks for the issue! This issue is being locked to prevent comments that are not relevant to the original issue. If this is still an issue with the latest version of Ionic, please create a new issue and ensure the template is fully filled out.

@ionitron-bot ionitron-bot bot locked and limited conversation to collaborators Jun 29, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
package: core @ionic/core package type: feature request a new feature, enhancement, or improvement
Projects
None yet
Development

No branches or pull requests

2 participants