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
When using conditional selection by setting a predicate function to determine whether individual items are selectable, both the web component and Flow component currently hide the select all checkbox. As this limits the usefulness of this feature we should consider how we can support this.
Describe the solution you'd like
The issue with conditional selection is that if individual items are not selectable, then the user can never select all items, and thus the select all checkbox would "get stuck" in an indeterminate state. Same for deselect all if there are selected items that the user may not deselect.
The main idea to solve this so far has been to make the select all checkbox only consider items that the user may change the selection state of:
If there are unselected items, but the user may not select any of them, the checkbox would still be checked
Likewise, if there are selected items, but the user may not deselect any of them, the checkbox would be unchecked
If there is at least one selected item that the user may deselect, then the checkbox is indeterminate
When toggling the checkbox, it would only select or deselect items that the user may change the selection state of
However there are several challenges with implementing this:
To figure out if any unselected item can be selected by the user we would need to load all items from the data provider and test if they are selectable or not. This is much more costly in terms of performance compared to the current check which just needs to run a size query against the data provider and compare the result against the number of selected items.
To check if any existing selected items may be deselected by the user we need to run the predicate against all existing selected items. The issue here is that the selected item instances may become stale if the data provider is refreshed in between, and thus running the predicate against a selected item instance could return different results than running it against the updated item in the data provider.
One approach to solve this could be to compute a list of non-selectable items whenever:
The data provider changes
Data in the data provider is refreshed (can be optimized to update the previously computed list when single items are refreshed)
Or the predicate changes
With that a full data provider fetch would only occur in these cases, but not when selecting individual items in the grid.
With that list, we can then:
Figure out if there are any unselected items that the user may still select, which should be Number of selected items that may be deselected + Number of all non-selectable items < Data provider size
Figure out if there are selected items that can be deselected by checking if some selected items are not the list of non-selectable items
As this would still add a full data provider fetch in a number of cases, the feature should be opt-in to not introduce any regressions regarding performance. For the Flow component it would make sense to hide the checkbox by default, and not compute the selected state as long as it is hidden. To opt in, developers can then explicitly set it to visible, similar to how it works with lazy / backend data providers currently.
For the web component we can consider enabling the feature by default, as the select all checkbox is only functional when using the in-memory / array data provider, in which case we would only introduce some additional iterations + filtering on existing data.
Describe alternatives you've considered
Give developers full control over the select all checkbox (visibility and checked state), and notify them whenever the selection state changes. That would allow them to implement custom logic to determine what state the checkbox should be in, and possibly do that in a more performant fashion than what we can do with a generic mechanism using the data provider APIs.
Additional context
No response
The text was updated successfully, but these errors were encountered:
Describe your motivation
When using conditional selection by setting a predicate function to determine whether individual items are selectable, both the web component and Flow component currently hide the select all checkbox. As this limits the usefulness of this feature we should consider how we can support this.
Describe the solution you'd like
The issue with conditional selection is that if individual items are not selectable, then the user can never select all items, and thus the select all checkbox would "get stuck" in an indeterminate state. Same for deselect all if there are selected items that the user may not deselect.
The main idea to solve this so far has been to make the select all checkbox only consider items that the user may change the selection state of:
However there are several challenges with implementing this:
One approach to solve this could be to compute a list of non-selectable items whenever:
With that a full data provider fetch would only occur in these cases, but not when selecting individual items in the grid.
With that list, we can then:
Number of selected items that may be deselected + Number of all non-selectable items < Data provider size
As this would still add a full data provider fetch in a number of cases, the feature should be opt-in to not introduce any regressions regarding performance. For the Flow component it would make sense to hide the checkbox by default, and not compute the selected state as long as it is hidden. To opt in, developers can then explicitly set it to visible, similar to how it works with lazy / backend data providers currently.
For the web component we can consider enabling the feature by default, as the select all checkbox is only functional when using the in-memory / array data provider, in which case we would only introduce some additional iterations + filtering on existing data.
Describe alternatives you've considered
Give developers full control over the select all checkbox (visibility and checked state), and notify them whenever the selection state changes. That would allow them to implement custom logic to determine what state the checkbox should be in, and possibly do that in a more performant fashion than what we can do with a generic mechanism using the data provider APIs.
Additional context
No response
The text was updated successfully, but these errors were encountered: