Material-ui: [Table] 'onRowSelection' does't get called with 'none' while deselecting all rows by check a single row

[gunx3961]

Problem description

Try checking a single row after the table has been allSelected,
the single row won't be checked but 'onRowSelection' will get called with an array, which includes the single row's key.

Link to minimally-working code that reproduces the issue

function handleSelection(arr) {
  console.log(arr);
}

const data = [
  { id: '0', name: 'zero' },
  { id: '1', name: 'one' },
  { id: '2', name: 'two' },
  { id: '3', name: 'three' },
  { id: '4', name: 'four' }
];

  render() {
    return (
      <Table
        multiSelectable
        onRowSelection={handleSelection}
        >
        <TableHeader>
          <TableRow>
            <TableHeaderColumn>id</TableHeaderColumn>
            <TableHeaderColumn>name</TableHeaderColumn>
          </TableRow>
        </TableHeader>
        <TableBody
          showRowHover
          deselectOnClickaway={false}
          >
          {data.map((row, index) => (
            <TableRow key={index}>
              <TableRowColumn>{row['id']}</TableRowColumn>
              <TableRowColumn>{row['name']}</TableRowColumn>
            </TableRow>
          ))}
        </TableBody>
      </Table>
    );
  }

Versions

• Material-UI: 0.16.7
• React: 15.4.2
• Browser: Chrome 55

[NewOldMax]

I confirm same behavior on http://www.material-ui.com/#/components/table

[ArcanisCz]

And what is the desired behavior? I can imagine 2 outcomes.

Given table with rows [0,1,2,3], click to selectAll, then click on item 2.
1) Will result with item 2 unchecked, others remain checked (checked [0,1,3])
2) Will result with only item 2 checked (checked [2])

And then "selectAll" becomes unchecked. Checking it again will result in selecting all (it both cases)

[NewOldMax]

I expect something like this

[lagneshthakur]

I've raised a PR #7453 that fixes this and achieves the desired behavior.

[oliviertassinari]

We have been porting the component on the v1-beta branch. We reimplemented it from the ground-up. While we haven't tested it, I think that the issue is most likely fixed on that branch. Hence, I'm closing it.
Still, we will accept PR fixes until v1-beta takes over the master branch.

[rdsedmundo]

Did this ever get a fix on 0.x branch? Facing this problem on a legacy app that upgrading for the 1.x is not a viable option for now.

[oliviertassinari]

@rdsedmundo No, it wasn't.