-
-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DataGrid] Allow developers to differentiate the checkbox selection all state #1876
Comments
@EdmundsEcho Please provide a minimal reproduction test case with the latest version. This would help a lot 👷 . What problem are you trying to solve? |
@oliviertassinari Here is the link to the sandbox. Thanks for taking a look. - E |
@EdmundsEcho This is expected, |
Sure. The header for the checkbox is unique in that it could have a state that reflects whether or not all of the rows have been selected. The use case: I record when all of the records have been selected in my app's redux-store. I do so with the event "handleToggleAll". The current approach requires using the apiRef: const handleToggleAll = useCallback(
({ field }) => {
if (field !== '__check__') return;
//
// This is the current approach that makes an assumption about
// *when* the state was updated.
//
const isSelected = apiRef.current.getSelectedRows().size !== 0;
dispatch(
toggleValue(
nodeId,
identifier,
[],
isSelected,
),
);
},
[
apiRef,
dispatch,
identifier,
nodeId,
],
); |
@EdmundsEcho OK, this starts to be interesting. (We should have started there, the rest of the information provided, we can't do anything with it). So, the problem is: How can developers know if the end-user has selected all the rows? Now, we need to refine what selected all the rows to mean, because there are different versions:
export type GridSelectionModel = GridRowId[]; What we would likely need is: /**
* Set the selection model of the grid.
*/
export type GridSelectionModel = {
/**
* The selected rows.
*/
ids?: GridRowId[];
/**
* - false, a couple of rows are selected.
* - 'page', all the rows on the page are selected.
* - 'all', all the rows of the dataset are selected.
* The value of this property is not taking into account how the filtering is configured (Select everything vs. Just filtered)
*/
selectAll: false | 'page' | 'all';
}; |
@oliviertassinari If I'm tracking your thoughts correctly here, Identifying when all rows have been selected is likely a useful property to make part of api (one way or another). Yes? I believe the grid is tracking this state already. I say that because the grid only displays the version of the checkbox = checked in the header when all of the rows are selected; true even when I reach that state manually by selected one record at a time. However, I could not find the prop in the api. The way I'm having to do so now is as follows: apiRef.current.getAllRowIds().length === apiRef.current.getSelectedRows().size, On a related note, what the user intends when they hit the "select-all" toggle in the header can be a bit tricky. This said, a canonical interpretation likely exists. Keeping in mind that there are a couple of events that can get the grid to this "all rows selected" state
There are a few possible ways to interpret what a user means when they hit the "select all" checkbox in the grid header
The latter is likely canonical when there is an active filter. Otherwise, it's likely select all, visible or not. The tipping point for this last point of view: it's much easier to manually select what's in a view, than have to view/page through everything in order to select all. Does this make sense? Finally, I noticed the topic mentioned when tracking the selection model when using server-side pagination. Perhaps the following may be useful. Absolutely, the grid should have the capacity to "accumulate" the selected ids when using server-side pagination (a trivial/obvious given when using client-side). One challenge: How display all when not all of the rows have been loaded into the grid? The solution I'm using is to "model" the selection model as a function, not a value per se. If the selection model is a "set", then the function is a "set generator". So, when the user hits "select all", the selection model is a function that will set the initial state accordingly. If this is not done at the right time, the user will suffer a "flash" or re-renders: |
Still needing this feature |
Any updates on this? We have licenses for data grid pro and are trying to find a way to do select all with infinite scrolling, with data loaded server side. My only idea so far is to add a custom select all checkbox which tracks some select all state and add ids into the rowSelectionModel as the server loads them if selectAll is true. Not sure how that would impact perf....hopefully not too much? |
@jmsims2 That's what I do... I track whether the person hit the select all button. I use that state to know how to display what comes from the server. Separate from that, I ended-up maintaining a "selected list" separate from the grid (I don't send real-time updates to the server). The list is irrelevant when the select-all state is true, and cleared when the select-all is first cleared. So, what finally is sent back to the server is a list, and "select-all" state. I need both to represent the users intent. If your tracking this far, because I had long lists that users paged through, I actually used the "select-all" state to know how to interpret what was in the "selected list".
I could not figure out a simpler way. |
Just ran into the same problem.
Right now, I'm opting to add custom checkbox columns instead of using the one provided by Datagrid. |
"@material-ui/x-grid": "^4.0.0-alpha.31"
Clicking on the checkbox in the header (displayed when using the
checkboxSelection
feature), does not generate an event object that echos the selected state of the control.Going off topic describing a solution when what we care is the pain
It took me a bit to track down how to retrieve the value. I'm wondering if it makes sense to put the getter as part of the top-level field prop. So, instead of:
Given that this event is only generated when the user click-on the header input field (so no indeterminate state is possible), it might make sense to either generate a synthetic event that echos what we expect when clicking on any checkbox, or given the potential need to compute the state something as follows:
Order id 💳
The text was updated successfully, but these errors were encountered: