feature request
Option lists can have slide toggles instead of checkboxes, as you can see on Android OS.
Option lists are only for checkboxes and if you want to create something that has the same look but has a slide toggle instead, you will have to implement by yourself.
Its a very common option list format, very used on Android 5~6.
Material 5.1
You can find it in Material's guidelines:

(switches are very cute btw)
Cute sidebar example:

(inspired by Twitter's PWA, achieved with slide-toggle, mat-list and ::ng-deep, that's a lot more than I expect to write)
I agree. That would be really nice to have.
We need to see how we can developers let decide which element to pick (_checkbox, slide-toggle_)
As long as switches are most used for options, what about create a mat-options-list that uses slide toggles by default and leave mat-selection-list as is?
cc. @jelbourn
This would be actually pretty easy to implement. We could have something like a [indicatorType] input binding that allows deciding which indicator to use (e.g. checkbox, slide-toggle).
It just feels a bit unfortunate, that we would need to have a dependency on the MatSlideToggleModule. We could fix that by either letting the user project the indicator manually, or by having a separate module for the selection list.
The list-option currently uses a pseudo-checkbox in order to avoid the cost of a full checkbox (since they are SVG-based), and because they _shouldn't_ be real checkboxes for a11y. We may want to do something similar for slide-toggle.
Yeah I noticed that while playing with that issue. Although, I think having something like a pseudo slide-toggle kind of might be difficult. Especially with the dragging functionality.
Letting the user project the indicator component itself, feels like the best solution, but unfortunately will involve so much boilerplate.
<mat-list-option>
<mat-slide-toggle matOptionIndicator></mat-slide-toggle>
</mat-list-option>
I noticed that the mat-list-..'s checkbox has a little different visual behavior than the checkbox component itself, should it be that way?
@DevVersion I noticed that as developers in Angular Material we can't customize as much as we can in Bootstrap, because you always try to make things as simpler as possible. That's good and that's bad too. I already had difficults with other components because of that. I don't know what you wanna do at this point, but you could build the components in layers, exposing the base and the abstracted version, so devs can mix components. I know that this could allow some people to mess things up, bug it's worse when we do that mess in SCSS with shadow piercing. Another advantage of letting devs customize things is that some of new (and not already implemented) components in Material would be covered up with some component mixin. It's a hard decision btw.
For now, I think that the easiest to stay in the project standards/guidelines, would be create a new component called mat-option-list which would have a different purpose than mat-selection-list and could share the same logic behind the hood (could have a lower level component, where Material team would create the boilerplate).
Just some ideas, thanks for taking this issue forward. 馃槉
In our app we had the lists with the slide toggle, but because it is not possible now, we had to change them to the checkboxes. and that's really not good, because our users were used to something else....馃槬
any updates on if this will be implemented?
I need the same thing but for star icon and star_bordred icon
Most helpful comment
cc. @jelbourn
This would be actually pretty easy to implement. We could have something like a
[indicatorType]input binding that allows deciding which indicator to use (e.g.checkbox,slide-toggle).It just feels a bit unfortunate, that we would need to have a dependency on the
MatSlideToggleModule. We could fix that by either letting the user project the indicator manually, or by having a separate module for the selection list.