I've personally wasted several hundred hours this year implementing custom table logic and design through the react-virtualized-table/react-window libraries. They are great libraries! But it was not a good use of my time customizing it into a perfect incantation/API. I over-engineered how the virtualization tied into our REST API and many of our junior developers couldn't keep up with the increased abstraction.
Let my story be a lesson that you should probably grab hold of a library like this, swallow the fact that you're conforming to someone else's API and concepts, and just get stuff done.
I'll seriously evaluate and likely use this library in future react projects instead of other more involved implementations. Great docs too!
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.
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.
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...).
/signed - the dumbass that builds his own table components.
Any idea of what is going on here?
[1] https://github.com/tannerlinsley/react-table/blob/master/doc...
if (isFakeColumn(cell.column.id)) {
return <React.Fragment key={cell.column.id}></React.Fragment>;
}
{cell.column.id === "title" ? (
<>
{cell.render("Cell")}
<br />
{row.cells[2].render("Cell")}
<br />
{row.cells[3].render("Cell")}
{" · "}
{row.cells[4].render("Cell")}
</>
) : (
cell.render("Cell")
)}
One thing I do have to complain about is the lack of native TypeScript support - there used to be types in the repo, but they got removed. And `prepareRow(row)` is a bit ugly, but nothing major and it's only a one-time call.
If it's the case, it does mean that the table component isn't controlled (as in "controlled input component"). What you describe (if I understand correctly) is _synchronising_ the local state of the table with my own global state, instead of controlling the table (giving my global state as param of the hook). This is breaking the one-way data flow that makes React so good.
The API I would expect would look more like:
useTable(
useFilter({value: myValue, onChange: myHandler})
)
You have a huge colorful banner at the top of the readme, why not screenshots?
We were hoping for a plug-and-play library, and eventually settled on React Table v6. Being a small team, I don’t think we’ll migrate over to v7 - we don’t have any benefits from any more control over the UI than v6 had.
Calling them 'reports' is also bad but a least it doesn't sound like something is going to be used up
- Lightweight (5kb - 12kb+ depending on features used and tree-shaking) - Headless (100% customizable, Bring-your-own-UI) - Auto out of the box, fully controllable API - Sorting (Multi and Stable) - Filters - Pivoting & Aggregation - Row Selection - Row Expansion - Column Ordering - Animatable - Virtualizable - Resizable - Server-side/controlled data/state - Extensible via hook-based plugin system