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?
- Exporting to excel is simple. You are provided the final data model after all processing/filtering/sorting/etc is done, and you are free to use whatever means you want to provide that data to your users, eg. The 'xlsx' npm package could do this easily.
- Searching/Filter is quite advanced. You can search/filter on any derived model of the data regardless of the display or format of that data.
- Sorting can also be 100% customized and can be configured to use any derived sorting mechanism that you choose or build, regardless of display or format.
The difference is that jQuery directly modifies the DOM while React/Vue/Angular/Svelte are all designed to react to some data and automatically render based on it. The simplest table components create an HTML structure by repeating a <TR> for an array of data you pass in, with the columns being the keys. More complex ones let you define your own components to render each row and cell, and have internal state and logic to handle clicks, sorting, filtering, etc.
React Table in this version is headless meaning it just provides the backend functionality but requires you to implement the HTML rendering with your own JSX/components so you get the most control over the output. Detecting clicks is just putting a onclick handler for your rows. Searching is up to you wiring up a textbox and filtering the array of data you provide to the table. Sorting can be handled with custom sort functions.
> React Table in this version is headless meaning it just provides the backend functionality but requires you to implement the HTML rendering with your own JSX/components so you get the most control over the output.
If this is the case, why are we putting this logic in React hooks? Shouldn’t the logic be portable across different frameworks? What does the hook API provide which couldn’t be provided using a class or even pure javascript functions?
One disturbing development I’ve seen with React hooks is that APIs which would normally be done with pure javascript are now done with React hooks for popularity’s sake, with the result being code which is vendor-locked into the React runtime.
The hooks API literally "hooks" into React's lifecycle, by allowing the ability to save state and force re-renders as needed. In addition, React-Table explicitly implements support for doing rendering of whatever React "cell" components you have supplied as part of the column definition.
Yes, a lot of the logic probably could be extracted as a pure vanilla JS lib, but there'd also be a lot of work that would have to be done to then integrate it into React.
Also, the creator is a fairly prolific author of React-based libraries, and that was his focus when he wrote React-Table. If someone else wants to try to create a vanilla JS version, you're free to do so.
This is specifically designed for React and uses the native APIs for best performance and usability. Being framework-agnostic isn't a goal and there are other components like AG-Grid you can look at if you need that.
Hooks is basically a declarative way to keep things in sync instead of writing a bunch of imperative code yourself. You describe the functionality that should run when some data changes (or all the time) and React handles the rest. The code inside hooks is just javascript, and by being functions it's much simpler than class-based structures. Vue is also working on a similar composition API.
The problem with JS datatables is, as a user, I'm expecting something like Excel tables. Being able to easily pin column or row as headers and having access to a filter / order by options in each of those header cell.
Can’t speak for all the folks in Vue-land, but IMO this is pretty super. You do have to add a couple of bells and whistles (like a search field - 5-10 lines of js) to make it awesome.
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
Can’t agree more. We were using vue-tables-2, which got the job done, but the maintainer went MIA for a few months (he did just recently push a new update).
Ag Grid is INSANE. The client side version churns through our entire set like butter.
Even if it weren’t, I was prepared to dive into the graphQL implementation but haven’t needed to.
The only negative I have is the bloat. But I’m p sure v22 solves that by letting you load on demand vs the whole thing.
I can’t imagine ever using datatables again or having to make a server call to sort or filter.
If you are not operating within the React Framework, I can totally agree with this. I used Ag-Grid before I built React Table and it shines as a JS-only datagrid. Start using React however, and I don't believe that is the case.
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.
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!)
Expensive?
I am CTO at ag-Grid competitor(FancyGrid). And I used ag-Grid to check it in details.
You will find more in future.
I use it for one of client, Financial service. I found bugs in ag-Grid, they wrote that it is custom work and that they will start custom work from 50,000$ only.
We use jQuery DataTables where I work and it seems more than adequate.
Supposed to set some time aside to investigate how to possibly port a small subsection of tables to use Vue Data Tables; it looks like there are a bevy of tools for Vue-based Data Tables here: https://madewithvuejs.com/blog/best-vue-js-datatables.
I worked at a company that migrated away from jQuery datatables. We chose Vue-good-table. Worked well but client side rendering mode had performance issues at 10k rows so we implemented a sorting algo in it.
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.
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?
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.
Right, which makes it a deal-breaker for almost all use cases. Plus, I'd guess that it's almost always less effort to optimize the DOM-based approach than to (poorly) reimplement all of that browser functionality in canvas.
I don't have a horse in this race - I don't use React Table or render tables in canvas. I still felt compelled to comment because it's not clear you realize that you're being closed-minded and ignoring what littlecranky67 is trying to explain.
Sometimes, no amount of optimization will achieve your performance objectives with the "obvious" path and you quickly find yourself deep in diminishing returns.
Sometimes, you really do have to do an extraordinary amount of work and cover an intimidating minefield of edge cases and heisenbugs to achieve a viable, working solution.
Of course it's almost always better to use a DOM library and just be done. Of course implementing copy+paste and drag-and-drop on Canvas is a masochistic slog. Nobody wants to do this; not even the insane.
The question is whether when the need arises and you've exhausted all other avenues, can you engineer the hard solution?
Sure, and I guess it depends on your performance requirements. As someone who has built a virtual table implementation in the past, I would much rather deal with the performance issues and nitty gritty micro-optimizations than go anywhere near canvas or WebGL for table rendering. But then again, I don't think my standard for acceptable performance was as high as OP's; I wasn't shooting for a buttery smooth 60fps with no jank, but simply trying to get something usable that wasn't frustratingly slow. If you really do need the performance, sure, I concede that maybe canvas/WebGL is the only way to go, but you'd better be damn sure that you really need the performance before you enter that mess.
Also if accessibility is a requirement, you'll have to implement a fallback in DOM, although you're probably no longer optimizing for raw speed in that case.
If you use a virtual table and only render the content that is visible at any given time, the number of rows ceases to be a bottleneck for rendering. Filtering/sorting becomes the new bottleneck, but you can generally optimize that via specialized indexes/views and other techniques, depending on the shape of your data and your business requirements.
Source: I built a virtual table implementation a decade ago that scaled just fine to tens of thousands of rows, and browsers were a lot slower back then. But my requirements were also relatively simple, so YMMV.
Google Sheets is not a table, which is what the discussion is about.
Edit: It also is not exactly the poster child of good UX and accessibility (or even performance, for that matter), so I'm not sure it's the best example.
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?
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.
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.
I've never used one, but it sounds like a great idea. 3rd party React components are a huge pain in the ass to work with. People do all sorts of bullshit like re-implement half of CSS in their component's API and half the time it's easier to just build the fucking thing yourself than learn all the arbitrary rules around customisation the author has conjured up.
The best reusable components are the ones that have exactly one look, which you're fine with, and are just plug in and go.
None of that is a problem with the logic behind the component though, just the display. So for something complex that has a bunch of logic behind it, it's a real nice idea to just be able to reuse that logic and whack some html and css over the top of it instead of having to read some 6 page doc every time you want to increase the width of a border or something.
I am extremely excited about it. I think of it as a form of IOC for front-end development. Almost constantly we run into a problem where a third party React library gets us 80% of what we want, but that last 20% is where we spend most of our time and where the most bugs are introduced. By taking full control of the front-end we can minimize the API wrangling and CSS hacks we need to get the component to play nice with our UI/UX spec.
Actually, many people do has same idea, but they don't call it 'headless component'. They instead call it 'renderless component'. Means the component itself render no ui element and delegate every ui part to something else. Google this word will give you a lot of similar ideas.
I love this, I mostly do backend and the frontend work I do is usually making things like this so the frontend guy can just work on look and feel while I do the logic.
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.
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.
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.
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!
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.
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.
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 wish more open source code took this approach. Rather than install something that is designed to be a black box that I don’t need to understand and can’t adapt, so often I would prefer to get a well designed, battle tested starting point, but be able to adapt and change that code in the future if I want to.
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.
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 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.
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.
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
WebAssembly engine can handle 1mm+ rows, and can be run virtually in node.js, Python or C++. Does filtering, pivoting on multiple axes, sorting, linking, click events, and more.
I think there is a misunderstanding here; I believe that OP is referring to "infinite scrolling" where the list items are fetched from the server n items at a time as you scroll and wishing for a toolkit that keeps the data in memory and recycles elements as you scroll (which is what everyone is recommending). When OP says "hack" they are talking about loading data as you go, not windowing, which is what you are talking about.
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.
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.
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.
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.
Thank you. I will research and see if it is what I needed (from my initial description I am not sure if it recycles invisible GUI items(DOM Elements) - there is no how it works in the github but I will look under ther hood tomorrow )
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?
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.
- React Table is not an HOC
- React may still show educational materials about HOC's but hooks replace their use-cases in almost every situation.
- I don't see how HOC's are attempting to draw more separation of concerns between the traditional Markup/Logic/Style debate. They were simply the best solution at the time for creating reusable logic.
I've used HOCs to share behavior between React components in the past. You can also accomplish similar things with the Render Props pattern, depending on how you want to organize code. Using hooks is new to me. Anyway, my point is there has always been ways to factor out the behavior from React components. I'm pretty sure the reason they don't encourage factoring it out completely is so that DOM events are still handled in the domain of the UI, since they don't deal with types in your model.
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 :)
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.
"Plain old HTML" is great. And guess what, because React Table is headless, you can render your tables using standard HTML table elements (table,thead,tbody,tr,th,td,tfoot,etc...).
Html elements on their own, however, are not capable of sorting, filtering, grouping, selection, nested header generation, (insert any feature from React Table here), let alone making all of those things perform well together.
Filtering, sorting, collapsing, etc. Can’t do any of that with plain HTML. And if the rest of your app is React, trying to integrate something non-React is just a headache.
Adding the “sortable” class to a <table> element provides support for sorting by column value. Clicking the column headers will sort the table rows by that column’s value. Tables must use <thead> and <th> tags for sortable functionality to work.
This is a copy and paste of the snippet google shows from https://www.bu.edu/tech/services/cccs/websites/www/wordpress... if you search for “sortable table”. The page is actually talking about how to author pages on their Wordpress site, which presumably uses a wordpress plugin to provide the JavaScript necessary to make this work.
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.
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?