An abstraction over table to provide a better component model for data tables
import React from 'react';
import Table from 'react-table-model';
export default function Basic() {
return (
<Table>
<Table.Head>
<Table.HeadRow>
<Table.HeadCell>Name</Table.HeadCell>
<Table.HeadCell>Allowance</Table.HeadCell>
</Table.HeadRow>
</Table.Head>
<Table.Body>
<Table.BodyRow>
<Table.BodyCell>Ed</Table.BodyCell>
<Table.BodyCell>$75.00</Table.BodyCell>
</Table.BodyRow>
<Table.BodyRow>
<Table.BodyCell>Matt</Table.BodyCell>
<Table.BodyCell>$100.00</Table.BodyCell>
</Table.BodyRow>
<Table.BodyRow>
<Table.BodyCell>Jeff</Table.BodyCell>
<Table.BodyCell>$125.00</Table.BodyCell>
</Table.BodyRow>
</Table.Body>
<Table.Foot>
<Table.FootRow>
<Table.FootCell>Total</Table.FootCell>
<Table.FootCell>$300.00</Table.FootCell>
</Table.FootRow>
</Table.Foot>
</Table>
);
}
The HTML table elements fall short in a couple of ways:
- Distinction between elements
- There's no distinction between the different kinds of
<tr>
tags - There's no distinction between a body
<td>
and a foot<td>
- You can control styling of these elements through CSS, but you cannot control behavior of the elements
- There's no distinction between the different kinds of
- Working with the native elements doesn't offer a means for applying standard behaviors
- For instance, if you want to apply
aria-
attributes in a standard way, you need a custom component - A custom component model affords opportunities to plug in site-wide extensions to the elements
- For instance, if you want to apply
Grid components tend to offer a high-level abstraction over the <table>
element and usually don't provide "escape hatches" where you can drop back down to markup for unsupported scenarios. That means at some point you'll hit a scenario the grid doesn't support and have to choose between three terrible options:
- Fail to support your scenario and ask your product owner or designer to compromise
- Fork the Grid component and add support for your scenario
- Forego the Grid component in that scenario
react-table-model is designed with the premise that you can always drop back down to raw markup and native HTML elements as needed.
Grid components tend to be quite heavy, with dozens of scenarios, to avoid the above from happening. That means even your simplest scenario that renders using a Grid has the pay the price for all of those features. There's rarely a "pay-for-play" model.
react-table-model offers a very lightweight abstraction over the HTML table, but it proves to be very composable and extensible. You opt into or compose any behavior you want to apply but basic scenarios never carry any more code than you need.
Grid components introduce new programming models that developers have to become familiar with. Have you ever worked on a project where you had to be trained on how to use the project's Grid? That's because of the high-level abstraction that is provided and it's an unnecessary burden.
react-table-model provides the same concept as an HTML table and arguably matches your mental model more closely than the native table does. There's a Table; it has a Head, Body, and Foot. Each of those has Rows and each Row has Cells. Everything beyond that is simply a means for applying standard behaviors while elimating duplicate code throughout your project.
Grid components tend to offer features for manipulating the data being rendered, such as:
- Data loading from APIs
- Sorting
- Paging
- Filtering
These concerns should all be kept separate from your View layer and instead should be handled in your state management layer, through redux for example. A well-factored application will not allow you to mix state management or data loading into your rendering components.
You can always build a fully-feature Grid component using react-table-model by extracting patterns and wrapping the components, but you can't take a Grid component and factor out the simple building blocks.
react-table-model gives you the building blocks you need to accomplish your scenarios, simple and complex. It makes the simple scenarios easy and the complex scenarios possible.