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.
- 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.
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.
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.
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.
- 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.
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?