Table in selection mode should not prevent Row actions

[selrond]

Provide your feedback here.

From the docs:

When at least one item is selected, the table is in selection mode, and clicking or tapping a row toggles the selection.

I believe this is too restrictive. Is there a reason a row action is inaccessible when this selection "mode" is in play?

Selection could still be controlled through other means (checkboxes for instance), while allowing the row actions.

Version

1.7.0

[LFDanLu]

If I remember correctly, this behavior was mainly for mobile users. There were cases design wise where checkboxes are omitted by default from the Table and mobile users would enter the "toggle" selection mode via pressing and holding on a target row. Since the last action was to select a row, we figured that intuitively next taps on subsequent rows would for further selection rather than performing an action on a different row.

What kind of user flow are you envisioning here where you'd like the row action to fire on subsequent pressed after toggling selection for a row?

[selrond]

What kind of user flow are you envisioning here where you'd like the row action to fire on subsequent pressed after toggling selection for a row?

Nothing fancy or unusual, really.
Row actions are extremely common, and usually have some affordance for toggling selection (checkboxes) designed.
If a user selects a row (using the checkbox), it’s quite unexpected to have the row action blocked / seemingly replaced by this selection mode behavior change.

For instance, if the main row action is opening a sidebar with more row details, and a user is selecting some rows in preparation for a bulk action of some kind, and want to quickly check some row details to guide their decision, it’s not possible currently. They’d have to either clear the entire selection to be able to trigger the row action, or change the design and introduce some kind of button to do so.

[selrond]

@LFDanLu does this make sense? I haven’t studied the source for this, but if you / the team is good with it, I could try to implement some flag

[LFDanLu]

Yeah, I agree that it there is merit to preserve the interaction required to trigger the row action rather than flip it when a row becomes selected. Will have to bring this up to the team to see if others have any opinions or have findings from user testing from when this was first implemented, I'm having trouble digging up any notes from that time myself.

[LFDanLu]

Apologies for the delay, chatted with the team about this today. We imagine that if we were to support this we would need to add a new prop to useSelectableItem that would define the "priority" of the row action, overriding any current calculated action priority that happens in

react-spectrum/packages/@react-aria/selection/src/useSelectableItem.ts

Lines 203 to 218 in 4a46c6e

	// With checkbox selection, onAction (i.e. navigation) becomes primary, and occurs on a single click of the row.
	// Clicking the checkbox enters selection mode, after which clicking anywhere on any row toggles selection for that row.
	// With highlight selection, onAction is secondary, and occurs on double click. Single click selects the row.
	// With touch, onAction occurs on single tap, and long press enters selection mode.
	let isLinkOverride = manager.isLink(key) && linkBehavior === 'override';
	let hasLinkAction = manager.isLink(key) && linkBehavior !== 'selection' && linkBehavior !== 'none';
	let allowsSelection = !isDisabled && manager.canSelectItem(key) && !isLinkOverride;
	let allowsActions = (onAction || hasLinkAction) && !isDisabled;
	let hasPrimaryAction = allowsActions && (
	manager.selectionBehavior === 'replace'
	? !allowsSelection
	: !allowsSelection || manager.isEmpty
	);
	let hasSecondaryAction = allowsActions && allowsSelection && manager.selectionBehavior === 'replace';
	let hasAction = hasPrimaryAction || hasSecondaryAction;
	let modality = useRef<PointerType | null>(null);

This would be very context dependent as we've found experiences in the wild that mimic our current behavior (Android filesystem/iOS Gmail app/etc), mimic the behavior you described yourself (Android Gmail app), or something else entirely where tapping may bring up a context menu instead.

It is hard to say if when we would pick this up ourselves. As can be seen in the code above would entail a lot of testing of all the combinations/permutations of various settings so it could end up having unforeseen ramifications so if you'd like to do some initial investigate that would be helpful!

[selrond]

@LFDanLu Just came across the same issue on GridList — I was trying to use it for a TODO-like UI pattern, where clicking on an entry (main action) navigates to details, and selection is done using checkboxes. However, because of this behavior, I can’t use the GridList, as I don’t want the main action to be replaced with the toggle selection mode.

[selrond]

It’s still possible that I’m misusing it for a wrong use-case, but on the first sight it looked like a perfect component for implementing TODO-like pattern.

[LFDanLu]

Right, GridList uses the same useSelectableItem code under the hood so applying the aforementioned update there should theoretically enable that use case for GridList.

[devongovett]

We discussed adding an itemBehavior prop today for a different use case, which would accept 'action' | 'selection' | 'both' as options.

• action: Item actions always take precedence.
• selection: Selection always takes precedence.
• both: The current behavior, which depends on whether any items are selected in the collection.

The selection code is quite complicated to handle lots of different combinations of behaviors already, so we'll need some time to determine what edge cases need to be handled here.

[davemoz]

I see this issue moved "To Groom" in September. Any other progress?

I'm in a similar boat: need to limit selection strictly to the checkboxes only, even after one is selected, and allow other toggles/buttons in the row to be clicked without affecting selection of that row.

[alirezamirian]

UNSTABLE_itemBehavior is already added in the low-level hook for selectable items.
The only blocker is now that the option is not supported fully in the chain:
⛔ (RAC) Row -> ⛔ useTableRow -> ⛔ useGridRow -> ✅ useSelectableItem

Do you have any estimation on when it will be available for table?
Or do you accept PR on it?

[LFDanLu]

That change was more of a quick fix for ComboBox and thus not really in a state where I can comfortably say if it should be added to all the other hooks as API just yet. No eta on our side as to when this may get picked up but happy for a RFC/discussion on the API as is and explorations into use cases/edge cases (e.g. as touched on briefly here: #8947 (comment))