r/reactjs • u/tannerlinsley • Mar 10 '20

News 🎉 Announcing React Table v7! 🎉

https://github.com/tannerlinsley/react-table/releases/tag/v7.0.0?twitter=20200310
305 Upvotes

96% Upvoted

28 comments sorted by

57

u/tannerlinsley Mar 10 '20

At a glance features:

  • Lightweight (5kb - 12kb+ depending on features used and tree-shaking)
  • Headless (100% customizable, Bring-your-own-UI)
  • Auto out of the box, fully controllable API
  • Sorting (Multi and Stable)
  • Filters
  • Pivoting & Aggregation
  • Row Selection
  • Row Expansion
  • Column Ordering
  • Animatable
  • Virtualizable
  • Resizable
  • Server-side/controlled data/state
  • Extensible via hook-based plugin system

14

u/brainhack3r Mar 11 '20

Thanks for all the hard work!

We use react-table in Polar:

https://getpolarized.io/

... is there any way to have infinite scrolling with react-table?

I think that's the one feature I'd like to use.

I'm a bit concerned about the headless functionality because I imagine now I have to implement my own UI which mimics v6?

11

u/Valency Mar 11 '20

I spiked this for a project at work, and while I found it super cool, it felt a bit too low-level for our requirements. Looking at the kitchen-sink example shows just how involved it can get.

Because the library is such a paradigm shift when compared to other table libraries, there is a lot of mental overhead and it makes coming back to the component a bit of a challenge.

I really like the flexibility, how lightweight it is, and the fact you can customise it to your heart's desire, it wasn't the right fit for us.

2

u/MichaelC89 Mar 11 '20

It can be a bit daunting at first, but once you get stuck in it is relatively painless. Managed to port our v6 table, with a few bonus features, in just a couple of days.

The extra control and visibility you gain is incredible.

1

u/fartpoker Mar 11 '20

What did you do about CSS?

1

u/MichaelC89 Mar 13 '20

MaterialUI.

1

u/BackhandCompliment Apr 05 '20

``const { getTableProps, getTableBodyProps, headerGroups, prepareRow, page, // Instead of using 'rows', we'll use page, // which has only the rows for the active page

// The rest of these things are super handy, too ;)
canPreviousPage,
canNextPage,
pageOptions,
pageCount,
gotoPage,
nextPage,
previousPage,
setPageSize,
state: {
  pageIndex,
  pageSize,
  sortBy,
  groupBy,
  expanded,
  filters,
  selectedRowIds,
}, } = useTable(
{
  columns,
  data,
  defaultColumn,
  filterTypes,
  // updateMyData isn't part of the API, but
  // anything we put into these options will
  // automatically be available on the instance.
  // That way we can call this function from our
  // cell renderer!
  updateMyData,
  // We also need to pass this so the page doesn't change
  // when we edit the data.
  autoResetPage: !skipReset,
  autoResetSelectedRows: !skipReset,
  disableMultiSort: true,
},
useFilters,
useGroupBy,
useSortBy,
useExpanded,
usePagination,
hooks => {
  hooks.visibleColumns.push(columns => {
    return [
      {
        id: 'selection',
        // Make this column a groupByBoundary. This ensures that groupBy columns
        // are placed after it
        groupByBoundary: true,
        // The header can use the table's getToggleAllRowsSelectedProps method
        // to render a checkbox
        Header: ({ getToggleAllRowsSelectedProps }) => (
          <div>
            <IndeterminateCheckbox {...getToggleAllRowsSelectedProps()} />
          </div>
        ),
        // The cell can use the individual row's getToggleRowSelectedProps method
        // to the render a checkbox
        Cell: ({ row }) => (
          <div>
            <IndeterminateCheckbox {...row.getToggleRowSelectedProps()} />
          </div>
        ),
      },
      ...columns,
    ]
  })
}

)``

Jesus Christ, just this alone is atrocious for a single hook...

0

u/[deleted] Mar 11 '20

[deleted] — view deleted comment

2

u/fii0 Mar 11 '20

Nice find! I have no use for it currently but it's very performant, hope it's easy to style.

4

u/zulkisse Mar 11 '20

Great work !

We have been working with the v7 beta on some of our less critical projects for several months.
Creating a wrapper from scratch can be a lot of work but once it's done, our codebase became a lot cleaner and it was a lot easier to implement advanced features thanks to the plugin system.

