unexpected behavior with mat-option select() #9314
Assignees
Labels
P3
An issue that is relevant to core functions, but does not impede progress. Important, but not urgent
Comments
|
A workaround for this issue is to just set the formControl value, but it still seems like a bug, and it's a bit disappointing that no one even bothered to comment on this in over 3 months. |
crisbeto
added
P3
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
May 26, 2018
…e options Reworks the way `MatSelect` handles syncing its selected state between its child options and the `SelectionModel`, making it easier to follow and generally more robust. Previously we kept syncing the selected state in parallel between the options themselves and the selection model, which meant that we had to prevent infinite loops by ignoring any non-user changes to the options' `selected` state. This made the `MatOption.select` and `MatOption.deselect` methods useless to consumers and was very error prone. The new approach makes the `select` and `deselect` methods usable and allows us to turn the `MatOption.selected` property into an input, getting it closer to the native `option` API. These changes also address the following issues that I bumped into along the way: * The `MatOption.onSelectionChange` was emitting even if the selection hadn't changed. * The `SelectionModel.sort` wasn't sorting its values if the consumer hadn't attempted to access the `selected` value since the last time it changed. Fixes angular#9314.
crisbeto
added a commit
to crisbeto/material2
that referenced
this issue
May 27, 2018
…e options Reworks the way `MatSelect` handles syncing its selected state between its child options and the `SelectionModel`, making it easier to follow and generally more robust. Previously we kept syncing the selected state in parallel between the options themselves and the selection model, which meant that we had to prevent infinite loops by ignoring any non-user changes to the options' `selected` state. This made the `MatOption.select` and `MatOption.deselect` methods useless to consumers and was very error prone. The new approach makes the `select` and `deselect` methods usable and allows us to turn the `MatOption.selected` property into an input, getting it closer to the native `option` API. These changes also address the following issues that I bumped into along the way: * The `MatOption.onSelectionChange` was emitting even if the selection hadn't changed. * The `SelectionModel.sort` wasn't sorting its values if the consumer hadn't attempted to access the `selected` value since the last time it changed. Fixes angular#9314.
jelbourn
pushed a commit
that referenced
this issue
Jun 12, 2018
…e options (#11528) Reworks the way `MatSelect` handles syncing its selected state between its child options and the `SelectionModel`, making it easier to follow and generally more robust. Previously we kept syncing the selected state in parallel between the options themselves and the selection model, which meant that we had to prevent infinite loops by ignoring any non-user changes to the options' `selected` state. This made the `MatOption.select` and `MatOption.deselect` methods useless to consumers and was very error prone. The new approach makes the `select` and `deselect` methods usable and allows us to turn the `MatOption.selected` property into an input, getting it closer to the native `option` API. These changes also address the following issues that I bumped into along the way: * The `MatOption.onSelectionChange` was emitting even if the selection hadn't changed. * The `SelectionModel.sort` wasn't sorting its values if the consumer hadn't attempted to access the `selected` value since the last time it changed. Fixes #9314.
victoriaaa234
pushed a commit
that referenced
this issue
Jul 25, 2018
…e options (#11528) Reworks the way `MatSelect` handles syncing its selected state between its child options and the `SelectionModel`, making it easier to follow and generally more robust. Previously we kept syncing the selected state in parallel between the options themselves and the selection model, which meant that we had to prevent infinite loops by ignoring any non-user changes to the options' `selected` state. This made the `MatOption.select` and `MatOption.deselect` methods useless to consumers and was very error prone. The new approach makes the `select` and `deselect` methods usable and allows us to turn the `MatOption.selected` property into an input, getting it closer to the native `option` API. These changes also address the following issues that I bumped into along the way: * The `MatOption.onSelectionChange` was emitting even if the selection hadn't changed. * The `SelectionModel.sort` wasn't sorting its values if the consumer hadn't attempted to access the `selected` value since the last time it changed. Fixes #9314.
|
This issue has been automatically locked due to inactivity. Read more about our automatic conversation locking policy. This action has been performed automatically by a bot. |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Bug, feature request, or proposal:
Bug
What is the expected behavior?
When manually calling select()/deselect() on a MatOption, I would expect the following to happen:
What is the current behavior?
Currently, only the option checkbox changes in the dom. The 3 things listed above do not happen.
What are the steps to reproduce?
http://plnkr.co/edit/kwmjilcrI5Yhf7hLUnKJ?p=preview
What is the use-case or motivation for changing an existing behavior?
It would be nice to be able to programmatically select/deselect options - for example, buttons to "Select All" or "Select None".
Which versions of Angular, Material, OS, TypeScript, browsers are affected?
Tested with Angular Material version: 5.0.4-303e004
Is there anything else we should know?
I would be willing to try and create a pull request, but wanted to first confirm that this is actually considered a bug.
The text was updated successfully, but these errors were encountered: