Implement sticky columns in GenericTable #1023
Conversation
| @@ -52,7 +57,6 @@ export const CASE_NOTE_COLUMNS = { | |||
| NoteContentPreview: { | |||
| key: 'content-preview', | |||
| header: 'Note Content Preview', | |||
| maxWidth: '450px', | |||
There was a problem hiding this comment.
Removed since this wasn't respected (maxWidth is not a valid property on ColumnDef and GenericTable doesn't do anything with it). There is a maxWidth applied to the Box below.
| @@ -74,7 +74,7 @@ const BulkServicesTable: React.FC<Props> = ({ | |||
| </NotCollectedText> | |||
| ); | |||
| return [ | |||
| CLIENT_COLUMNS.name, | |||
| { ...CLIENT_COLUMNS.name, sticky: 'left' }, | |||
There was a problem hiding this comment.
Known issue: Checkbox is not sticky. I think my current approach would need a bit more work to accomplish more than 1 sticky column per side. It's not ideal, but I am proposing to descope this and open another ticket, unless you see an easy way around it.
There was a problem hiding this comment.
Ok with me @martha. Not sure how much it would simplify things, but one option is to make the checkbox always be sticky. That seems reasonable to me.
There was a problem hiding this comment.
Thanks, Gig, good point! With this suggestion it wasn't so bad, see 273b059
| <Button onClick={primaryActionConfig.onClick} {...buttonProps}> | ||
| {primaryActionConfig.title} | ||
| </Button> | ||
| ))} | ||
| {primaryAction} | ||
| {!!secondaryActionConfigs && secondaryActionConfigs.length > 0 && ( |
There was a problem hiding this comment.
Noting that I think there was agreement around including the primary action config inside the secondary menu, so I'd say we can go ahead with that. Maybe it would be as simple as passing items={[primaryActionConfig , ...secondaryActionConfigs]} below.
Yes, I wanted to keep that on a separate diff since we haven't reached consensus on that change yet, but I opened a draft PR here: #1025 |
Description
GH issue: https://github.com/open-path/Green-River/issues/6761
This PR is a follow-up from this comment thread in Slack. Summary of changes:
I should note that, while I've once-overed every individual table that's using this new pattern, I haven't tested this PR extremely thoroughly, since the ticket is over estimate. For efficiency, I'm proposing to do more thorough QA in the QA environment once this is merged to the deploy branch.
Type of change
Checklist before requesting review