
React Table is a “headless” UI library - cwackerfuss
https://github.com/tannerlinsley/react-table/blob/master/docs/concepts.md
======
euoia
Every few months I look at the state of table libraries on the web. Of course,
it's great to have pagination, sorting, searching - these are the basics.

I have been impressed with jQuery DataTables. jQuery DataTables has a lot of
features, including export to Excel. jQuery DataTables works with Vue without
any issues so long as you never mutate the table data. Mutating table data in
Vue can be accommodated, but requires watching for data changes in Vue and
making calls to the DataTables API.

I have a few questions about this library. Can it detect rows being clicked on
(and emit an event, for example)? Can the searching be customized (I may want
to display numbers in a locale-specific format, but match even when the search
doesn't include the formatting)? Can sorting be customized (I may wish to the
sorting for a field to depend on another, possibly hidden, field)?

What do people use in Vue-land for tables? Is there anything that approaches
the feature set of jQuery DataTables?

~~~
justaguyhere
If you are impressed by datatables, you should check out Ag-Grid. It is much,
much more powerful than datatables. The only negative thing about ag-grid is
its price, otherwise it is a pleasure to work with.

I am not affiliated with them, just a very happy customer

~~~
slaymaker1907
Holy crap, just checked out their pricing and it is $750 per developer (for
enterprise edition)! That is more expensive than JetBrains all products, $649.

~~~
justaguyhere
Yes, it is expensive. Not just 750, you also have to pay another 750 for
deployment license per production environment. And it is 1200 if your devs are
working on more than one project.

That said, I'd argue it is still worth it, assuming you can afford it. It will
save you tons of developer time down the road. Their documentation is top
notch too.

For example, it has graphs built in! I have never seen any grid library do
that.

Again, not affiliated with them in any shape or form, just a happy customer
(trying to get a discount from them though, ha!)

------
georgewfraser
I spent a ridiculous amount of time working on optimized table rendering in
the early years of my company, and I came to a simple conclusion: if you want
to display full-screen tables, with dense data, and scroll around fast, the
only option is canvas. "Virtualized" HTML tables are always an order-of-
magnitude slower, no matter how much effort you put into optimization.

The fundamental reason why you end up back at canvas is that if you are
scrolling a full-screen table fast, even at 30 FPS you are going to have to
rerender about half the table on each frame. So "virtualized DOM" doesn't
really work; it's all about render speed. And canvas allows you to achieve
unbeatable render speeds by specializing your drawing algorithm for your
particular scenario.

~~~
tannerlinsley
I'm terribly sorry that you ended up in Canvas land for tables. I built and
maintained Chart.js for a while, so I know how hard it can be to work with.

As for React Table, I have never run into a situation where drawing a table to
canvas has ever been necessary. I guess I'll consider myself lucky, but I
would still love to hear your use-case in a more structured format. Maybe a
blog post?

~~~
nojvek
I’ve spent a crazy amount of time at my workplace optimizing the shit out of
tables.

Canvas is great, you could even get extra oomph with webgl but those break
basic things. You have to spend a lot of time recreating basic things like
copy paste.

Dom virtualization gets you pretty fast and very usable tables. 30FPS
rendering is quite doable with react and friends. Just gotta ensure the layout
paint/cycles are small and you’re compositing as much with the GPU.

Like using translate3d instead of using scrollTop

Basically we need a middle ground primitive, something higher than canvas that
still allows drawing text real fast but still has copy paste and usual
accessibility features but low level enough to be insanely fast.

------
outsidetheparty
I'm very curious how do people feel about the "headless component" UI
strategy? First came across the concept at a conference recently -- React
Table was one of the key examples the speaker gave, in fact -- and I find the
idea intriguing, but I'm not quite sure yet whether I want to subscribe to the
newsletter.

Is it a useful way to separate look-and-feel concerns from functional
concerns, or is it just another layer of indirection?

~~~
johnsoft
I'm a fan. It's so refreshing to have all the HTML and CSS in your own
codebase, under your control, instead of reading through a list of 50
sparsely-documented props only to realize that none of them quite do what you
need.

Another example of this pattern is `downshift`, which is a headless
autocomplete library: [https://github.com/downshift-
js/downshift](https://github.com/downshift-js/downshift)

I would love to see a datepicker component that used this design. I have some
choice words for the various datepicker libs I've used over my career and none
of them are friendly.

------
grumblestumble
I think the team behind this is somewhat trivializing this change by saying
that a UI table library "has no business being in charge of your UI". Is the
expectation is that the following are all bespoke, easy-to-implement features
that application teams should rewrite from scratch and maintain internally,
and should not be considered when looking at a library to deal with rendering
tabular data in an application?

* Support for virtualized rows/columns * Support for fixed headers * Support for frozen columns * Support for resizable columns * Support for re-ordering columns * Dealing with page / container resizing. * Support for context menus in the context of all of the above * Support for master/detail views * Support for tree data

My take is that the inverse is true. Structure/Pagination/sorting/filtering of
data sets is pretty trivial and in most cases the out-of-the-box functionality
that libs provide for these is insufficient and ends up being overwritten
anyway. The above list is exactly what I'm looking to outsource when looking
at a grid library.

~~~
tannerlinsley
By team, I think you mean me. I'm flattered! :)

Being a headless UI library doesn't necessarily mean that it has no business
being in charge of your UI, it's more about the way that you interact with the
API. If you look closely at React Table, it absolutely does take charge of
your UI via prop-getters and inversion-of-control integrated into your table
markup.

There are plenty of table libraries that do exactly what you are referring to
by handling the things you want to "outsource" pertaining to UI-specific
features. Ag-Grid comes to mind here, which is a fantastic library and might
do what you're looking for. However, the main takeaway here is that markup-
bound APIs that are designed to be totally "in charge of your UI" may not
always get out of the way when you need them to. Take it from a maintainer who
has seen hundreds and hundreds of "issues" and "feature requests" that
essentially amount to "how can I take back control of the [markup, styles,
scrolling, pagination, resizing magic, frozen columns, etc]".

It's true that there is a bit more work involved in managing this on your own,
but you're not really on your own after all. Fostering a good community of
examples and resources around a low-level library like React Table v7 relieves
most of that pain and you'll find that the amount of work to build and control
your own table markup and styles is not only easy, but liberating.

Also, I don't really think it's fair to generalize
structure/pagination/sorting/filtering as trivial tasks. Conceptually they are
all very simple, for sure. But, marrying all of these features together in a
way that is extremely performant across all of the many flexible permutations
of features is very difficult. Ask any table library author and they will
likely tell you that those 4 seemingly simple tasks are the ones that
complicate everything else by a magnitude of difficulty.

Thanks for your feedback!

~~~
james_s_tayler
I totally agree with the myriad of "last mile" issues teams face when using
component libraries with opionated, pre-baked UI.

I think the magic could really come when you have full headless component
libraries and full sets of libraries that skin them. You can always roll your
own skin. But that's better than having to roll your own entire component
library just to get around last-mile issues.

We are slowly but surely working towards higher and higher levels of code
reusability at all levels of the stack. Reusable UI is massively important to
productivity.

------
burtonator
I've been using react-table in Polar since the beginning and it's a great
library.

We're using it in the document and annotation views and it provides
pagination, sorting, etc.

I'm a bit nervous about this 7.0 release _not_ providing a basic table UI as
that was one of the wins for us migrating.

For example, here's a screenshot of the document repository:

[https://getpolarized.io/#document-
repository](https://getpolarized.io/#document-repository)

... which is sort of the main view. React table allows you to sort by
progress, creation time, update time, etc.

We used the same react table code to build the annotation viewer:

[https://getpolarized.io/#annotation-
viewer](https://getpolarized.io/#annotation-viewer)

One big issue we had was with context menus and selecting multiple items.

This doesn't come out of the box (of course) but I think platform-consistent
multi-select is important so we had to implement all that functionality.

We're still a way from a more clear cut API for managing this stuff on the web
+ desktop + mobile.

I REALLY wish I could have web technology transparently work on mobile!

~~~
tannerlinsley
That's awesome! Soo cool to see it in your product! About being nervous, I
don't think you should be! I know it's intimidating moving to v7 from v6, but
it's pretty simple given the examples that we have in the repo thus far. If
you still are getting the jitters, then DM me on Twitter! I would love to work
something out to help you feel better about it. I offer sponsorships for
prioritized support and even private consultation if needed. Don't be shy,
just reach out!

------
scarejunba
I see. It's the backing data and state handling plus hooks (in the normal
sense rather than React sense) to allow you to draw your own table. Very
interesting.

Naturally, I imagine someone will make basic-react-table or something so you
don't have to write the code to render the table. I appreciate that the
bottom-most level of libraries is this customizable but frequently I don't
want to draw all that code.

Still, perhaps the right place for that code is examples rather than a
library. Hmm.

~~~
acemarke
And on that note, Tanner has put together a bunch of example CodeSandboxes for
the various features [0] . For our own app, I basically copied most of the
default rendering logic from those, applied styles to match the rest of our
app, and we've been adding some additional APIs to the grid from there to suit
our needs.

[0] [https://github.com/tannerlinsley/react-
table/blob/master/doc...](https://github.com/tannerlinsley/react-
table/blob/master/docs/examples.md)

~~~
tannerlinsley
This is how I envisioned things from the beginning. Some people may want a
quick drop-in library, since that's what they're used to, but in reality,
copying and pasting an example into a `component/Table.js` file is essentially
the same thing. The only thing it's missing is styles, which are implemented
so differently these days, it's almost impossible to ship standard table
styles without compromising the majority of users in some way.

I'm happy with the low-level + examples approach.

~~~
acemarke
I did see someone suggest that maybe R-T v7 should ship with a component that
implements the v6 API on top of the v7 implementation, but that would add a
noticeable amount of overhead to the API and I'm not sure how much benefit
there would be.

~~~
tannerlinsley
I've toyed with that idea for a long time now. I go back and forth, but as of
today, I don't feel like that would do much good with the success I've seen
people having with the examples. Sure, v6 was popular because it was very AG-
grid like and included everything you could ever want and just dropped right
in. But IMO, that led to most of its long-term and difficult problems, mainly
issues around "How do I style this", "How can I rearrange this", "How can I
extend it to do this". I find it much easier to show people how to make their
own table component in an 80 line example, then extend it in userland to fit
their needs.

I'm always open to the idea though.

------
iddan
Pairs great with React Spreadsheet [https://iddan.github.io/react-
spreadsheet/](https://iddan.github.io/react-spreadsheet/)

~~~
jsd1982
I just tried `A1: 1`, `B1: =A1`, `C1: =B1*5` and the C formula failed as
`#VALUE`. It seems to only work if there is no nesting of cell references in
formulae.

------
quink
I have put together the Material-UI Table component and react-table v7 for a
project. Apart from the Typescript for v7 being a bit insufficient (but easy
to work around it, and possibly fixed by now), it was an absolutely pleasant
experience.

It’s almost like react-table v7 and {insert UI component library here} are
made for each other and it’s incredibly valuable, more so than the previous
react-table.

Absolute kudos to the developer and I look forward to UI component libraries
writing their table display components to target the semantics of react-table
v7.

This has some real potential for any UI library to get first-class table
functionality without sweating and needlessly repeating the implementation
details.

~~~
tannerlinsley
The force is strong with this one!

Thanks!

------
proc0
Hmmm this isn't srictly true. It's a React library after all, and React is the
rendering "engine" here. Even their description says: "Hooks for building
lightweight, fast and extendable datagrids for React". Therefore React is
taking care of rendering. I think what they really mean by "It doesn't render
it for you" is that you have to implement the rendering functions for the
Table, which is more just like providing a UI plugin that has no "default"
(but I'm even assuming React Table does have a simple default, so it's
basically just an extensible UI plugin).

~~~
tannerlinsley
Yep! You're getting it now! Take a look at the examples and see just how easy
it is to spin up your own table with React Table :)

------
latortuga
Have used React Table in production and it's a great, reliable library. Thanks
Tanner!

~~~
tannerlinsley
Thanks! Be sure to get your company to sponsor me on Github if you can!

------
simion314
is there a library that can render a lot of data as performant as native GUIs
tabes/data-grids . In my experience just loading 1000 items at once it hangs
in the browser native dom lay outing code, a good implementation won't create
a GUI widget of each item but only for the visible ones and some buffer ones
to have faster scrolling. Pagination and loading as you scroll is a hack, an
example scenario would be like you would want to create a simple CSV editor
and you want to load 1000+ rows , have sort-able, hide-able , rearangeble
columns (with a decent toolkit you would just drop a DataGrid component and
set the data provider

~~~
onion2k
_Pagination and loading as you scroll is a hack.._

I've written software using virtual lists in languages from VB6 to React.
They're not a hack; they've been a staple of UI libraries for decades.

~~~
simion314
I am sorry but it is a hack, if I can fit that 1000 rows of CSV in a few KBs
of memory and and Array of 1000 objects is fast to manipulate paginating the
UI layer because the UI is slow is a necessary workaround not something you do
because of UX.

Your text editor is not painting all the text in a large file , how would you
feel if you had to display a large file in an html view you had to paginate it
and do all the work that the textarea should have done by itself.

~~~
pault
I have the same scrolling issues on large, complex Excel spreadsheets. Every
environment is going to hit a wall at some point when the UI is forced to
display a certain amount of data.

~~~
simion314
I understand that some application are not optimized, a good GUI widget would
render only the visible part and a buffer , the fact that we don't have such
good library or even beter native component in HTML is sad , especially that
people are making desktop apps with electron. What is more sad is trying to
excuse this with some fake ideas that pagination and bad implemented infinity
scrolling is superior to optimized GUIs.

Just in case I am not clear. Say you have an Array with 10k image thumbnail
urls and you want to show them in a Grid, this Array fits in memory so
paginating using network request is stupid and makes things slow. So if all
images urls are in memory you can create 10k IMG elemetns because the DOM is
slow(especially if you have some DIvs and spans to wrape elements around,
center some img name , maybe a button or menu). So if on my screen I can fit
15 items , I could create 30 img elements and as you scroll you would move the
UI items that are no longer visible at the bottom and change the attributes
like src, name etc. This is not simple and decent toolkits do this for you by
default similar how a text editor can load a large file fast because is not
painting all of the file text.

~~~
pault
Oh I see, yeah that's pretty much the default way to render large lists in a
SPA (the term of art is called windowing). React-window is really well
designed[0]. It is a shame that there is no native HTML element for this
though.

[0] [https://github.com/bvaughn/react-
window](https://github.com/bvaughn/react-window)

------
addicted44
The "headless" UI concepts promoted at this website feel to me like an attempt
to shoehorn separation of templates and business logic which React has
strongly resisted.

Any thoughts on whether this impression is right or wrong?

~~~
tannerlinsley
I would say the "separation of concern" you're referring to is typically
centered around (and definitely grew out of) the idea that styles, logic and
markup should be in separate files or logical systems (html, css, js). The
react ecosystem doesn't preach or empower this, and since React Table is built
on that React, it also does not.

Hooks are a proper interface for _modularization_ of logic, in the same way
that components modularize markup (and potentially styles, eg css-in-js).

Since React Table v7 is just a collection of hooks, it is no more an attempt
at separation of concerns than the core React hooks are.

In similarity, it is merely a utility that encapsulates configuration, state
and side-effects into a modular unit that can be used to build your UI. Sounds
exactly like React if you ask me.

------
sbilstein
Formik does this for forms. It’s great.

~~~
tannerlinsley
So does React-Form ;) [https://github.com/tannerlinsley/react-
form](https://github.com/tannerlinsley/react-form)

------
dimgl
I was actually building this exact thing many years ago. In hindsight I
probably should have made it into React Table.

[https://github.com/divmgl/tabled.js](https://github.com/divmgl/tabled.js)

~~~
lioeters
From skimming through, the library looks good! It's "generic" in the best
sense of the term, agnostic of React, Vue, etc.

~~~
dimgl
Thanks. Maybe I'll pick it up again and polish it up to 2019 standards.

------
rubyn00bie
So... is this pretty much providing a "headless" gui like coca does (e.g.
UITableView), and then gives you a delegate or something which you implement
for styling it (e.g. UITableViewDelegate)?

------
bubbab
React Table is soo good for making your own table library. The flexibility is
insane, even in the previous version where you had render props + prop
getters. I love the idea of headlessness in v7, although I'm kind of dreading
the migration from v6 -> v7 :)

------
mikhailtatsky
List of almost all grid solutions [https://github.com/FancyGrid/awesome-
grid](https://github.com/FancyGrid/awesome-grid)

------
veeralpatel979
If you like React Table, you might like AG Grid: [https://www.ag-
grid.com/](https://www.ag-grid.com/)

~~~
tannerlinsley
I would actually say that if you like React-Table, you likely wouldn't want to
use Ag-Grid for the very reasons that React Table exists.

Had someone asked if there were similar tables libraries, I would have
expected this response and welcomed it. Ag-Grid is a great library and their
free-tier is very robust, but I don't see how the above comment is anything
more than a drop-in marketing attempt.

~~~
cinbun8
For those that want a UI along with a table, AG-Grid has a neat solution and
is a viable alternative.

------
hiccuphippo
Fyi, the examples in codesandbox don't work for me unless I remove the
serviceWorker.unregister() line.

~~~
tannerlinsley
That's very strange. Can you file an issue or send me more info on how to
replicate that issue?

------
intellix
Sounds like angular-cdk, which is just awesome in the angular world

------
fithisux
So a reimplementation of celtk or hoplon?

~~~
tannerlinsley
I wrote React Table and have never heard of those.

So no, React Table is not a reimplementation.

------
techsin101
I use this and it's not ideal, let's just say that. Lot of edge cases that you
have no way of fixing without messing with library code itself

~~~
tannerlinsley
I'm sorry you've had that experience, though I don't recall seeing any issues
on Github to this degree that we haven't taken care of. Can you point me to
anything specific I can help you out with? Thus far, React Table v7 has been a
complete joy for many to work with.

Also, remember that it's still in beta, so your frustration doesn't have to be
silent or permanent! File an issue and I'll see what I can do.