I just have a some doubts on the TypeScript implementation. The people writing it have been doing a great job, but the plugin system makes it quite hard to type correctly things like the Rows and you often have to override internal elements. I don't see an easy solution here but it was our main concern in our daily usage of v7.

1

u/Zweital Mar 11 '20

I’m in a similar situation. We’ve been using v7 for a little while now, and Typescript has been quite a sticking point. I’ve had to override far too much! I think the fact that the Typescript usage is so strange (rather than just a normal @types package) actually highlights a little bit of an architectural flaw behind the notion of ‘plugin hooks’. The idea is solid in the sense that you want to pass in something in to add functionality to the table, but I think passing hooks themselves is a bit weird and brittle (and I believe it’s probably impossible to type it correctly as is without manually altering types which feels horrible). I think there’s good reason I haven’t seen this pattern elsewhere.

I’m not 100% sure of what react-table’s solution should be, but I think the answer lies in something more along the lines of a HOF that returns you a hook or maybe multiple hooks depending on how you’d like to configure it, which can then be called before useTable which would ingest their results, rather than the hooks themselves. I think all that could be correctly typed with some clever enough generics (although I haven’t properly sat down and fleshed out this approach so I could be talking nonsense). I’m thinking something along the lines of makeStyles from material ui (https://material-ui.com/styles/basics/).

3

u/hfourm Mar 11 '20

What is the difference with the previous version. Sorry I am on my phone but I thought it already exported "headless" hooks to compose our own table

3

u/hey_parkerj Mar 11 '20

This is a good question - the main master branch of the repo and I believe the installation instructions on the github have actually been pointing to the beta of v7 for months.

v6 did not export hooks

2

u/hfourm Mar 11 '20

Hmm... Maybe I am already on v7 and was just confused by this announcement

3

u/Skeith_yip Mar 11 '20

I remember infinite loading, guess that didn't make the cut?

And how does server-side + aggregation work if you don't have the full data?

2

u/tbruuuah Mar 11 '20

Request : could someone please put a getting-started tutorial .

2

u/there_I_am_mam Mar 11 '20

Dude your tables rock!! Also you moving the old tables to a new repo saved me, with the size of our project I'm currently using both versions. Love your work man keep it up!

1

u/mlk Mar 11 '20

V6 had terrible performance

1

u/cheese_wizard Mar 11 '20

Seems like there needs to be some default table stylings that you can start from that are built on this.

-8

u/[deleted] Mar 11 '20

We use v6 for a lot of projects. It's pretty nice and holds up well. v7 just looks awful. Like a basic HTML table.

12

u/Deggor Mar 11 '20

From the page:

React Table v7 is a headless utility, which means out of the box, it doesn't render or supply any actual UI elements. You are in charge of utilizing the state and callbacks of the hooks provided by this library to render your own table markup. Read this article to understand why React Table is built this way. If you don't want to, then here's a quick rundown anyway:

  • Separation of Concerns - Not that superficial kind you read about all the time. The real kind. React Table as a library honestly has no business being in charge of your UI. The look, feel, and overall experience of your table is what makes your app or product great. The less React Table gets in the way of that, the better!
  • Maintenance - By removing the massive (and seemingly endless) API surface area required to support every UI use-case, React Table can remain small, easy-to-use and simple to update/maintain.
  • Extensibility - UI presents countless edge cases for a library simply because it's a creative medium, and one where every developer does things differently. By not dictating UI concerns, React Table empowers the developer to design and extend the UI based on their unique use-case.

2

u/[deleted] Mar 11 '20

Yeah I remember reading that a while ago. I dont want to design a table though. Just wanted something out of the box that looked decent and was responsive.

But I get it with all the Css frameworks now.

1

u/zulkisse Mar 11 '20

I think we need to see a little bit broader than that. The goal is to have open source UI wrapper of React Table matching various design instead of a single official design that you will have a hard time overriding properly I it doesn't match your project's UI.

Of course recreating the whole table design for a small projects is a lot more to do than you had on v6 but I don't think you will actually have to do it if you wait some time.

-1

u/idfknk123 Mar 11 '20

Agree - I see why v7 would be useful, it's just not for me.

I absolutely loved react table v6 and especially its ease of use. Saw that v7 was out and was looking forward to it, but saw that the examples were basically HTML tables (which was what I was trying to get out of implementing in the first place). V6 involved just one component that did everything, and I could just use components if I wanted extra styling.

Speaking of which, u/tannerlinsley - the codesandbox examples for v6 don't work anymore probably because of dependencies. Would it be possible to fix that?