PF4 Please provide a lightweight composable component set for tables

[idevat]

Patternfly-table provides heavyweight component Table. This component tries to provide complex functionality to ease a development. But my experience with this component is a bit painful and I would welcome a set of simple composable components beside this super "smart" component. Let me elaborate it a bit.

As can be seen for example in issue #1399, component Table does not allow the developer to control some details. It tries to make things universal. In the case of issue #1399 it is about a control over the keys. It can fit to some use cases but not to all.

Sometimes, a particular use case could be achieved much more easily with set of simple tools. Actually, I haven't yet encountered a case where the current Table component saved me the hard work that a set of simple components couldn't handle. On the contrary. But it is true that my experience with this component is not extensive.

Most of the examples in https://www.patternfly.org/v4/documentation/react/components/table/ could be implemented with a set of simple components, I guess. Just a note, I haven't found the difference between First cell as header table and Simple table. When I looked into the code I found { title: 'Header cell', cellTransforms: [headerCol('selectable')] } but I have no idea what it should do (without more detailed study).

Take for example the issue #2357. If a user had components similar to these:

const PFTable = ({ children }) => (
  <table className="pf-c-table pf-m-grid-md">
    {children}
  </table>
);

const PFCompoundExpansionToggle = ({ expanded, onClick, children }) => (
  <td
    className={
      `pf-c-table__compound-expansion-toggle ${expanded ? "pf-m-expanded" : ""}`
    }
  >
    <button
      className="pf-c-button pf-m-link"
      type="button"
      onClick={onClick}
    >
      {children}
    </button>
  </td>
);

const PFExpandableRow = ({ children }) => (
  <tr className="pf-c-table__expandable-row pf-m-expanded">
    {children}
  </tr>
);

the implementation of task from issue #2357 might look like this:

const ClusterRow = ({ cluster }) => {
  const [expanded, setExpanded] = React.useState(false);
  return (
    <React.Fragment>
      <tr>
        <td>{cluster.name}</td>
        <PFCompoundExpansionToggle
          expanded={expanded}
          onClick={() => setExpanded(!expanded)}
        >
          {cluster.nodeList.length}
        </PFCompoundExpansionToggle>
      </tr>
      {expanded && (
        <PFExpandableRow>
          <td colSpan={2}>Nodes</td>
        </PFExpandableRow>
      )}
    </React.Fragment>
  );
};

const ClusterList = ({ clusterList }) => (
  <PFTable>
    <thead>
      <tr>
        <th>Cluster</th>
        <th>Nodes</th>
      </tr>
    </thead>
    <tbody>
      {clusterList.map(cluster => (
        <ClusterRow cluster={cluster} key={cluster.name} />
      ))}
    </tbody>
  </PFTable>
);

export default () => {
  const clusterList = [
    { name: "cluster-1", nodeList: ["one", "two"] },
    { name: "cluster-2", nodeList: ["one", "two", "three"] },
  ];
  return (
    <ClusterList clusterList={clusterList} />
  );
};

It is much more straightforward. There is simpler state logic. It's just React, the reader doesn't need to know a specific Table configuration (rows), which is itself a complex system. Maybe, there are some use cases where the component Table is effective. But it would be great to have a set of simpler composable components for the rest of use cases.

[rachael-phillips]

@priley86 @tlabaj making you aware

[rachael-phillips]

Hi @idevat thanks for filing! Would this experience be improved if we improve the documentation for our current Table?

[dgutride]

@idevat - thanks for opening this issue. Before we agree to take on this work, I'd like to see what @karelhala and @priley86 have to say about both the feasibility of this request as well as whether or not this is a valuable addition to the component library. @priley86 is away for a little while so we'll revisit this around the second week of July or so

[karelhala]

There has been a lengthy discussion at the start of pf4 project about table library [1]. React tabular [2] has been chosen. The main reason why is that any project can write rather simple formatter or transformer. At the same time we found the vanilla API is rather hard to use and we have wrote a wrapper that simplified it to some extend (you can still use vanilla API if you want to, for instance when moving from PF3 tables to PF4).

There was issue about providing simple table components as well, however we wouldn't be able to support fully accessibility and other computed values (they would have to be set by consumer).

I agree with you that these simple components should be introduced, we should export current table components and simplify them so consumers can use them without the need for table provider. But at the same time much bigger documentation for tables should be done as well. A lot of things are hinted or not shown directly (custom props passed to rows tor instance).

