[Feature Request]: From Scratch Refactor of DataTable

[naderalmogazy]

The problem

The DataTable Component is in a great working state, but highly confusing and lacking a level of intuitive use. I find it frustrating to import so many separate components to get the functionality I expect from one component.

The solution

I am proposing a new version that is a bit more opinionated, but much faster to set up and customize.

This component takes in an array of objects as its 'Data' and maps the data automatically, one object, one row.

In addition to the 'data' it takes a mapping of key's expected in those objects, to column labels, along with other useful things like what share of the width that column should take up.

Other functionality is built on top of that like row onClick handler, which expects to take a handler function, and passes the row clicked to that function on invocation.

Examples

Basic example:

Search Functionality:

Inline functions:

Dropdown options:

Dropdown expanded:

Application/PAL

App & Data Modernization

Business priority

Low Priority = release date is not dependent on fix or not upcoming

Available extra resources

Personal Repos where I use this component.

Code of Conduct

• [X] I agree to follow this project's Code of Conduct

[tay1orjones]

Thanks for suggesting this change! DataTable is challenging in that it must be highly flexible so that it can be repurposed for uses outside of the standard feature set provided through @carbon/react.

Many advanced use cases such as async loading/rendering must be supported in some way, and the established way to accomplish this is through React's composition features. This is why DataTable is broken up into so many individual pieces. With this setup, consuming teams and projects can opt to not use the default state manager in DataTable and instead rewrite their own entire custom state manager using the Table* components (like this example). With this approach, these teams and process have full control and still receive the benefit of standardized styling/handlers/etc. that comes with using components provided through Carbon.

As you mentioned though, the need for a simpler and more opinionated DataTable setup is a common one and as such many teams have established their own reusable components adjacent to ours that bear resemblance to what you're suggesting here. carbon-addons-iot-react has a StatefulTable that maps all data and functionality to props. @carbon/ibm-products has a DataGrid that does similar and provides a large collection of hooks to extend the default behavior set.

What we typically recommend in cases like yours is either to write your own wrapper around DataTable and reuse it across your projects, or leverage one of the other existing solutions. The DataGrid from @carbon/ibm-products is particularly active and has a working group surrounding it that we could connect you with if you're interested.

Overall I hope this helps to shed light on the reasoning for the way things are right now and why we won't be pursuing a refactor of this nature. Providing a simpler version of the DataTable like this would be at odds with the complex requirements we have across all the teams using and repurposing the existing DataTable.

If you'd like to discuss more how you might be able to leverage one of the libraries adjacent to ours or spin up a reusable component for use in your projects, just let me know.

[naderalmogazy]

My take on this refactor definitely sounds a lot like the carbon-addons-iot-react StatefulTable. It takes in a list of props. All the data and functions(fired by user events), are provided as input to the component. I hear that the current DataTable doesn't deal with state well, and that just sounds like all the more reason to go back to the drawing board.

It has most if not all the functionality I've seen from the current data table. And of course you could replenish any missing functionality over time.

I do see the benefits being significantly decreased learning curve, and significantly better state management. Not to say that the con's aren't there, I'm sure this being such a heavily collaborated work, my work is far less documented, and the accessibility level is probably lagging behind as well.

[sstrubberg]

Thanks for bringing this to our attention @naderalmogazy and I hope you got some good resources to work from. Closing this issue for now as Taylor pretty much covered our POV on DataTable. Have a good one!