I was actually building this exact thing many years ago. In hindsight I probably should have made it into React Table.
React Table is a “headless” UI library
91–100 of 115 posts
Re: React Table is a “headless” UI library
#92I 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…
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.
Re: React Table is a “headless” UI library
#93Earlier quoted context omitted.
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.
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…
It's a backpressure issue. It's called handling backpressure.
Re: React Table is a “headless” UI library
#94I 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?
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.
Re: React Table is a “headless” UI library
#95Every 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
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.
Re: React Table is a “headless” UI library
#96I 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.
Google Sheets is pretty slow to be honest. You want fast tables. Look at Bloomberg terminal. They’ve spent eons optimizing tables.
Google sheets doesn’t even do smooth scrolling that really annoys me. Excel 365 online feels so much smoother.
Re: React Table is a “headless” UI library
#97I'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…
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.
Re: React Table is a “headless” UI library
#98React 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 :)
Re: React Table is a “headless” UI library
#99Earlier quoted context omitted.
Well of course not, you have to implement it yourself - just as everything else when drawing a table into a canvas.
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?
Re: React Table is a “headless” UI library
#100Earlier quoted context omitted.
Well of course not, you have to implement it yourself - just as everything else when drawing a table into a canvas.
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.
Google Sheets is based on canvas. Works pretty good for me.