Table

[roblafeve]

Proposal

Tables can be a pain. Let's make it as quick and easy to spit out a simple table that handles sorting and selection.

AC

1. Any data can be mapped to a row
2. Can sorting by column
3. Can select by row
4. Does not support complicated tables

Interface Options

A - Render Children and Props

Pros:

1. Kind of looks like a table...

Cons:

1. We'll still have to pass configuration for header/footer to distinct props which will give this a weird shape
2. Need to pull in custom, or native table elements—you essentially still need to build a table
3. Kind of looks like a table—seems like a shallow module (bad)—doesn't hide much

<Table
  data={data}
  renderHeader={() => (...)}
  >
  {({ a, b, c, d }) => (
    <Tr>
      <Td>{a}</Td>
      <Td>{b}</Td>
      <Td>{c}</Td>
      <Td>{d}</Td>
    </Tr>
  )}
</Table>

B - Render Props

Pros:

1. Kind of looks like a table
2. All render props are passed as props—as opposed to using children

Cons:

1. Same as Option A

<Table
  data={data}
  renderHeader={() => (...)}
  renderRow={({ a, b, c, d }) => (
    <Tr>
      <Td>{a}</Td>
      <Td>{b}</Td>
      <Td>{c}</Td>
      <Td>{d}</Td>
    </Tr>
  )}
/>

C - Config-Based

Pros:

1. No knowledge of table structure is needed (deep module)
2. Column headers and table data values are define once—instead of potentially defining them separately—and potentially mismatching them.

Cons:

1. Lose FULL control—but that's the point. This is the starting point for a useful abstraction that the user could augment to fit their needs.

<Table
  data={data}
  columns={[
    { label: null }, // maybe we need a gap 🤷‍♂️
    { label: "A", getValue: (user) => user.a, sortable: true },
    { label: "B", getValue: (user) => user.b },
    { label: "C", getValue: (user) => user.c.toString() },
    { label: "D", getValue: (user) => user.d.e },
  ]}
/>

I might convert columns to a single function that has "datum" passed to it

[roblafeve]

I'd love your thoughts on these potential interfaces for a Table component ☝️🙏

cc @belv2c @luiz-chagas @albatrocity @thispastwinter

[thispastwinter]

I prefer option C as I as the developer don't have to worry about the implementation. Might be a little more annoying as we'd need to supply some styling props but I prefer the convenience of that abstraction over having to pass in my own table. These are just my initial thoughts. I may stew over this further and have some follow up thoughts.

[luiz-chagas]

Option C seems to give the best developer experience.

A table might evolve to have many other features (filtering, pagination, count, footer, etc) but this is a good starting point.

[roblafeve]

I prefer option C as I as the developer don't have to worry about the implementation

@thispastwinter thanks for the feedback!

A table might evolve to have many other features (filtering, pagination, count, footer, etc) but this is a good starting point.

@luiz-chagas Ooooh yes... and I think we can accomodate those in a usable way if we keep the interface simple. Again, I think the current use case is that you are wanting to create a single table abstraction for your app. You very well may need to edit the source code to make it fit your needs exactly. I think that's okay within our current approach.

Once a good pattern has been established for the primary use case, I think you can give the user reasonable back doors for customization.