docs(DataTable): add reference stories for row actions

[joshblack]

Closes https://github.com/github/primer/issues/1816

Changelog

New

• Add story for a single row-level action
• Add story for two row-level actions
• Add story for row-level actions in a menu

Changed

• Make field optional for "virtual" columns like a sortable column which has no value in the data set
• Update header from string to string | (() => React.ReactNode) to support custom rendering

Removed

[changeset-bot]

⚠️ No Changeset found

Latest commit: f0ca043

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[joshblack]

@colebemis @mperrotti this is currently adding stories-only for these patterns just to see how far we could go with what we have built-in.

Curious if you all had any recommendations or ideas for ways to help abstract or make row-level actions easier for consumers to implement 👀

[github-actions]

size-limit report 📦

Path	Size
dist/browser.esm.js	94.47 KB (0%)
dist/browser.umd.js	95.04 KB (0%)

[colebemis]

Is this space between the icon button and the edge of the table intentional?

[joshblack]

Good catch @colebemis! Let me look into it 👀

[mperrotti]

Curious if you all had any recommendations or ideas for ways to help abstract or make row-level actions easier for consumers to implement 👀

Maybe we could export a component you can use in renderCell that makes it easy to render one or more actions?

[mperrotti]

@ericwbailey - should the row actions be in a role="toolbar" and only have one tab stop? Or should we keep them as separate unrelated buttons?

[joshblack]

@colebemis seems like it's coming from auto-sizing of table cells from the table layout algorithm 😞

I'll defer this for after @mperrotti's work for column layout and see if it persists or if we need to target this case specifically through some kind of abstraction 👍

[joshblack]

@mperrotti I'd love to make something simple but couldn't seem to land on the right abstraction 🤔 Curious if you have any ideas or places to take inspiration from that would help to simplify this.

One idea was to introduce primitives like:

• RowAction
• RowActionGroup (which would contain RowAction)
• RowActionMenu, RowActionMenuItem

Where RowAction would ostensibly be a wrapper for IconButton and RowActionMenu would be a wrapper for ActionMenu. They didn't seem to add much value though.

Here's what some of the stories might look like with this in mind:

With Row Action

// Before
<IconButton
  aria-label={`Download: ${row.name}`}
  title={`Download: ${row.name}`}
  icon={DownloadIcon}
  variant="invisible"
  onClick={() => {
    action('Download')(row)
  }}
/>

// After
<RowAction
  rowHeader={row.name}
  action="Download"
  icon={DownloadIcon}
  variant="invisible"
  onClick={() => {
    action('Download')(row)
  }}
/>

With Row Actions

// Before
<>
  <IconButton
    aria-label={`Edit: ${row.name}`}
    title={`Edit: ${row.name}`}
    icon={PencilIcon}
    variant="invisible"
    onClick={() => {
      action('Edit')(row)
    }}
  />
  <IconButton
    aria-label={`Delete: ${row.name}`}
    title={`Delete: ${row.name}`}
    icon={TrashIcon}
    variant="invisible"
    onClick={() => {
      action('Delete')(row)
    }}
  />

// After
<RowActionGroup rowHeader={row.name}>
  <RowAction
    action="Edit"
    icon={PencilIcon}
    variant="invisible"
    onClick={() => {
      action('Edit')(row)
    }}
  />
  <RowAction
    action="Delete"
    icon={TrashIcon}
    variant="invisible"
    onClick={() => {
      action('Delete')(row)
    }}
  />
</RowActionGroup>

With Row Action Menu

// Before
<ActionMenu>
  <ActionMenu.Anchor>
    <IconButton
      aria-label={`Actions: ${row.name}`}
      title={`Actions: ${row.name}`}
      icon={KebabHorizontalIcon}
      variant="invisible"
    />
  </ActionMenu.Anchor>
  <ActionMenu.Overlay>
    <ActionList>
      <ActionList.Item
        onSelect={() => {
          action('Copy')(row)
        }}
      >
        Copy row
      </ActionList.Item>
      <ActionList.Item>Edit row</ActionList.Item>
      <ActionList.Item>Export row as CSV</ActionList.Item>
      <ActionList.Divider />
      <ActionList.Item variant="danger">Delete row</ActionList.Item>
    </ActionList>
  </ActionMenu.Overlay>
</ActionMenu>

// After
<RowActionMenu>
  <RowActionMenuItem onSelect={() => { /* ... */}>
    Copy Row
  </RowActionMenuItem>
  <RowActionMenuItem>Edit row</RowActionMenuItem>
  <RowActionMenuItem>Export row as CSV</RowActionMenuItem>
  <RowActionMenuItem.Divider />
  <RowActionMenuItem variant="danger">Delete row</RowActionMenuItem>
</RowActionMenu>

[colebemis]

Looks good! I'm okay with moving forward with this more verbose API for now. We can always create a simplified abstraction later without a breaking change, right?

[colebemis]

Do we want to add these stories to the docs?

[mperrotti]

I like the RowActionGroup/RowAction/RowActionMenu abstraction, but I'm also ok with moving forward with the more verbose API for now.

Also just wanted to remind the group that we're not restricting consumers to icon-only buttons. It's just the preferred format to use when possible. There might be actions that can't easily be represented with an icon.