Skip to content

fix: Support range selection with grid/table checkboxes #7839

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

Open
wants to merge 3 commits into
base: main
Choose a base branch
from

Conversation

levrik
Copy link

@levrik levrik commented Feb 27, 2025

Upstreaming a fix for the product I'm working on. Please let me know if you require an issue to be created and I'll create one.

I'm not particulary happy with the fix but making e.shiftKey flag available in onChange of useCheckbox, which goes down quite deep through other hooks, probably does not make a lot of sense. Simply tracking shift key state in a local ref seemed like the cleanest solution to me.

✅ Pull Request Checklist:

  • Included link to corresponding React Spectrum GitHub Issue.
  • Added/updated unit tests and storybook for this change (for new code or code which already has tests).
  • Filled out test instructions.
  • Updated documentation (if it already exists for this component).
  • Looked at the Accessibility Practices for this feature - Aria Practices

📝 Test Instructions:

Use a table with slot="selection" checkboxes and try to do a range selection by holding Shift key.

🧢 Your Project:

@levrik levrik force-pushed the fix-collection-checkbox-range-selection branch from be59ade to b451fa3 Compare February 28, 2025 10:56
}
};

document.addEventListener('keydown', trackKeyDown);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

these should be capturing listeners, don't want to miss it should something call stopPropagation

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

makes sense, added

document.removeEventListener('keydown', trackKeyDown);
document.removeEventListener('keyup', trackKeyUp);
};
});
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
});
}, []);

We don't want to re-run this every time we render, only on mount/unmount

Copy link
Author

@levrik levrik Mar 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh my... no idea how I missed that. added.

document.removeEventListener('keyup', trackKeyUp);
};
});

// Checkbox should always toggle selection, regardless of selectionBehavior.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will need to discuss with the team if the proposed change conflicts with this intent

Copy link
Author

@levrik levrik Mar 3, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just to add some background here: I have a table with href on each row so people use the checkboxes to do the initial selection. While the table then switches into another mode that allows selection also on the rest of each row, people tend to keep clicking on the checkboxes. Not having Shift+Click for range selection available there while it is on the rest of the table is kinda confusing and led to complaints from customers and even the CEO 😅

@snowystinger
Copy link
Member

FYI, haven't had a chance to bring it up yet. However, I did notice another issue we'll need to consider.

This attaches keydown window listeners, however, if the window isn't focused when the shift key is pressed. Maybe the user was responding to Slack in another window, but then shift clicked back. The range won't be expanded. We have to know at the time that the click occurs regardless. We'll either need to expose our press events on checkbox or we'll need to expose the shift key in the onChange event.

Thanks for your patience.

@levrik
Copy link
Author

levrik commented Mar 10, 2025

@snowystinger Yeah. These were compromises that I personally am fine with for my usecase but I understand that as a library this maybe is not good enough. Having access to the shiftKey flag of the originating event would be the much better implementation of course but I wasn't sure if exposing this in onChange makes any sense, especially given that it's only relevant when onChange was triggered by a mouse click.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants