Generate resource type filters from data #1221
Conversation
Note that currently that data is hard coded, but the new upcoming API work will allow the server to tell the client what types to expect.
| internal static class StringComparers | ||
| { | ||
| public static StringComparer ResourceType => StringComparer.Ordinal; | ||
| } |
There was a problem hiding this comment.
This is a convention I've seen used in a few places, giving semantic names to different domains of strings, ensuring they're compared in a uniform way.
| <FluentCheckbox @bind-Value="_areProjectsVisible" Label="Projects" @bind-Value:after="HandleTypeFilterTypeChanged" /> | ||
| <FluentCheckbox @bind-Value="_areContainersVisible" Label="Containers" @bind-Value:after="HandleTypeFilterTypeChanged" /> | ||
| <FluentCheckbox @bind-Value="_areExecutablesVisible" Label="Executables" @bind-Value:after="HandleTypeFilterTypeChanged" /> | ||
| <FluentCheckbox |
There was a problem hiding this comment.
Looks like you got rid of the indeterminate (i.e. "some are checked some are not") state? Was that an intentional change?
There was a problem hiding this comment.
I had the impression it wasn't actually showing intederminate state in the previous code because of ShowIndeterminate="false", but maybe that's just clearing indeterminate state if present.
I will reinstate the indeterminate state.
There was a problem hiding this comment.
Yeah, the naming is a little confusing. ShowIndeterminate actually controls whether the user can toggle between on/off and indeterminate with mouse clicks. We don't want that, so it's false. ThreeState parameter controls whether the component will even display the three states in any situation (including programmatic, which we use), so that one was true.
You can see some docs and examples here if it helps: https://www.fluentui-blazor.net/Checkbox#fluentcheckbox-class_properties
There was a problem hiding this comment.
To clarify the existing behavior:
The "All" checkbox would automatically toggle to checked (if all other checkboxes were checked), unchecked (if no other checkboxes were checked) or indeterminate (any other combination of checks).
The user clicking it wouldn't ever toggle it to indeterminate, just between checked/unchecked - and those actions would impact all the other checkboxes as appropriate.
There was a problem hiding this comment.
Thanks, I think it'll be straightforward to restore this behaviour.
There was a problem hiding this comment.
I checked the behaviour on main. Here are some recordings:
When starting from no selections and adding, it appears indeterminate:
There was a problem hiding this comment.
I played around with this for a while and am can't tell why it wouldn't work. Sticking a breakpoint in the property getter the CheckState value is bound to shows it's getting a null but displaying as a false. Anyone got any thoughts or ideas here?
Note that this is not yet working correcetly due to an apparent bug in the control being used. That's being investigated separately.
| <FluentPopover AnchorId="typeFilterButton" @bind-Open="_isTypeFilterVisible"> | ||
| <Header>Resource Types</Header> | ||
| <Body> | ||
| <FluentStack Orientation="Orientation.Vertical"> | ||
| <FluentCheckbox Label="All" CheckStateChanged="HandleTypeFilterShowAllChanged" |
There was a problem hiding this comment.
The current code doesn't seem to respond to clicking the All checkbox as expected, but I think its because of the ShowIndeterminate parameter in my other comment and not because of the changes from CheckState/CheckStateChanged to @bind-CheckState. I think when it is checked and you click it, it goes to indeterminate state, but then immediately gets flipped back to true because nothing changed with the other checkboxes.
|
GIF of latest revision's behaviour:
|
For whenever someone is looking through the history when trying to fix the |
Note that currently that data is hard coded, but the new upcoming API work will allow the server to tell the client what types to expect.