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.<p>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.<p>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)?<p>What do people use in Vue-land for tables? Is there anything that approaches the feature set of jQuery DataTables?
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.<p>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.
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.<p>Is it a useful way to separate look-and-feel concerns from functional concerns, or is it just another layer of indirection?
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?<p>* 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<p>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.
I've been using react-table in Polar since the beginning and it's a great library.<p>We're using it in the document and annotation views and it provides pagination, sorting, etc.<p>I'm a bit nervous about this 7.0 release <i>not</i> providing a basic table UI as that was one of the wins for us migrating.<p>For example, here's a screenshot of the document repository:<p><a href="https://getpolarized.io/#document-repository" rel="nofollow">https://getpolarized.io/#document-repository</a><p>... which is sort of the main view. React table allows you to sort by progress, creation time, update time, etc.<p>We used the same react table code to build the annotation viewer:<p><a href="https://getpolarized.io/#annotation-viewer" rel="nofollow">https://getpolarized.io/#annotation-viewer</a><p>One big issue we had was with context menus and selecting multiple items.<p>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.<p>We're still a way from a more clear cut API for managing this stuff on the web + desktop + mobile.<p>I REALLY wish I could have web technology transparently work on mobile!
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.<p>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.<p>Still, perhaps the right place for that code is examples rather than a library. Hmm.
Pairs great with React Spreadsheet <a href="https://iddan.github.io/react-spreadsheet/" rel="nofollow">https://iddan.github.io/react-spreadsheet/</a>
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.<p>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.<p>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.<p>This has some real potential for any UI library to get first-class table functionality without sweating and needlessly repeating the implementation details.
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).
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
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.<p>Any thoughts on whether this impression is right or wrong?
I was actually building this exact thing many years ago. In hindsight I probably should have made it into React Table.<p><a href="https://github.com/divmgl/tabled.js" rel="nofollow">https://github.com/divmgl/tabled.js</a>
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)?
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 :)
List of almost all grid solutions
<a href="https://github.com/FancyGrid/awesome-grid" rel="nofollow">https://github.com/FancyGrid/awesome-grid</a>
If you like React Table, you might like AG Grid: <a href="https://www.ag-grid.com/" rel="nofollow">https://www.ag-grid.com/</a>
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