Data table library for PF4

[LHinson]

This issue to work with @mcarrano about the direction for PF4 data table view and the required features and functionality. Design work is currently being tracked here: patternfly/patternfly#199

Questions to answer:

• Will we continue to use what seen in PF React today? If not, what are alternatives?
• Is there any customization required to achieve desired features and functionality?

[karelhala]

I love the new design of tables! It looks really interesting and easy to use.

As of the implementation I don't really like the idea of relying on other packages let alone on reactabular, it's fairly old and given the design it would be really hard to use and work with it.

For simple tables there is often used package called react-table, I would recommend it to be used for simple tables, header with sort and static pagination. However I don't think there is any package complex enough to cover our needs for custom rows which could be draggable, editable, sortable and collapsible. So I suggest writing our own implemtnation, I know that it might sound scary, but sorting, pagination and filter is rather easy because of ES6 functions. Drag and drop can be achieved with react-dnd, rendering custom rows/cells (including collapsible elements) is easy thanks to react (just pass HTML elements into body of PF table), inline edit can be achieved easy enough with react as well.

[priley86]

@karelhala thanks for the feedback...having worked on this a bit in the past, here is my thoughts...

I think we are essentially comparing two very similar APIs for building tables w/ React. I find the reactabular implementation quite simple to modify and fully featured. I do tend to agree that more HOCs could be provided to make the reactabular API easier on the consumer (still a TODO item), but it is quite flexible and can handle almost all use cases when packages are combined (and it is completely extendable).

With react-table, you are getting a lot of additional things out of the box I feel (vs independently loading table features w/ separate packages/modules). While its API may seem easier to consume, for PF concerns, I think you will end up overriding virtually everything. The HTML markup it renders in all of the examples is not semantic (div vs table th tr.. missing aria attributes, etc), custom css, etc. so in the end, I think you'll just end up completely customizing and reimplementing on top of that to meet PF guidelines...

For that reason, I still believe reactabular is a better choice for PF (you'll write smaller extensions on top of smaller independent packages). You mention wanting to write a lot of custom features, well reactabular is just a modular guide to doing that...I would almost be more inclined to just write a completely custom implementation then.

I'm definitely curious what other community members think, but that is my $.02 on this one. I am happy to help write more HOCs if it makes table consumption easier...

[LHinson]

Just wanted to give you the heads up of continued conversation over in the core repo - patternfly/patternfly#199

[LHinson]

@karelhala does this address your concerns? As FYI, @mnolting is going to start on basic table styling over in core. patternfly/patternfly#513

We've had success with reactabular with PF3, therefore would like to move forward with this solution for PF4 as well however, wanted to loop back around with you as well given you initial concern.

[karelhala]

@LHinson thanks for opening this discussion. My concerns are still same as before, that I don't think that we really need any library to handle tables, let alone such complicated one as Reactabular is. But that is my personal feeling.

I'm fine with using such library it just feels too complex for such a small thing as tables are, on the other hand using this library could help us to combine multiple decorators and that would be really benefitial. For instance we can add collapsible tables + editable + sortable + drag and drop which would be really hard with plain tables.

As i said before I created table in react without this library because it was much faster at that time and we wouldn't have to think about multiple variants of each cell. But patternfly is not just for convenient sollutions but it should address some more specific and more complex use cases as well so I understand the need for this library. If you want I can start the effort on writing table using this library and meantime anybody at insights project can continue using the older implementation of tables I'll try to be as consistent with the API as possible and should any changes arise I'll try to keep them down and help others to move from older implementation to newer one.

But this issue could stay opened so other members of community can state their concenrs and such.