md-data-table
md-data-table copied to clipboard
daniel-nagy
Row Selection Behavior
Row Selection Logic
I've been receiving some controversial request on how row selection should work. The main concern is whether or not the selection of items should persist between page navigation, that is to say, should the selection of non-visible items be allowed.
Here is how this is going to work, If you are in favor of allowing items to be selected when not visible then leave a comment here that says +1 if you are opposed leave a comment that says -1. In addition, you may leave a an argument for or against it but please make it brief. Periodically I will check this thread and update the voting poll and the motivation for allowing or disallowing if anyone has contributed a valid argument.
I am on the fence.
Votes
| Opposed | In Favor | On the Fence |
|---|---|---|
| 12 | 13 | 4 |
Motivation For Disallowing
- It may not be obvious to the user that they have items selected if they are not currently visible.
- If items are paginated on the server then persisting selected items may result in data integrity violations
Motivation for Allowing
- It makes manipulating large data sets easier by allowing the user to select as many items as they want before performing an action.
- If the number of selected items is displayed in a table toolbar then is should be sufficient for the user to infer they have items selected that are not visible
- The fact that items are visible or not does not necessarily guard against stale data.
-1
And these are my reasons: 1- selection should be cleared after a page change 2- select all should select only the items in the current page (but this doesn't mean a bulk select/delete all can't be added, but shouldn't be the default) 3- if you try some applications with an extensive tables use, the 99% will work as i said above. 4- if you really want add that functionality, i will do it after providing the default behavior and not starting from this in mind.
+1 1 - Number of items selected can be displayed so not that confusing. 2 - Limit of displaying maximum 15 rows makes it hard to select over multiply pages (if you took the feature away)
I don't think it should be taken away instead just giving as an option. md-persistent-select=true for maintaining selections over pages and md-select-all-page-only=false for changing the select all behavior etc.
+1 - The fact that items 'off screen' are selected can be communicated with numerous UI hints - the pagination footer, and the table header toolbar. Here's a screenshot of how we use the table, we have way too many elements in our dataset to display at once so we're happy with this solution. And so far, the users have been too :)
At the moment, I'm using the select all as global, but I've almost deleted all my data because of global select all. On the other hand, it could be useful to be able to go through pages and select individual items as you move along.
I'm kind of on the fence, but clearing selection after each page isn't really that tough to do.
@gligoran I would suggest a dialog to first confirm deleting all items :stuck_out_tongue_closed_eyes:
Good point I don't think there is anything stoping the developer from clearing the selected items on page change from within their controller.
@daniel-nagy: Did that after those first few times. Thankfully everything is still in development, so nothing critical :)
+1 This is very important for me...
Please add an option to table how that clearing selection should work and lets user decide it. like
0: on the fence
I'm on the fence because the question is unclear :)
Preseve the user's selection until they change it. Pagination does not have the affordance of a "selection changing control".
If the question is "should selection be preserved across pagination changes", this is how gmail works. If you select something, pagination changes don't affect your selection.
However, I'm with @Soulcyber, and so is gmail. Select all on my gmail inbox in gmail selects all mail on that page, with an option to bulk select everything that's hidden.
I'm with @activedecay on this one. The question is kind of unclear.
1.) Should selection persist between pagination, yes. This is inline with existing google applications. 2.) Should "Bulk Select" select items not in the current view, lord no. The ability to select everything in a record set and perform an action has disaster written all over it.
+1
But keep it as an opt-in (via attribute md-persistent-selection or something)
-1 for the reason that it could easily lead to records being deleted unknowingly. If you have a table with 1000's of rows, then finding which are selected and where would be a nightmare. Best do it the usual way of show xxx number of items and use sort/filters, then select.
-1
If this feature is added it should be an option (and not the default behavior) for all the reasons stated in the previous posts....
0: On the fence.
Best behaviour would be what @joshtoo and @activedecay described. Option to bulk-select would be a nice add-on.
+1
The question doesn't seem unclear. I don't see mention of select all functionality in the description, it seems to be asking only about selection persistence across pagination. For me as a user, my selection vanishing when I change the page is unexpected and frustrating, it should definitely persist. I agree with @maryisdead, @joshtoo and @activedecay as well about select all functionality. Select all should select all on page, not all in the entire data set.
I think there should be some kind of option for SHIFT + Click selection which is an expected behavior from many web applications. Right now, it seems that there is no way to bulk select items and that is a major drawback of this module for the type of project where that UX is desired. Even if you don't want to support it natively, it could be easily enabled by giving developers a callback function for when a row is clicked. I would write the multi-selection logic myself, track indexes, figure out if selection is positive or negative, etc. @daniel-nagy this seems to be the best place for this discussion, thoughts?
-1 but.. I do want to able to select all items on all pages with on button. Not sure if thats a part of this matter.
+1 IMO the primary purpose of pagination is to avoid scrolling (keeping all table items on screen), not a bandwidth or performance concern. Going to the next page is not "navigating away", it's equivalent to scrolling down, so doesn't interfere with page state. If loading needs to occur in the background it should be transparent to the user, like a virtual repeat.
A deselect all API, called by the developer on page change, would easily address the case where one did want to deselect.
+1
I can see the argument for both sides. But, fundamentally, I believe that this is an application specific concern and that a complete implementation of the md-data-table should allow this kind of behavior as an option.
+1
Alternatively, there should be an option for one-way-bindings so that this can be managed externally. This would require:
- an event/callback for when an item or items are selected/deselected
- a function for testing if an item is selected
+1
I don't see why this can't be added button like.
In gmail, if you select all, it first select all element in the view, but it let you chose then to select all element that matches criteria.
I guess that it's the expected behavior for that function.
+1 Although it could be part of configuration on table level, so you could make a decision for each particular case.
+1 with optional attribute.
@daniel-nagy I fixed this issue by adding additional scope attributes on the mdSelect directive. I kept the default behavior if this attributes are not included. --md-select-all : Expects an array of Objects, this will select all rows across all pages. --md-search : Expects a string(variable you filtering on ), this will select all rows across all pages that show up when filter is applied.
