[Table] Composable and simpler API

[alitaheri]

Regarding #2246. I'd say we should rewrite table, it's better not to use HTML table and instead do it all with div. This will give very flexible api and capability that would otherwise be impossible with table.

Right now there are tight couplings between Table and it's child components TableHeader, TableBody and TableFooter. There should be carefully designed props instead of wrapping the child components within divs and tables only to apply some styles and callbacks that can hurt composibility and customizability.

But I guess if we decide to do this we have to rewrite all the table components. Therefore, deprecation will be very hard.

Roadmap:

1. Keep the Table as it is for now.
2. Create new Table component set.
3. Deprecate the old components with a migration guide.
4. Remove the old Table components after some time.

New Components to be built:

• Table (how to disambiguate with the current table?)
  • Only a wrapper.
  • Passes dimension data, column sizes, etc. down the hierarchy via context.
  • Takes Header and Footer (or arrays of them?) as props not as children.
  • The children are the rows (that can be anything, not just TableRow).
• TableHeader (disambiguate!)
  • Can only accept TableCell
  • Flexible height?
• TableRow (disambiguate!)
  • Can only accept TableCell
  • Handles selection.
• TableCell
  • Can span multiple columns.

The sizes of columns will be passed down the hierarchy by the Table component. This information is something like this:

// the actual width of each column would be calculated like this:
// actualtWidthOfColumns[0] = (columns[0] / columns.sum() ) * tableWidth;
const columns = [5, 1, 1, 2, 2];
const tableWidth = 1000;

This means the first column will have the width of 500, the second 100 and so on.

With this, one can implement any feature around the table. Or even build it within the components. Features such as sorting, pagination, flexible columns, resizable columns, editable cells and so on. All these are possible right now, but with a lot of pain. Because the coupling is very tight. But with this things can become a lot easier for others to customize the table to their needs.

I'd love to hear everyone's thoughts on this. Or how it can be improved further.

[Dreculah]

How far along is this? Maybe I can help.

Since we're already using material-ui for a pretty ambitious project at my company, I'd rather use Table vs having to integrate/extend another react data table implementation.

The key features we need are cell editing/editors (e.g. components inside cells as editors on cell click) and support for hierarchical data.

We might be able to contribute some cycles to adding these features.

[newoga]

@Dreculah, this is in the ROADMAP and is definitely planned, but I don't believe any real work has been started with this. The core maintainers are mostly tied up with improving the code quality and stability rather than creating new components, so if you wanted to give this a stab, it'd be appreciated!

As @alitaheri mentioned in the description of the issue, we're likely going to pursue a component redesign for this rather than adding additional functionality to what is there. If you wanted to make a proposal/mock up an end user API for this, it'd be super appreciated. We can regroup after and decide what the next steps are.

Also,

The key features we need are cell editing/editors (e.g. components inside cells as editors on cell click) and support for hierarchical data.

That's awesome. That'd be really cool functionality for the project. 👍

[alitaheri]

@Dreculah I needed what you want. so I squeezed a TextField inside the table. And it's working great. It's a good workaround for now if it covers your use-case

[Dreculah]

I've cross posted to react-data-grid about this as well...

For hierarchical data, we need something like this: http://dev.sencha.com/deploy/ext-4.0.1/examples/tree/treegrid.html

Since the material-ui project wants to rewrite its table to give it the features already in react-data-grid. I wonder if react-data-grid code is compatible enough that it could be used/forked instead?

[ccomb]

Another grid example is http://griddlegriddle.github.io/Griddle/

[vmsoftware]

something like this would be great:
https://github.com/adazzle/react-data-grid

[zachguo]

I have been using Table for a while. IMO, this component is too overachieving, it doesn't need to carry so many features. Logics for those checkboxes should be handled by user outside of the component. Fixed footer should be deleted. Ideally, the Table should just be a simple <table> in material-design styles.

It doesn't need to handle interactions in table cells too, such input, dropdown or checkbox. Just offer several pre-styled dumb components like TableCellInput etc, so that user can plug them in if they want.

[nathanmarks]

@zachguo https://github.com/callemall/material-ui/blob/next/src/Table/Table.js

[nathanmarks]

By the way, for anyone looking for a data grid, it should be implemented differently than a table. I'd recommend using an existing data grid library and just applying material styling too it.

[zachguo]

@nathanmarks looking forward to 0.16.0

[nathanmarks]

@zachguo Me too 😄

[zakdances]

@nathanmarks What's the difference between a "data grid" and a table?

[frankbolviken]

@zakdances I guess data grid implies more advanced features like grouping, sorting, filtering, cell-editing etc. Table would be a more plain table to view data without the need for advanced functionality. At least thats how I would interpret these terms