Open pburkindine opened 5 years ago
angular-robot[bot]
commented
2 years ago Just a heads up that we kicked off a community voting process for your feature request. There are 20 days until the voting process ends.
Find more details about Angular's feature request process in our documentation.
angular-robot[bot]
commented
2 years ago Thank you for submitting your feature request! Looks like during the polling process it didn't collect a sufficient number of votes to move to the next stage.
We want to keep Angular rich and ergonomic and at the same time be mindful about its scope and learning journey. If you think your request could live outside Angular's scope, we'd encourage you to collaborate with the community on publishing it as an open source package.
You can find more details about the feature request process in our documentation.
Please describe the feature you would like to request.
Currently working with the autocompleter (or select) and using different templates which define and bubble up mat-optgroups is a challenging and manual process requiring understanding of the inner workings of the components and direct access of private fields.
https://stackblitz.com/edit/dynamic-autocomplete
In addition, when there are no "real" top-level options, a shim disabled option must be inserted and then disguised (or else very undesirable workarounds that don't work well with ngrx state-driven option lists must be undertaken). Otherwise, the autocomplete will not open, and reindexing of select handlers for the dynamic options will fail, so that the list either does not appear initially or cannot be navigated/selected from.
As this is a common use case for autocompleters with behavior driven by another selection (e.g.), and we do not want to access internals, we would like to propose a "reboot" method on the autocomplete (and select) whereby a group of MatOptions can be provided and Material will handle getting things into the correct state.
e.g.
What is the use-case or motivation for this proposal?
We have encountered multiple scenarios that were best handled by choosing between multiple optgroup-producing templates. For instance, another select may cause the user to choose a "Type" which then should drive our autocomplete to choose between a very complicated and a very simple template.
Currently, realizing this behavior (without putting all of it in one god controller) is unsafe as we must access class internals, and requires specific and fragile knowledge and patterns.