chore(table): update expandable table data

[jenny-s51]

What: Closes #7685 , towards #7384, follows investigation done in #7795

• introduces a set of hardcoded table data to use for the rest of the demos.
• updates the expandable demo data to align with the new data

The expandable table data must remain hardcoded in the md file because the consumer needs to specify the data that is in the expandable section.

Because the data is hardcoded here, we cannot paginate this without puffing up the demo with data and pagination logic, therefore pagination cannot be supported in this demo.

Link to expandable demo for convenience: https://patternfly-react-pr-7838.surge.sh/components/table/react-demos/expandcollapse-all/

[patternfly-build]

Preview: https://patternfly-react-pr-7838.surge.sh

A11y report: https://patternfly-react-pr-7838-a11y.surge.sh

[nicolethoen]

Not too long ago, the table and table composable examples were refactored so that the table data was structured to look more like it was coming from an API and the data was not stored in the example's state. I'm wondering if this is a good thing to also do with this new data set in the demos. If you want to walk through more of what I mean, let me know! Even the most basic table composable example demonstrates what i'm talking about.

[jenny-s51]

@nicolethoen this is a great idea - looking at the syntax in the Basic Table Composable demo:

  // In real usage, this data would come from some external source like an API via props.
  const repositories: Repository[] = [
    { name: 'one', branches: 'two', prs: 'three', workspaces: 'four', lastCommit: 'five' },
    { name: 'one - 2', branches: null, prs: null, workspaces: 'four - 2', lastCommit: 'five - 2' },
    { name: 'one - 3', branches: 'two - 3', prs: 'three - 3', workspaces: 'four - 3', lastCommit: 'five - 3' }
  ];

This would be a great standard to follow for other demos and I think we definitely should try to take data out of the state and apply this approach where we can.

For this expandable demo specifically, it looks like the data would need to remain in the state, since the isExpanded behavior is directly related to the isOpen attribute in this.state.rows, which gets updated in the state by the onCollapse function. WDYT @nicolethoen ?

[mcarrano]

@jenny-s51 can you point me to what's changed and what exactly I should be reviewing from a UX perspective? Thanks.

[jenny-s51]

@mcarrano The expandable react demo was updated to use the recently updated table data from https://docs.google.com/spreadsheets/d/1-sqIbCpmFfmID0fByWZSOBpn99ocGyT2KoUZ5B_s3zo/edit#gid=0 as part of patternfly/patternfly-design#1157!

The existing core demo: https://pf4.patternfly.org/components/table/html-demos/expandable/

The existing react demo: https://www.patternfly.org/v4/components/table/react-demos/expandcollapse-all/

And the updated react demo: https://patternfly-react-pr-7838.surge.sh/components/table/react-demos/expandcollapse-all/

[nicolethoen]

@jenny-s51 it shouldn't be necessary to couple the isExpanded behavior with the data coming from the API. You'd probably want to handle it like the expandable example does where it maintains an array of expandedRepoNames (line 80 in the example code) and uses that information on line 106 when it's constructing the rows object to pass to the Table.

[mcarrano]

@jenny-s51 I think this looks good. One of the ideas we talked about was maybe using labels to represent status just to give examples of how to add an element other than text in a table cell. How easy or hard would that be to do? It's sort of a nice to have, but would be good to add if we can. Or we can follow up at a later date. @mmenestr what are your thoughts?

[jenny-s51]

You'd probably want to handle it like the expandable example does where it maintains an array of expandedRepoNames (line 80 in the example code) and uses that information on line 106 when it's constructing the rows object to pass to the Table.

Thanks for suggesting this approach @nicolethoen ! I've updated the code in the expandable demo file to implement the expandable rows per your comment! I've addressed your feedback regarding #7857 (comment) as well and removed lodash from the data file.

One of the ideas we talked about was maybe using labels to represent status just to give examples of how to add an element other than text in a table cell. How easy or hard would that be to do? It's sort of a nice to have, but would be good to add if we can. Or we can follow up at a later date. @mmenestr what are your thoughts?

This is a great idea @mcarrano - I've updated the demo to represent the status cells using labels, following the mock you linked. @mcarrano @mmenestr please share your thoughts when you get a chance 🙂

[jenny-s51]

Still WIP - marking as draft until I fix the padding on the expandable content and a few other remaining visual things

[mcarrano]

Looks good. Thanks for making those changes @jenny-s51 !

[tlabaj]

LGTM!

[patternfly-build]

Your changes have been released in:

• eslint-plugin-patternfly-react@4.73.1
• @patternfly/react-catalog-view-extension@4.85.1
• @patternfly/react-charts@6.87.1
• @patternfly/react-code-editor@4.75.1
• @patternfly/react-console@4.85.1
• @patternfly/react-core@4.234.1
• @patternfly/react-docs@5.95.1
• @patternfly/react-icons@4.85.1
• @patternfly/react-inline-edit-extension@4.79.1
• demo-app-ts@4.194.1
• @patternfly/react-integration@4.196.1
• @patternfly/react-log-viewer@4.79.1
• @patternfly/react-styles@4.84.1
• @patternfly/react-table@4.103.1
• @patternfly/react-tokens@4.86.1
• @patternfly/react-topology@4.81.1
• @patternfly/react-virtualized-extension@4.81.1
• transformer-cjs-imports@4.72.1

Thanks for your contribution! 🎉