[1] https://www.polygon.com/nintendo/2019/6/22/18713685/super-mario-battle-royale-website-takedown-dmca-royale-infernoplus
[2] https://reactabular.js.org/#/

[idevat]

It would certainly be a good idea to improve the documentation. However, the main point was not about documentation.

Consider following example:

import React from "react";
import { Table, TableHeader, TableBody } from "@patternfly/react-table";

class Example extends React.Component {
  constructor(props) {
    super(props);
    this.state = {
      columns: ["first"],
      rows: props.exampleData.map(i => [i]),
    };
  }

  render() {
    const { columns, rows } = this.state;
    return (
      <Table caption="Selectable Table" cells={columns} rows={rows}>
        <TableHeader />
        <TableBody />
      </Table>
    );
  }
}

const Alternative = ({ exampleData }) => (
  <table role="grid" className="pf-c-table pf-m-grid-md">
    <caption>Selectable Table</caption>
    <thead>
      <tr>
        <th>first</th>
      </tr>
    </thead>
    <tbody>
      {exampleData.map(row => (
        <tr key={row}>
          <td>{row}</td>
        </tr>
      ))}
    </tbody>
  </table>
);

export default () => {
  const [data, setData] = React.useState([]);
  return (
    <React.Fragment>
      <Example exampleData={data} />
      <hr />
      <Alternative exampleData={data} />
      <hr />
      <div onClick={() => setData([...data, data.length])}>
        Add
      </div>
    </React.Fragment>
  );
};

There is the component Example that uses Table component. Rows and columns are stored in the component state - this is common pattern in a documentation. There is also a default component that pushes data to Example component. Data can change by clicking on Add. There is also a reference component Alternative, which gets the same data as the component Example. So there are two tables in the page.

When you click on Add then the first table Example stays unchanged whilst a new row is added to the second table Alternative. Either the following method must be added to Example:

static getDerivedStateFromProps(props) {
  return { rows: props.exampleData.map(i => [i]) };
}

Or rows must be built in render method according props. In this case, some extra state must be kept and merged into rows when the table is selectable or expandable. So an appropriate approach must be considered.

These details may not be obvious at first and documentation could help. But when I go through various details of the component Table (including those above), I can't resist an impression that something is not conceptually quite good in the Table component.

Rows is a complex variable that mixes state (selects, expands), components (see title in Compound Expandable table example), settings for inner components (colSpan), references (parent, compoundParent), transformers (compoundExpand) and maybe I missed something. One must learn about structure of rows, so building (and reading!) rows could be a complex task.

But what will be gained for this complexity? Is it worth it? What real benefits? I don't need to write inputs in Selectable table, I don't need write some tr, td, th and some of its attributes. Yes there are accessibility and other computed values. But these are trivial tasks and the explicit code is much easier to understand for the reader. Some accessibility values (e.g. <th scope="col"...) can be inside simple wrappers.

