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?
React Table is a “headless” UI library
51–60 of 115 posts
Re: React Table is a “headless” UI library
#52I 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? * S…
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!
Re: React Table is a “headless” UI library
#53Hmmm 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).
Re: React Table is a “headless” UI library
#54The "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?
React doesn't avoid this. They describe sharing behavior through higher-order components in their documentation. https://reactjs.org/docs/higher-order-components.html
Re: React Table is a “headless” UI library
#55The "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.
Re: React Table is a “headless” UI library
#56Hmmm 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…
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 :)
Re: React Table is a “headless” UI library
#57I 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 c…
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?
Re: React Table is a “headless” UI library
#58Every 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 requi…
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
Re: React Table is a “headless” UI library
#59I 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 c…
Isn't that what Google does on Google Sheets? I can only imagine the ungodly amount of work to get something like that working.
Re: React Table is a “headless” UI library
#60If you like React Table, you might like AG Grid: https://www.ag-grid.com/
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.