Mui-datatables: toobarSelect replaces toolbar when rows are selected

[b1rt]

I'm not sure if it's bug or not, but it is negative user experience.

If you select any rows after applying search of filters, toolbarSelect (which shows how many rows you are selected) replaces and hovers standard toolbar, thus make it impossible to discard or change search, or change filters (but you can discard filters, as they appear under toolbar).

So, if user select any rows after searching, he must discard his selection first to discard or change search string, making it useless to search and then select rows.

Expected Behavior

After selecting rows, user can change search string of filters.

Current Behavior

After selecting rows, toolbar disappears (replaced with toolbar select)

Steps to Reproduce (for bugs)

1. Search smth in your table.
2. Select any of found rows.

Your Environment

| Tech | Version |
|--------------|---------|
| Material-UI | 3.3.1 |
| MUI-datatables | 2.0.0-beta-52 |
| React | 16.6.0 |
| browser | chrome |

[jakesyl]

I'm having the same issue

[byb121]

I'm having the same issue, I hope I can place the whole bar elsewhere, or disable it completely.

[gabrielliwerant]

I think the UX would be troublesome to have both toolbars available at the same time. For example,

• With select bar and toolbar open, should the download/print options work only on selected rows or not?
• With select bar and toolbar open, changing filters can remove already selected rows. Should they remain selected and then return selected if the filters change again in a way that reveals them?
• With select bar and toolbar open, changing the search can also remove already selected rows.

Due to the UX difficulties of having both of these options available at the same time, there is often a toggle that enables/disables select checkboxes in interfaces.

What I think would help here is the capacity to add the main toolbar options to the select toolbar, thereby making the fact that they are operating in a select context clear. That might be a bit of a work, but I think it's a worthy goal.

[mattgbrich]

@gabrielliwerant

I would suggest that the Title/textCopy area should also be considered. It's often much more desirable to keep the table Title visible rather than being forced to replace it with <num> row(s) selected.

This is especially relevant to single-select tables. Constantly displaying 1 row(s) selected is meaningless information in that case, and creates a poor UX by removing relevant information from the users view, and replacing it with information they don't care about.

The UX concerns you mentioned are only relevant to the options, the current solution of replacing the entire toolbar _creates_ new UX problems for the text display. The text display should be able to be managed separately so that it isn't impacted by changes to the options.

Could the two be separated so a solution to the UX problems surrounding options does not impact the table Title?

It seems it would be easy enough to dynamically render different containers for the options based on selection, rather than dynamically rendering entirely different toolbars based on selection.

[gabrielliwerant]

@mattgbrich I agree that it would be good to keep the table title visible even while in the select toolbar, though this would be a big break in the UI from previous versions, and I don't like the idea of an API option for it, since typically these types of visual distinctions are handled via style overrides. What I might accept is something like a title that is hidden by default, but can then be overridden via styles. Maybe that's better than having to add it through the custom select toolbar.

I also agree that the toolbar count doesn't make that much sense when only a single selection is possible, but we still need a way to present options to the user that are impacted only on the selected row, and a replacement toolbar seems to be the UX standard.

I think the happiest middle ground here that provides the most avenues for customization, is to make it easier to integrate the existing toolbar features into the select toolbar and/or make the select toolbar appearance easier to customize.

If someone wants to discuss specific approaches for a PR, I'm open to that conversation. But as for my own efforts, there are currently larger problems that require attention, so this one would be low priority for me at the moment.