Skip to content

Make DataTable rowDetails expansion tracked by primary key rather than index #7547

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

Merged
merged 8 commits into from
Apr 17, 2025

Conversation

MikeKingdom
Copy link
Collaborator

@MikeKingdom MikeKingdom commented Mar 19, 2025

What does this PR do?

This PR fixes an issue from Kari where DataTables rowDetails expansion was tied to a table index. Being based on index wasn't working very well with filter/sort or pagination.

These changes also introduce the ability to use the details row expansion in a "controlled" mode. For example:

const [expand, setExpand] = useState([]);
...
<DataTable rowDetails={{
  render: (datum) => <SomeComponent data={datum} />,
  expand,
  onExpand: (expanded, datum) => setExpand(expanded),
}} />

This pattern more closely follows how we do selections as well as grouped row expansions.

I re-wrote the rowDetails story to better show a rowDetails example using the StarWars api. It has more interesting details worth showing in a detail row.

Where should the reviewer start?

DataTable/Body.js

What testing has been done on this PR?

storybook and manual

How should this be manually tested?

Storybook Visualizations/DataTable/rowDetails

Do Jest tests follow these best practices?

  • screen is used for querying.
  • The correct query is used. (Refer to this list of queries)
  • asFragment() is used for snapshot testing.

Any background context you want to provide?

From Kari's request:

We've been implementing a feature using the rowDetails prop on DataTable. There are some oddities about how it works, so I'd like to suggest a few enhancements:

  • Which rows are expanded is tracked via their index instead of by the primary key. This means if you expand the fifth row and then resort, the fifth row is still expanded even if it has completely different data. If you tracked expanded rows using primary key, then this would lead to more natural result of the same data being expanded even if it is in a new location in the table
  • Similarly, the indexes expanded is the same when you go to a new page of data in a paginated table. So if you had the 2nd row expanded and then go to the next page, the 2nd row of the new page is expanded. This doesn't seem obvious.
  • It would also be nice to support get/set props like for select to track and control which rows are expanded.... Similar to select and onSelect props. And/or allow controlling this via Data context props.

What are the relevant issues?

Screenshots (if appropriate)

image

Do the grommet docs need to be updated?

Yes

Should this PR be mentioned in the release notes?

Yes

Is this change backwards compatible or is it a breaking change?

This change should be backwards compatible since we didn't expose the expansion keys before now. It will also use the index as a key if for some reason it can't find a primary key

Copy link
Collaborator

@britt6612 britt6612 left a comment

Choose a reason for hiding this comment

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

Thanks Mike for working on this and getting something up I just have a couple questions as far as code but I like the behavior thank you for changing the story its nice to have!

@britt6612
Copy link
Collaborator

I was trying to think of a way we can also write a test for this behavior but that doesnt have to block this PR. One small comment then everything looks good!

Copy link
Collaborator

@taysea taysea left a comment

Choose a reason for hiding this comment

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

Overall looks great and storybook example is super helpful/realistic thank you, one small comment.

@MikeKingdom MikeKingdom requested review from britt6612 and taysea April 3, 2025 15:58
@MikeKingdom MikeKingdom requested a review from jcfilben April 4, 2025 19:37
Copy link
Collaborator

@taysea taysea left a comment

Choose a reason for hiding this comment

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

LGTM, thanks Mike!

Copy link
Collaborator

@jcfilben jcfilben left a comment

Choose a reason for hiding this comment

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

Looks good!

@jcfilben jcfilben merged commit 917d394 into master Apr 17, 2025
15 of 16 checks passed
@britt6612 britt6612 mentioned this pull request Apr 30, 2025
3 tasks
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.

4 participants