You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Unfortunately, supporting this feature in Blazor requires some research to land on the proper pattern to promote. Because of the reliance of requiring a client to handle an event while the Select component is in a non-default interactive state (displaying a dropdown), the default Blazor behavior will be to recreate the Select component when the user types something in the filter input of the dropdown, causing the dropdown to disappear. This means that in order to properly implement dynamic options with the Select we will require the client to implement a pattern that will avoid the default Blazor behavior or re-rendering the entire component that handles the event.
Microsoft outlines ways to avoid this in their docs. We should converge on the way we want to guide clients to handle this scenario, and as part of this work, update our guidance docs accordingly.
💁 Proposed Solution
I suspect we will likely push clients towards implementing the IHandleEvent interface, as it is a fairly light-weight solution. This obviously needs to be explored.
📋 Tasks
The text was updated successfully, but these errors were encountered:
🙋 Feature Request
We need to support dynamic options in Blazor for Select (see 'Filterable Select should support dynamic options').
😯 Problem to Solve
Unfortunately, supporting this feature in Blazor requires some research to land on the proper pattern to promote. Because of the reliance of requiring a client to handle an event while the
Select
component is in a non-default interactive state (displaying a dropdown), the default Blazor behavior will be to recreate theSelect
component when the user types something in the filter input of the dropdown, causing the dropdown to disappear. This means that in order to properly implement dynamic options with theSelect
we will require the client to implement a pattern that will avoid the default Blazor behavior or re-rendering the entire component that handles the event.Microsoft outlines ways to avoid this in their docs. We should converge on the way we want to guide clients to handle this scenario, and as part of this work, update our guidance docs accordingly.
💁 Proposed Solution
I suspect we will likely push clients towards implementing the
IHandleEvent
interface, as it is a fairly light-weight solution. This obviously needs to be explored.📋 Tasks
The text was updated successfully, but these errors were encountered: