@jtomasek I like the flexibility here and the use of the render prop pattern (used it also in Wizard). It seems to work well in Data Tables.

I also like that you are starting simple. Look forward to your additional progress and let us know when you want more review...

I've found a nice react library for datatables, that supports client & server pagination, sorting, filters etc.
You can also try it via storybook.

I've found a nice react library for datatables, that supports client & server pagination, sorting, filters etc.

That's cool. And it supports row selection which is a requirement for us before we can use this.

I do, however, prefer @jtomasek's approach on the columns versus the react-table implementation.

    <DataTable rowGetter={key => items[key]} rowKeys={Object.keys(items)}>
      <Column label="Title" dataKey="title" />
      <Column label="Description" dataKey="description" />
    </DataTable>

versus

  const columns = [{
    Header: 'Name',
    accessor: 'name' // String-based value accessors!
  }, {
    Header: 'Age',
    accessor: 'age',
    Cell: props => <span className='number'>{props.value}</span> // Custom cell components!
  }, {
    id: 'friendName', // Required because our accessor is not a string
    Header: 'Friend Name',
    accessor: d => d.friend.name // Custom value accessors!
  }, {
    Header: props => <span>Friend Age</span>, // Custom header components!
    accessor: 'friend.age'
  }]

  <ReactTable
    data={data}
    columns={columns}
  />

I like @jtomasek's approach because it allows for easier customization of the columns themselves (adding additional classes, etc.).

I tend to agree w/ @waldenraines comments above. Current PatternFly design is quite specific to the subset of features used in DataTables.net with some customized PF pagination styles.

My guess is that we can self implement most of these features quite well (and even achieve accessibility standards) as a community, and write a much more flexible React API for this design (assuming we want to keep this design). There will always be other use cases and fancy UX usages of tables, and my guess is those should be left out of PF React and up to the individual consumer on how best to handle. Ideally we can provide a core set of features in PF React that best serves most intended use cases, and ensure that those common APIs are easy for the consumer (sort/filter/page/etc.). We can always progressively enhance this list as a community and ensure flexibility as we go...

I would say this to be the case on most of our patterns in PF today, excluding charts, date picker, and possibly tree view (which it seems we could probably find more adequate React implementations in the upstream communities).

Another thing to note - we probably have one of the most knowledgeable in the community on tree view w/ @skateman at RH. I'm fairly certain he could write a tree view in React if we challenged him on this 😸

How urgent is this @priley86? We have a student writing his thesis about a tree component and the practical part is to have multiple componentized implementations. ETA is next spring, but if that's too late you could go with something similar to this, i.e. a lightweight wrapper around the original treeview code.

@priley86 the main drawback of writing it ourselve is that it can get fairly complex quickly - I do like the fact that react-table comes with client and server side support for pagination, sorting etc.

I agree that the API is nicer, but we can use a custom header, cell etc - have a look at https://github.com/react-tools/react-table#custom-cell-header-and-footer-rendering

agreed @ohadlevy - that is the danger with self implementing. As long as the API is flexible enough to support our use case, I do not have problem at all. This seems to indicate that...

@ohadlevy I would also be okay with using react-table and wrapping it with our own components to create a similar API as @jtomasek defined above.

i've opened a new issue about this in #107

@jtomasek I think we can close this in favor of #143 soon...

reactabular-table is actually quite lightweight (under 20kb min/gzipped) and would be the only dependency needed to build a simple table such as this. I am in favor of using that simple/extendable API and being consistent with our Table APIs vs. introducing another Table just for basic table. thoughts?

I guess this could mean we just expose a single Table instead of DataTable and Table (we could of course visualize them in different stories, but I am in favor of the shared abstraction for customization reasons). I will leave this up to further discussion though...

closing this in favor of #143

i think we can explore a lot of the other data table features mentioned here in the future (integrated HOC datatable with toolbar filters / empty state, column reordering, react-virtualized for infinite scroll, tables with treeview / drag/drop treeview etc.)

thanks again @jtomasek for starting this discussion and if you'd like to try those features some time feel free 😸 . I think we can break those features down into subsequent issues as they are needed but for now we are tracking them in #107