I too have gone down the same road as you. I wish I could share your sentiment of - just go with React Table.

But React Table is headless. Which is nice, but it's not going to automatically virtualize rendering. From what I can tell you are going to have to manually render using react virtualized/window or some other solution to get that to work. It also doesn't support things like fixed rows or columns out of the box since it doesn't provide UI.

My initial reaction is that this is a rather complicated API to group, sort, filter, expand, re-order, and select rows within data structures. It also uses a lot of prop spreading which is not my favorite.

I'm not sold that you wasted your time. But I'm going to give it a little more time as my initial assessment could be inaccurate.

I would love to hear how you would solve these problems yourself. Any ideas are very appreciated. Still, the patterns and tradeoffs built into React Table are not fleeting exploratory concepts that we hope will catch on, they are architected this way for a purpose. Sure, it doesn't come with any opinionated UI, but in the future, opinionated UIs for React Table will likely exist (some are already in development by 3rd parties). Until then, there are plenty of examples that show you just how easy it is to implement things like virtualization. Having control of the markup for a data grid can be intense and intimidating for those who aren't use to building their own tables, but again, once you see how little work there is to do in your own components, you'll see the power in the library (like having full control over styles, building your own UI APIs, prop patterns, state management paradigms, etc.) As for the prop spreading............... It's fantastic and I would love to see anyone convince me of a more elegant/composable pattern for decorating arbitrary and unknown markup.

Fair take, but I also believe we should've thrown out virtualization/windowing entirely. It was of those shiny product-level features that sounds great but ultimately provides little to no value for most applications.

Most of my point is engineer-oriented but I think it also applies at the product level. React allows you to build cool features easily - that doesn't mean every cool idea should be acted upon.

At times this will mean "dumbing-down" design in the name of pragmatism > shininess. YMMV, ad-supported businesses are going to need that infinite scroll... but most don't.

Agreed. Most if not all of the production tables I have are using very simple architecture. Pagination + Data Exploration utilities like sort/filter/group/etc.

In no way am I preaching that these plugins should used. However, I am proud that they can be used. And if you end up being one of the users that only needs a few things to make your production tables great, then you win again by being able to treeshake out all of the other stuff you choose not to use.

I went through quite some trouble to get a react-table v6 based datagrid updated to v7.

I found that the examples showed individual features well, but when you combine features you are on your own. The "Kitchen Sink" example is far from having all features enabled at once.

The reason why I couldn't stay with v6 was that the virtualization examples used a deprecated API from an old minor version. I would have had to support a solution on a non-supported version (v6 has been pretty much abandoned).

So, I had to get these features to coexist peacefully:

- expanded rows

- virtualization

- sorting

- custom cell rendering

- click actions inside the cells (open a dialog, add the row entity to comparison)

Mirroring the GP, I had to use react-window and deal with the complexity from the library. I think that virtualization should be a first-class citizen inside react-table, like sorting.

On top of all of this the TypeScript support/typings are tricky to work with (IIRC you have to maintain a .d.ts file in your codebase and remember to update it when you update react-table). I literally had a headache for hours on while going through the refactoring.

In the end I managed to get everything to work without any bugs or weird behavior. I really was enthusiastic about v7, but was left with a bad feel of it.

I'm sure that things will get better, and luckily most folks don't beed all of these features. It's really the virtualization that makes things complicated. The thing is, pagination is not always a viable solution.

To save other people trouble, I should update the Codesandbox that I originally built (https://codesandbox.io/s/react-table-virtualized-subcomponen...).

The beginning of your comment made me uneasy, but then you endorsed the library! Phew! Thanks!

Some of React’s data tables are not that great for anything other than the most conventional cases. You are mostly right, but I don’t think making your own table is equatable to like some of the dumbass things people inject into their ecosystem for a simple app.

/signed - the dumbass that builds his own table components.

Why was the virtualization tied into to your Rest API? If I give you an array of N things, you render them. If you need more records, ask me, and I'll get them for you. The table should be just be a UI component with virtualization. It shouldn't need to know how to retrieve its data.