I can imagine that such component could be valuable in the project with jquery or other system. But with the react, it seems to me that I have to prepare the data in a special format for the component so that the component places the data where I could place it without problems and better (e.g. including keys see #1399). Why to use title (with component), transformers and formatters to instruct the component Table to create special cases instead of using standard react approach? Am I missing something important?

[karelhala]

When you click on Add then the first table Example stays unchanged whilst a new row is added to the second table Alternative. Either the following method must be added to Example:

static getDerivedStateFromProps(props) {
  return { rows: props.exampleData.map(i => [i]) };
}

Or rows must be built in render method according props. In this case, some extra state must be kept and merged into rows when the table is selectable or expandable. So an appropriate approach must be considered.

In the alternative exaple you are uilding rows in render method, you can actually do the same thing for Table component. About the selected/expanded you'd still have to keep it somehwere and you can buble this information up to parent one or keep it in state.

These details may not be obvious at first and documentation could help. But when I go through various details of the component Table (including those above), I can't resist an impression that something is not conceptually quite good in the Table component.

I dissagree with you Table component is big generic data driven component. There are various reasons (like sharing transformers, accessibility, changing table by updating settings - for instance static table to sortable table is a matter of one function and settings update) why react-tabular was chosen instead of writing simple components. Take for instance react-select [1], that is soewhat small component and you just have to adapt to the datashape as well. Same goes for charts and even forms these are big data driven components and you have to adapt to the object shape otherwise you'd have to write all interaction on your own.

Rows is a complex variable that mixes state (selects, expands),

This is deliberate every consumer wants to react on state updates differently (make a server call on each select or fetch data for collapsed rows when they expand).

components (see title in Compound Expandable table example),

Again this is deliberate, you want to have as much freedom as possible when using it. We can't limit consumers to only texts in cells. Otherwise that would be really hard to use.

settings for inner components (colSpan)

This is basically enhancement to your rows/cols you can write transformers instead of props but that would be even harder.

, references (parent, compoundParent),

Yes references are quite not ideal, we were playing with an idea of structured array. But that would be even harder to navigate trough so we decided to go with flat structure and using references.

transformers (compoundExpand)

I can't see any transform function in rows definition.

But what will be gained for this complexity? Is it worth it? What real benefits? I don't need to write inputs in Selectable table, I don't need write some tr, td, th and some of its attributes. Yes there are accessibility and other computed values.

You don't have to write logic for expandable or compound view. Sorting is done for you by passing one settings and one function.

But these are trivial tasks and the explicit code is much easier to understand for the reader. Some accessibility values (e.g. <th scope="col"...) can be inside simple wrappers.

I can imagine that such component could be valuable in the project with jquery or other system. But with the react, it seems to me that I have to prepare the data in a special format for the component so that the component places the data where I could place it without problems and better (e.g. including keys see #1399). Why to use title (with component), transformers and formatters to instruct the component Table to create special cases instead of using standard react approach? Am I missing something important?

I understand your concerns and yes big data driven components are no longer used in react because it is easier to use multiple small components instead of one big component and transform the data. But you have to understand that PF wants to deliver same user experience regardless where you use it and how you use it. With small components it would be really hard to supports all devices and have same accessibility in every project that uses it.

However i think that we are deviating from what this issue is about and started to argue what is better and such. So let's focus on the real problem here and that is the simple components, whether or not PF wants to support them, the easiest way would be to update components already used in Table to be more generic and export these components. Consumers could then decide if they want to use data driven provider Table or if they want to maintain all things and use generic components. I can see value in the small generic components if there is table that doesn't really need sorting, expanding and such. Just static table with no fancy functionality, but once you want to add some logic go with the data driven Table.

[1] https://github.com/JedWatson/react-select

[idevat]

My original intention was to show why I lack simple components. I apologize for moving to criticism of the component.

With transformers I did a mistake - they are in columns.

Yes, react-select can be understood as similar component. But I'm not sure if the variability of this components and Table is comparable. Anyway, I would prefer html API with select and options.

I can see value in the small generic components even if there is need sorting, expanding and such. For example, the following code shows creates something very similar to https://www.patternfly.org/v4/documentation/react/components/table/#compound-expandable-table. (It use the same simple components as in the first comment in this issue).

const AlternativeRow = ({ row }) => {
  const [expanded, setExpanded] = React.useState("");
  const toggle = (name) => () => setExpanded(expanded !== name ? name : "")
  return (
    <React.Fragment>
      <tr>
        <th><a href="#">{row.repository}</a></th>
        <PFCompoundExpansionToggle
          expanded={expanded==="branches"}
          onClick={toggle("branches")}
        >
          <CodeBranchIcon key="icon" />
          {row.branches}
        </PFCompoundExpansionToggle>
        <PFCompoundExpansionToggle
          expanded={expanded==="pullRequests"}
          onClick={toggle("pullRequests")}
        >
          <CodeIcon key="icon" />
          {row.pullRequests}
        </PFCompoundExpansionToggle>
        <PFCompoundExpansionToggle
          expanded={expanded==="workspaces"}
          onClick={toggle("workspaces")}
        >
          <CubeIcon key="icon" />
          {row.workspaces}
        </PFCompoundExpansionToggle>
        <td><a href="#">Open in Github</a></td>
      </tr>
      {expanded === "branches" && (
        <PFExpandableRow>
          <td colSpan={2}>Branches</td>
        </PFExpandableRow>
      )}
      {expanded === "pullRequests" && (
        <PFExpandableRow>
          <td colSpan={2}>PullRequests</td>
        </PFExpandableRow>
      )}
      {expanded === "workspaces" && (
        <PFExpandableRow>
          <td colSpan={2}>Workspaces</td>
        </PFExpandableRow>
      )}
    </React.Fragment>
  );
};

const Alternative = () => {
  const data = [
    {
      repository: "siemur/test-space",
      branches: 10,
      pullRequests: 4,
      workspaces: 4,
      lastCommit: "20 minutes",
    },
    {
      repository: "siemur/test-space2",
      branches: 3,
      pullRequests: 4,
      workspaces: 2,
      lastCommit: "20 minutes",
    },
  ];
  return (
    <PFTable>
      <thead>
        <tr>
          <th>Repositories</th>
          <th>Branches</th>
          <th>Pull requests</th>
          <th>Workspaces</th>
          <th>Last Commit</th>
          <th/>
        </tr>
      </thead>
      <tbody>
        {data.map(row => (
          <AlternativeRow row={row} key={row.repository} />
        ))}
      </tbody>
    </PFTable>
  );
};

Yes, some things are simplified there: no accessibility props, expanded content is simple string, etc. But the point is: there is an expansion logic and it can be easily done with simple components. Maybe, you must add more logic in an official example:

  onExpand(event, rowIndex, colIndex, isOpen, rowData, extraData) {
    const { rows } = this.state;
    if (!isOpen) {
      //set all other expanded cells false in this row if we are expanding
      rows[rowIndex].cells.forEach(cell => {
        if (cell.props) cell.props.isOpen = false;
      });
      rows[rowIndex].cells[colIndex].props.isOpen = true;
      rows[rowIndex].isOpen = true;
    } else {
      rows[rowIndex].cells[colIndex].props.isOpen = false;
      rows[rowIndex].isOpen = rows[rowIndex].cells.some(cell => cell.props && cell.props.isOpen);
    }
    this.setState({
      rows
    });
  }

I haven't tried it yet but even sorting won't require too complex logic, I guess. Beside sorting function you already mentioned you have to keep column, according to which it should be sorted, in the component state. Yes, in this case, the component Table could be more effective. But also with simple components it would be relatively easily doable.

And that is my point: small generic components don't have to be limited to static tables with no fancy functionality.

[priley86]

Sorry, was away for a bit. Here is my $.02 on this one...

Patternfly-table provides heavyweight component Table. This component tries to provide complex functionality to ease a development. But my experience with this component is a bit painful and I would welcome a set of simple composable components beside this super "smart" component. Let me elaborate it a bit.

Table is the fully featured export. It's quite light compared to some table libraries. You can also pick and choose ESM modules if you'd like to reconstruct it 😸. I think to be honest though, many teams would prefer to see more abstractions rather than less, but this is definitely a tradeoff you have to weigh. We have split out major additions inline-edit and virtualized extensions for this very reason.

When I looked into the code I found { title: 'Header cell', cellTransforms: [headerCol('selectable')] } but I have no idea what it should do (without more detailed study).

We can certainly improve the docs here. We've added additional utility transforms (like columnTransforms and headerCol that Reactabular does not add out-of-the-box). I think conversion to TSX in 1950 will also help with this, as well as making it more clear how one could consume these modules separately.

I can see value in the small generic components even if there is need sorting, expanding and such.

Agree completely, we can continue to break down the inner JSX of the formatters/decorators applied into smaller stateless components that could be reused elsewhere if desired...please feel free to attempt this!

Maybe, there are some use cases where the component Table is effective. But it would be great to have a set of simpler composable components for the rest of use cases.

To be honest, I think this introduces more maintenance burden (assuming we'd have to maintain more Table components). I'd rather break down the existing components further and make them reusable where possible.

When you click on Add then the first table Example stays unchanged whilst a new row is added to the second table Alternative. Either the following method must be added to Example:

static getDerivedStateFromProps(props) {
  return { rows: props.exampleData.map(i => [i]) };
}

By default we expose a similar "stateful" rows and columns API on the Table to mimic Reactabular. I think this is easier for folks to learn and apply. One could easily abstract this downstream to make it more robust (and introduce another stateless wrapper on top). This is exactly what we did in OpenShift:
https://github.com/openshift/console/blob/master/frontend/public/components/factory/table.tsx

There has been a lengthy discussion at the start of pf4 project about table library [1]. React tabular [2] has been chosen.

The link posted in [1] is about Super Mario @karelhala ? Maybe a typo... 😄
We droppped Reactabular dependency in 1628 and brought that source in house, making it easier to customize, expand upon, update, and convert to TypeScript. It's a very modular library making it good for applying PF principles, however it became dated and the author abandoned it. With as many specifications as PF places, I am definitely in the "keep the table source in house" camp. I see Reactabular as just a good set of examples and base utilities now that we can learn from and continue to improve upon.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.