-
Notifications
You must be signed in to change notification settings - Fork 13.5k
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
Comments
@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 Screen.Recording.2023-04-18.at.4.50.27.PM.movNotice how the second (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:
To explain the reason this matters for us specifically, and why Sometimes there are so many logs from 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. |
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. |
Additional issues reported. 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. |
Note, after doing some 'creative thinking', I did find a very hacky workaround for this for the time-being:
The key features of this workaround are:
|
That problem is why we are doing this form control migration. Form controls have several "magical" behaviors when used inside of We plan on adding support for a |
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 :) |
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. |
Hi there, We added the Example usage: <ion-select>
<div slot="label">My Label</div>
</ion-select> |
You are a hero! |
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. |
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 likeion-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 theslot=label
slot ofion-segment
:Use
slot=label
to provide custom label elements, likeion-range
: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 useslot=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
The text was updated successfully, but these errors were encountered: